As Published In May/June 2004

Add Storage, Not Projects
By Jonathan Gennick

Automatic Storage Management lets DBAs do their jobs and keep their weekends.

DBAs spend a lot of time managing disk space. To maximize I/O rates, we spread the data we manage across many physical disks. Often we do this by working with a system administrator who uses a logical volume manager (LVM) to combine many physical disks into a single logical volume for use by Oracle Database. Then, when those logical volumes run out of space, we may spend part of our weekend unloading data, adding a new drive to the volume, and reloading data to balance it across all drives. The more adventuresome of us will plumb the mysteries of raw devices in order to eke out a 10 to 15 percent increase in performance. What a lot of work! Wouldn't it be great if we could just throw a basket of disk drives at the database and let the database sort out the details? Oracle Database 10g moves us toward that goal in the form of a new feature called Automatic Storage Management (ASM).

What Is ASM?

ASM is a combination of a logical volume manager and a file system embedded within the database. Using ASM, you define groups of disks that are analogous to the volumes you would otherwise create by using an LVM. Then you can place datafiles, logfiles, and even control files onto those groups. ASM creates the necessary files in Oracle's file system and stripes your data across all the disks in a group. ASM can mirror data for you, and it rebalances data as you add disks to and remove them from a group. Because ASM understands the contents of the files it manages, it can rebalance data in ways an LVM cannot. Because ASM eliminates the LVM and the operating system's file system from the disk group stack, you reap a potential performance gain similar to what you get from using raw devices. However, ASM is far more convenient to use than raw devices.

Figure 1 shows a high-level view of the ASM architecture. ASM storage is managed and apportioned out to database instances via a new type of instance called an ASM instance. One ASM instance manages ASM storage for all the database instances on a given server. Database instances still read and write their own data, but the ASM instance reads and writes data during rebalancing operations.

instance_type=asm
background_dump_dest=C:\oracle\admin\
asm10\bdump
core_dump_dest=C:\oracle\admin\asm10\
cdump
user_dump_dest=C:\oracle\admin\asm10\
udump
compatible=10.1.0.1.0
asm_diskstring='\\.\*:'

ORADIM -NEW -ASMSID asm10 -SYSPWD 
nevertell -PFILE C:\oracle\admin\asm10\pfile\
initasm10.ora

All that remains is to start the instance, create a server parameter file, and bounce the instance so that it comes up using that new file. Listing 1 shows these tasks. (You can ignore messages about disk groups not being mounted at this point in the process.) Using a server parameter file enables the ASM instance to automatically record new disk group names in the ASM_DISKGROUPS parameter, so that those disk groups can be automatically mounted whenever the ASM instance is started. After you start the new ASM instance, any database instances on the same server will automatically find it.

Creating Disk Groups

create disk groups and add and remove storage while connected to the ASM instance. Be sure to connect as SYSDBA. You can query V$ASM_DISK to see which disks you are using or may potentially use. A group number of 0 indicates that a disk is available and hasn't yet been assigned to a disk group. Listing 2 shows the creation of a new disk group named MYDATA, followed by a query to V$ASM_DISKGROUP to show details of the new group.

The MYDATA disk group contains four disks. The keywords NORMAL REDUNDANCY result in two-way mirroring of all files on the disk group. You can specify EXTERNAL REDUNDANCY if your disks each map to a RAID array managed externally or if you do not care to mirror the files at all. You can be extra cautious and specify HIGH REDUNDANCY to get three-way mirroring.

The MYDATA disk group consists of two failure groups, which define sets of disks that should never contain more than one copy of mirrored data. Any data files that ASM places on drives F: and G: must therefore be mirrored on drives H: and I:. Data on F: can never be mirrored on G:. If two drives share a controller or any other such resource, be it hardware or software, you should put them into the same failure group to ensure against failure of that common resource. Assuming that F: and G: are on the same controller, that controller can fail, with H: and I:, both on a different controller, picking up the load.

Placing Data on a Disk Group

Placing new objects on a disk group is simple. You can use disk group names in place of filenames when you create database files, redo log members, and so on. Even though you're now using ASM storage, you perform these operations while connected to your database instance. For example,

CREATE TABLESPACE geo_names
   DATAFILE '+MYDATA' SIZE 100M;

CREATE TABLE geo_names (
   state         VARCHAR2(2),
   feature_name   VARCHAR2(80),
   feature_type   VARCHAR2(9),
   county        VARCHAR2(60)
) TABLESPACE geo_names;

The plus sign (+) in front of the name MYDATA indicates that the name is a disk group name, not an operating system filename. Your database instance queries the ASM instance for a new file in that disk group and uses that file for the tablespace data—in this case, striping the geo_names table data across all the drives in 1-megabyte chunks. (Redo log and control files use a 128K stripe size.)

Migrating existing database files to ASM is a bit more of a challenge. Traditionally, you move database files by using operating system commands, but your operating system can't read from and write to Oracle's file system, so you need another method for moving existing files onto ASM. You can migrate redo logs to ASM storage by creating a new member in each log group, placing those new members on ASM disk groups, forcing a log switch, and then dropping all the non-ASM log members. For datafiles and control files, the solution for migrating to ASM lies in using RMAN. For detailed procedures for using RMAN to move files into and out of ASM storage, see the Backup and Recovery Advanced User's Guide, especially Chapter 12, "Migrating Databases to and from ASM with Recovery Manager."

Adding and Removing Storage

You can easily add disks to or remove them from a group. To add disks to a group, first add them to your server (or to your storage network or disk array), change them to be owned by the same user that owns the Oracle Database software, tag them with asmtool (for Windows only), and then issue an ALTER DISK GROUP command from your ASM instance. The following example adds two disks to MYDATA, one to each failure group:

ALTER DISKGROUP mydata
  ADD FAILGROUP mydata01 DISK '\\.\J:'
      FAILGROUP mydata01 DISK '\\.\K:';

It's not necessary to add disks to all failure groups within a disk group. You can add a disk to just one failure group, leaving the others unchanged, but it's good practice to keep the amount of space in the failure groups close to equal. Otherwise, you might not have the room you need for mirroring data.

When you add a disk to a group, ASM automatically rebalances the data stored in that group, so that each disk in the group uses the same amount of its capacity, percentagewise. For example, if your data consumes 30 percent of the total space in the disk group, that data will be spread across all drives, so that each is 30 percent full. There's much less I/O involved in ASM's rebalancing process than if you were to unload and reload all the data in the tablespace. You can view ongoing rebalancing operations by querying V$ASM_OPERATION from the ASM instance, as shown in Listing 3. The SOFAR and EST_WORK columns refer to allocation units, which are 1MB chunks for datafiles. EST_WORK is the total number of units to move, and SOFAR is the number of units moved so far during the rebalance operation. EST_RATE is the current number of units per minute being moved by the rebalance operation, and EST_MINUTES gives an estimate of the remaining time, in minutes.

Next Steps READ ASM documentation Oracle Database Administrator's Guide: Chapter 12, "Using Automatic Storage Management" Backup and Recovery Advanced User's Guide: Chapter 12, "Migrating Databases to and from ASM with Recovery Manager" LEARN more about ASM on Oracle Technology Network's Database Manageability page: ASM is supported on all database platforms, including Windows, Linux, Solaris, and HP-UX.

ALTER DISKGROUP mydata
   DROP DISK MYDATA_0004, MYDATA_0005;