As Published In September/October 2003

Eliminating Complexity: Automatic Storage Management

By Kelli Wiseth

Provisioning storage for a single database instance, let alone an entire enterprise, is complex. Typically, the process runs something like this: Come up with a reasonable estimate of the amount of space you're likely to need over the long term, map out what you hope will be an optimal structure—where to put datafiles, archive files, and so on to avoid hotspots; create logical volumes; create file systems; install Oracle; and finally, create your database. And then the hard work begins—looking for hotspots that negatively affect performance; moving datafiles around to reduce contention; and waiting for the day you run out of space (and you always do), when you must add more disks and shift all the files around again to rebalance across your updated storage configuration.

Fortunately, that scenario is about to change dramatically, thanks to Oracle Database 10g's new Automatic Storage Management (ASM) capability. In simple terms, ASM provides the functionality of a volume manager and a file system directly in the Oracle Database kernel, resulting in the type of "virtualization" benefits—ease of manageability, higher availability—that storage-area-network systems provide, specialized for Oracle Database files rather than for more-generalized storage needs. As with a logical volume manager, ASM spreads its files across all available storage for optimal performance, and it can mirror as well (at either the disk or the database file level), providing protection against data loss.

But more important, ASM eliminates the complexity associated with managing data and disks. It vastly simplifies the processes of setting up mirroring and adding and removing disks. Rather than managing hundreds, possibly thousands, of files—as in a vast data warehouse, for example—DBAs using ASM create and administer a larger-grained object, the disk group, which identifies the set of disks that will be managed as a logical unit.

Adding a disk to an ASM disk group is as simple as preparing the disk for the underlying OS and then issuing the Add Disk command. The elegance of ASM really shows, though, when it comes to rebalancing the load after adding a disk to or removing it from a disk group: Whether you remove disks from or add them to your configuration, with a single command, all your datafiles will be redistributed across the disks—automatically, while the database is running.

In addition to the disk group concept, ASM introduces the concept of failure groups. A failure group identifies a set of disks sharing a common resource—a controller, for example—whose failure can be tolerated. With ASM, a DBA creates the appropriate number of failure groups to accommodate the disk groups created for your system. The failure groups can be defined to enable mirroring of datafiles across a disk controller or even an entire disk array, allowing for component loss without data loss.

You don't have to use ASM's native mirroring mechanism; in the process of creating a disk group, you specify the redundancy for that group, and if you prefer to use an external system (or you have no need for fault tolerance for a particular disk group), you can set the redundancy to external, in which case ASM won't mirror at all—the assumption being that you're using an external mirroring solution.

Unless otherwise specified, redundancy defaults to normal, which places the mirrored data in two different failure groups. For the highest level of fault tolerance, you can specify high redundancy, which provides three-way mirroring. And as mentioned, you can choose the level of protection (datafile level or disk level).

The core components of ASM include its own separate, special-purpose database instance—the ASM instance—dedicated to managing the metadata about physical disks, the disk groups they comprise, and the failure groups. The ASM instance also manages the mapping of where the entire datafile resides and controls the process of rebalancing the placement when the storage allocation is changed. An ASM instance uses only a 64MB system global area (SGA), so resource requirements are relatively small. In a RAC configuration, an ASM instance on each node in the cluster manages all disk and failure groups for that node, in coordination with the other nodes in the cluster.

Oracle recommends using ASM with Oracle Database 10g, which supports all the other new features in this release that involve managing the movement or placement of datafiles and space objects, including bigfile tablespaces and the disk cache recovery area. ASM is completely integrated with SQL*Plus, Enterprise Manager, and Database Configuration Assistant (DBCA).