Original subtitles

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.