9.1. Introducing the ASM Architecture

ASM not only enhances performance by automatically spreading database objects over multiple devices, but it increases availability by allowing new disk devices to be added to the database without shutting down the database; ASM automatically rebalances the distribution of files with minimal intervention.

ASM also eases the administrative burden of managing potentially thousands of database files by creating disk groups, which are comprised of disk devices and the files that reside on the disk devices managed as a logical unit. ASM divides the datafiles and other database structures into extents and divides the extents among all the disks in the disk group to enhance both performance and reliability. Instead of mirroring entire disk volumes, ASM mirrors the database objects to provide the flexibility to mirror or stripe the database objects differently depending on their type. Optionally, the objects may not be striped at all if the underlying disk hardware is already RAID-enabled, for example.

Automatic rebalancing is another key feature of ASM. When you need an increase in disk space, you can add disk devices to a disk group, and ASM moves a proportional number of files from one or more existing disks to the new disks to maintain the overall I/O balance across all disks. This happens in the background while the database objects contained in the disk files are still online and available to users. If the impact to the I/O subsystem is high during a rebalance operation, the speed at which the rebalance occurs can be reduced using an initialization parameter.

As mentioned earlier in this chapter, ASM supports virtually all Oracle object types as well as RAC, eliminating the need to use any other logical volume manager or cluster file system. Figure 9.1 shows an example of a database that contains tablespaces consisting of files both from a traditional file system and from an ASM disk group, and another database that allocates all its datafiles from an ASM disk group.

Note that the example in Figure 9.1 shows that more than one database may allocate files from the same ASM disk group. An ASM file is always spread over all ASM disks in the ASM group; an ASM disk belongs to only one ASM disk group.

Figure 9.1. Tablespaces using ASM and traditional datafiles

ASM requires a special type of Oracle instance to provide the interface between a traditional Oracle instance and the file system. The ASM software components are shipped with the database and are always available as a selection when choosing the storage type for the SYSTEM, SYSAUX, and other default tablespaces when the database is created.

Using ASM does not, however, preclude you from mixing ASM disk groups with manual Oracle datafile management techniques, but the ease of use and performance of ASM makes a strong case for eventually converting all your storage to ASM disk groups.

Two new background processes support ASM instances: RBAL and ORBn. RBAL coordinates the disk activity for disk groups on an ASM instance, and ORB n, where n can be from 0 to 9, performs the actual extent movement between disks in the disk groups.

For database instances that use ASM disks, two new background processes also exist: OSMB and RBAL. OSMB performs the communication between the database and the ASM instance, and RBAL performs the open and close of the disks in the disk group on behalf of the database instance. Note that the RBAL process exists in both ASM instances and database instances, but performs different functions on each.