All language subtitles for [SubtitleTools.com] Automatic Storage Management - ASM - Learning Oracle 12c [Video]

In this lesson, we're going to
be looking at Automatic Storage

Management or ASM.

ASM is really an amazing
feature of the Oracle database

that was first introduced
in version 10g.

In 11g, it was moved to become a
pod of the grid infrastructure,

which is the software that
supports Real Application

Clusters or RAC.

And the best way
to understand ASM

is to kind of understand
the two methods of storing

Oracle database
files that preceded

the introduction of ASM,
and that is on a file system

and on raw devices.

So when we store an Oracle
database on the file system,

we're talking about
what is actually

going to store the
data files themselves.

So in this case,
in a file system,

they're stored on a
general OS file system,

something like NTFS,
on Windows, ext3,

on Linux, a file system
related to one of those.

Not a network file system
or a shared file system,

but just a general
OS file system,

and this is the kind
of thing that we're

familiar with if you've ever
formatted a hard drive or even

a floppy disk.

When you format a
disk, what you're doing

is laying down a file
system on top of it.

And a file system
just makes it easier

to interact with the files.

So in Windows, you can use
Explorer to go through folders

and look at files and drill
down, so on and so forth.

In Linux and Unix, you can
use directories using the CD

command to drill
down into directories

and to see the
files that are there

and operate with those files.

So a file system just
makes it easier to use.

And when we store an Oracle
database on the file system,

there's some pros and cons.

The pros are that,
obviously, it's easy to use.

It's easy to see and
manage the files.

If you want to know where
you're redo logs are,

you can look in the data
dictionary for their location

and then open a Windows
Explorer or a Linux command line

and just drill down through
the directory structure

and see the files.

The cons for file system based
databases are that it's slower.

It's slower because a
file system has overhead,

and that file system
overhead that's involved

can create a performance drag.

This is just basically because a
file system, like NTFS or ext3,

is not designed with the Oracle
database data files in mind

in particular.

So a general OS file system
has its own overhead,

it has its own
file system cache,

which is a memory area where
blocks from the file system

are stored.

And that's sort of in conflict
with an Oracle database

because Oracle has its
own caching mechanism.

So really, when you operate
with an Oracle database

on a file system, you're
really operating not disk

to Oracle cache, but file
system cache to Oracle cache.

There can be some
confusion there,

and consequently, it ends up
being a little bit slower.

Now, for many databases, the
file system based database

is fine because it does
not affect performance

in such a way that would cause
a problem for the application.

But in larger databases or
more demanding environments,

in terms of performance,
especially when

you get into things like data
warehousing, decision support

systems of that nature, then
the performance is everything,

and having your database
on a file system

could be problematic.

So historically, the other
option was raw devices.

And with raw devices,
the database data files

are stored on an unformed
logical volume or disk.

So to try to picture
what this is like,

imagine that you
are at the store

and you purchase a hard
drive that you're going

to put into your computer.

You open up your computer,
you attach the disk drive,

but you don't format it.

Well, you might say,
well, you can't use it

if you don't format it.

Well, Oracle can use
devices like that.

As long as the operating
system underneath the hood

can see the disk,
it can be told,

use this unformatted
disk for Oracle Data.

Now the difficulty of this
is that there is a one to one

relationship between
data files and disks

when you use raw devices.

So that one disk can't
hold multiple data files.

It has to hold one data file.

So there needs to be a
disk for your control file,

one disk for each
of your redo logs,

one disk for each of your data
files, so on and so forth.

So that's why we use
the term logical volume.

In a enterprise
system, you might

have something like a
storage area network,

and we would just cut out
unformatted logical volumes out

of that mass of disk so that
you're not actually worried

about a one to one between
data files and disks,

you have a little more control.

So the pros of this
is that databases

running on raw devices are
much faster than file system--

along the order of 30% faster.

And this can be a
huge improvement

for database performance
because database I/O is usually

the limiting factor as far
as performance in a database.

That is to say, it's
easier to add more memory

or even add more CPUs if
it's necessary to a system,

but there's not that many ways
to increase the disk output.

So having raw devices can
be a tremendous performance

boost in terms of
I/O, and that really

adds up to the user experience.

And the cons of this
method are that it

is very difficult to work with.

Even for experienced system
administrators and database

administrators,
the overhead that's

involved in cutting
out all of the volumes

and matching them up, and
it can be even dangerous

because there are no
real safeguards as far as

if we had two data files pointed
to the same logical volume.

They would simply
overwrite each other,

and it certainly can be
done and certainly is done,

but it is much more difficult
to work with than a file system

database.

So those two form an extreme.

With 10g Oracle devised
ASM, which was a new way

to do database storage,
ASM is essentially

a file system for the Oracle
database, designed for Oracle,

designed to store the
Oracle database files.

ASM runs in its own instance--

not a database, but an instance.

So the set of background
processes and memory

structures, that's an instance,
and ASM uses its own instance,

and that instance is very small.

It takes very little overhead
to work with ASM from a system

resource perspective.

And how we do this is, just as
we did before with raw devices,

we would cut out
logical volumes.

But instead of assigning data
files to each one of these,

we present those
raw devices to ASM,

and it completely manages them.

So we say, these 10 raw
devices are yours to use, ASM.

Then Oracle takes
those raw devices

and manages them as it sees
fit, automatically managing

the storage, hence the name.

So some benefits in ASM is we
get the speed of raw devices,

because we have
no OS file system

overheads, so we get that 30%
or better boost in I/O speed.

It's simpler to
manage than using

raw devices,
although probably not

simpler to manage than
a file system database.

It's safer to manage because
ASM has many safeguards that

would prevent us
from doing things

like dropping a raw device
or pointing two data

files to the same raw device.

And it has a number
of hot features.

It is a globally
available file system,

meaning that it can be used for
RAC, so Oracle talks to ASM,

and those different instances
that Oracle has in Oracle RAC

can all share that same ASM
space without any dangers

of overwriting.

It also has features like
dynamic rebalancing, meaning,

if we have our ASM setup and
we have all the raw devices

assigned to it and
we want to grow,

we can simply assign
more raw devices to it,

make those a part of ASM,
and it can dynamically

rebalance that data without
any shutdown of the system

or really without any
performance overhead

because it's very efficient in
how it manages that data that's

on the raw devices.

The ASM architecture is broken
down into a couple of terms

that we'll cover here.

Lastly, we had here in this
list, the ASM instance.

So the set of background
processes and memory

caches that it needs to
manage the ASM disks.

The raw devices that we present
to ASM are known as ASM disks.

And when we take
ASM disks, we can

create what's called
a disk group that

is a set of ASM disks.

So those disk groups make
it much easier to work with.

So if we were to
create a table space,

rather than saying create table
space data file with this path,

we would simply say, data
file and within quotes would

be a plus sign and then
the name of the disk group.

And from that point, Oracle
takes it over and manages it.