Oracle Automatic Storage Management

By Sean Hull

There's a lot of talk about ASM, but what the heck is it really? ASM is effectively an abstraction layer, allowing your Oracle database to work with abstract space called diskgroups, instead of datafiles directly. This provides lots of benefits, but also requires learning some new concepts, commands, utilities, and administration tasks. So take a look at what it solves, and what it takes to manage and weigh the pros and cons before diving in with your production systems.

Why Was It Created?

The best way to answer this question is to go right to the source, Bill Bridge the original architect of Automatic Storage Management. In the Oracle Press title, Oracle ASM, Bill provides a forward where he discusses the problems with using vendor specific OS filesystems to manage Oracle datafile placement:

1.  for arch logs & backups, OS vendors don't provide shared disk filesystem

2.  logical volume managers hide the location of files making it difficult to manage disk I/O and provide good stats

3.  existing lvm's don't work well with over 100 disks

4.  OS's and Oracle don't handle databases well that have 1000's of datafiles

5.  naming becomes difficult with large number of datafiles

6.  features, and filesystem limitations vary across different OSs

7.  users at the OS level can touch Oracle files with standard utilities, without Oracle knowing

So, he set out to solve these problems by building Oracle's own filesystem. His intention was to provide these features:

1.  tightly integrated with Oracle, and work with clusters (then parallel server)

2.  new storage automatically used, managed as disk unit or disk group

3.  thousands of disks supported

4.  files won't have names, and will be hidden from the OS

Who Needs It?

A quick look at the problems and solutions above should help you determine who ASM is targeted at. For starters, it was built to handle the very large databases now coming online. So if that includes your shop, you're probably already looking at it, or starting to implement ASM. If you have smaller databases, with fewer datafiles, you may still want to consider it given a few considerations.

1.  You'll have some new technology to get familiar with, and should start by setting it up in your dev environment, and do some testing for a few months.

2.  If you want to squeeze out more performance from your existing disk subsystem, and get better statistics for forcasting disk I/O.

3.  If you're using RAC, ASM is something to consider.

Getting Started

ASM is managed by an instance, much like an Oracle database. However the initialization parameters are much more limited and the startup process is simpler.

a.  Set your ORACLE_SID to +ASM1

b.  Edit init.ora

# as opposed to RDBMS for a normal Oracle instance

INSTANCE_TYPE=ASM

# these names will be used in place of datafile names when you create tablespaces

ASM_DISKGROUPS=SEAN, AARON

processes=100

# this parameter is platform specific and is the path to the raw disk device

ASM_DISKSTRING='/dev/cciss/c0d0p1'

# on 11g you should use diagnostic_dest instead of these

background_dump_dest=/opt/oracle/admin/+ASM/bdump'

core_dump_dest=/opt/oracle/admin/+ASM/cdump'

user_dump_dest=/opt/oracle/admin/+ASM/udump'

c.  start the ASM instance

$ sqlplus / as sysdba

SQL> startup

d.  create diskgroups

SQL> create diskgroup SEAN disk '/dev/cciss/c0d0p1';

e.  example tablespace creation

As you might guess, creating a tablespace will change slightly. The default method looks like this:

SQL> create tablespace sean_space datafile '+SEAN' size 1GB;

However, consider this great feature. If in your database init.ora file you set the parameter

db_create_file_dest=+SEAN

then you can do this:

SQL> create tablespace sean_space;

Then let Oracle do the rest. In both cases, you'll find that the paths of files listed in v$datafile will be relative to the abstract +SEAN diskgroup, not a real OS datafile.

f.    And Way Beyond

Of course simplifying filenames and tablespace creation is really only the tip of the iceberg for what ASM can do for you. It can also provide a level of redundancy as well.

In database speak, external redundancy is basically when you have redundancy at the hardware level (RAID) or other method outside of what Oracle can see. In other words if the asm_diskstring devices are themselves logical, hiding the physical disks behind some hardware layer of redundancy, then you have external redundancy.

However, if you don't already have this redundancy, ASM can provide it. You can specify redundancy, failure groups, and a whole host of other options to protect against loss of one or more disks, controllers, or even whole SAN failures. ASM also provides evenly distributed I/O across a diskgroup. Since ASM has a better picture of what's happening under the hood, Oracle can automatically provide a better balance of I/O to disk for you.

Challenges to ASM Adoption

ASM is certainly a powerful technology with a lot of potential. But with every technical solution, there come a whole host of other challenges. In the case of ASM, it potentially disrupts the usual balance of power between the Unix + Systems Administration groups, and the Database/DBA groups. Traditionally the former group manages disks, hardware, and the operating system level, leaving the DBAs to coordinate with them for new resources. This would change that balance somewhat, which could cause some resistance from that group.

In the end, it should be the business need that pushes this adoption. Also be aware that ASM is still in the enterprise computing sense, relatively new. There are a number of vendors whose core business has been in the logical volume manager/filesystem space for years. Quite often, maturity matters a lot when it comes to software systems, and reliability.

Conclusion

ASM is powerful stuff, providing solutions for the growing very large database systems being deployed currently. It may also provide solutions for smaller database installations, or those using clustering. As with any new technology, evaluate, test, and then test some more.

=========================================================

Automatic Storage Management (ASM)

Automatic Storage Management (ASM) is oracle’s logical volume manager, it uses OMF (Oracle Managed Files) to name and locate the database files. It can use raw disks, filesystems or files which can be made to look like disks as long as the device is raw. ASM uses its own database instance to manage the disks, it has its own processes and pfile or spfile, it uses ASM disk groups to manage disks as one logical unit.

The benefits of ASM are

• • Provides automatic load balancing over all the available disks, thus reducing hot spots in the file system

  • Prevents fragmentation of disks, so you don't need to manually relocate data to tune I/O performance

  • Adding disks is straight forward - ASM automatically performs online disk reorganization when you add or remove storage

  • Uses redundancy features available in intelligent storage arrays

  • The storage system can store all types of database files

  • Using disk group makes configuration easier, as files are placed into disk groups

  • ASM provides stripping and mirroring (fine and coarse gain - see below)

  • ASM and non-ASM oracle files can coexist

  • ASM is free!!!!!!!!!!!!!

The three components of ASM are

• • Not Managed by ASM - Oracle binaries, alert log, trace files, init.ora or password file

  • Managed by ASM - Datafiles, SPFILES, redo log files, archived log files, RMAN backup set / image copies, flash recovery area.

ASM Processes

There are a number of new processes that are started when using ASM, both the ASM instance and Database will start new processes

ASM registers its name and disks with the RDBMS via the cluster synchronization service (CSS). This is why the oracle cluster services must be running, even if the node and instance is not clustered. The ASM must be in mount mode in order for a RDBMS to use it and you only require the instance type in the parameter file.

ASM Disk Groups

An ASM disk group is a logical volume that is created from the underlying physical disks. If storage grows you simply add disks to the disks groups, the number of groups can remain the same.

ASM file management has a number of good benefits over normal 3rd party LVM's

• performance

• redundancy

• ease of management

  • security

ASM Stripping

ASM stripes files across all the disks within the disk group thus increasing performance, each stripe is called an ‘allocation unit’. ASM offers two types of stripping which is dependent on the type of database file

ASM Mirroring

Disk mirroring provides data redundancy, this means that if a disk were to fail Oracle will use the other mirrored disk and would continue as normal. Oracle mirrors at the extent level, so you have a primary extent and a mirrored extent. When a disk fails, ASM rebuilds the failed disk using mirrored extents from the other disks within the group, this may have a slight impact on performance as the rebuild takes place.

All disks that share a common controller are in what is called a failure group, you can ensure redundancy by mirroring disks on separate failure groups which in turn are on different controllers, ASM will ensure that the primary extent and the mirrored extent are not in the same failure group. When mirroring you must define failure groups otherwise the mirroring will not take place.

There are three forms of Mirroring

• • External redundancy - doesn't have failure groups and thus is effectively a no-mirroring strategy

  • Normal redundancy - provides two-way mirroring of all extents in a disk group, which result in two failure groups

  • High redundancy - provides three-way mirroring of all extents in a disk group, which result in three failure groups

ASM Files

The data files you create under ASM are not like the normal database files, when you create a file you only need to specify the disk group that the files needs to be created in, Oracle will then create a stripped file across all the disks within the disk and carry out any redundancy required, ASM files are OMF files. ASM naming is dependent on the type file being created, here are the different file-naming conventions

• • fully qualified ASM filenames - are used when referencing existing ASM files (+dgroupA/dbs/controlfile/CF.123.456789)

  • numeric ASM filenames - are also only used when referencing existing ASM files (+dgroupA.123.456789)

  • alias ASM filenames - employ a user friendly name and are used when creating new files and when you refer to existing files

  • alias filenames with templates - are strictly for creating new ASM files

  • incomplete ASM filenames - consist of a disk group only and are used for creation only.

Creating ASM Instance

Creating a ASM instance is like creating a normal instance but the parameter file will be smaller, ASM does not mount any data files, it only maintains ASM metadata. ASM normally only needs about 100MB of disk space and will consume about 25MB of memory for the SGA, ASM does not have a data dictionary like a normal database so you must connect to the instance using either O/S authentication as SYSDBA or SYSOPER or using a password file.

The main parameters in the instance parameter file will be

• • instance_type - you have two types RDBMS or ASM

  • instance_name - the name of the ASM instance

  • asm_power_limit - maximum speed of rebalancing disks, default is 1 and the range is 1 - 11 (11 being the fastest)

  • asm_diskstring - this is the location were oracle will look for disk discovery

  • asm_diskgroups - diskgroups that will be mounted automatically when the ASM instance is started.

You can start an ASM instance with nomount, mount but not open. When shutting down a ASM instance this passes the shutdown command to the RDBMS (normal, immediate, etc)

RMAN backup

RMAN is the only way to backup ASM disks.