Automatic Storage Management
Under an ASM system, the Oracle DBA is in charge of the management of physical storage from within Oracle’s framework, instead of relying on the system administrator. Using the ASM disk groups, you can address sets of disks simultaneously, instead of individual disks, and the database can dynamically configure storage based on changing workloads. By allowing the Oracle DBA the flexibility to manage complex storage management
devices across various server and storage platforms, ASM becomes a crucial part of Oracle’s grid computing initiative.
ASM is built on OMF, which means you don’t have to worry about specifying filenames and locations when creating new databases—all you have to do is identify an ASM disk group, which consists of a set of disks. When you create a database or add a file, you can use familiar CREATE, ALTER, and DROP SQL statements to allocate disk space. ASM acts as Oracle’s built-in Logical Volume Manager by handling striping and mirroring functions previously managed by third-party tools. Under ASM,
disks are grouped and managed by the database itself and made available for creating tablespaces. You don’t have to mount the files as with the normal Linux or UNIX file systems. You also can’t use the traditional tools, such as cp and tar, to copy the ASM files, nor can you describe them using the ls command. The database holds all information regarding ASM files. If you use ASM for an Oracle file, the operating system can’t see it, but RMAN and Oracle’s other tools can.
Benefits of ASM
By using ASM, you can manage data by selecting reliability and performance characteristics for data classes, rather than working with large storage systems on a per-file basis.
An ASM file system offers the following benefits:
• ASM provides automatic load balancing over all the available disks, thus reducing hot spots in the file system.
• ASM prevents fragmentation of disks, so you don’t need to manually relocate data to tune I/O performance.
• Adding disks is straightforward—ASM automatically performs online disk reorganization when you add or remove storage.
• ASM uses redundancy features available in intelligent storage arrays.
• The ASM storage system stores all types of database files.
• ASM makes your file management tasks easier, because you will be dealing with just a few groups of disks, rather than a multitude of database files. ASM automatically creates the database files and places them in appropriate disk groups.
• ASM does mirroring and striping, which in turn increases reliability and performance. You can select different reliability and performance characteristics for various types of data. For example, you can use fine-grained striping for redo log files and a coarser-grained striping for regular datafiles.
• ASM is free!
Examining the ASM Architecture
The three major components of ASM are the ASM instance, ASM disk groups, and ASM files. Let’s look briefly at these important ASM components.
The ASM instance is a special Oracle instance—it does not have its own datafiles like a regular Oracle database does. A single ASM instance on a server can manage the ASM file systems for all the Oracle databases on that server. The ASM instance looks after disk groups and gives the database access to the ASM files. The database makes the initial contact with the ASM instance to get information on the datafiles, but it accesses those files directly. The ASM instance must be running for an Oracle database to use the ASM file system, and the ASM instance can’t be shut down while the other Oracle databases using ASM file systems are still running, since those databases will crash without the ASM instance.
ASM disk groups are somewhat analogous to logical volumes created by a Logical Volume Manager. Unlike the usual Oracle database files, you don’t access ASM files directly. Disks in an ASM context are rather loosely defined and can include a partition of a disk spindle or the entire disk spindle itself. This depends on how the storage system represents the logical unit number (LUN) to the operating system. Any LUN or a disk represented to the operating system is called a disk. Since each operating
system could have a different disk-naming system, check your disk-naming system.
ASM files are part of an ASM disk group, which contains all your database files. ASM manages a disk group consisting of several disk drives as a single unit, and it spreads the data evenly among all the disks in the group. You don’t have to change the management of your database if you want to switch to an ASM system, because you can use your operating system–based files with the new ASM files. Logical concepts such as extents, segments, and tablespaces work the same way under an ASM system.
Here’s a summary of an ASM storage system:
• A database is allowed to have multiple disk groups.
• You can store all of your Oracle database files as ASM files because Oracle sets up a one-to-one mapping between an Oracle database file (datafiles and control files, for example) and an ASM file.
• An ASM disk group comprises a set of disk drives.
• ASM disk groups are permitted to contain files from more than one disk.
• ASM files always spread over every disk in an ASM disk group and belong to one disk group only.
• ASM allocates disk space in allocation units of 1MB.
ASM and Cluster Synchronization Service
An ASM storage system requires the use of an additional specialized instance called ASM, which will actually manage the storage for a set of Oracle databases. In order to use ASM storage for your Oracle databases, you must first ensure that you have Oracle’s Cluster Synchronization Service (CSS) running on your databases.
CSS is responsible for synchronizing ASM instances and your database instances, and is installed as part of your Oracle software. When you start an ASM instance, it registers itself and the disk groups it manages with the CSS, and when an RDBMS needs to get to a disk group, it relies on the CSS to provide the name of the ASM instance that is managing that disk group.
Examining an ASM Instance’s Architecture
An ASM instance uses several regular Oracle background processes, such as SMON, PMON, and LGWR. In addition, ASM utilizes two new ones: ASM rebalance master (RBAL) and ASM rebalance (ARBn). The RBAL process coordinates disk activity, and the ARBn processes perform the rebalancing work, which can include moving data extents.
In addition to ASM’s RBAL and ARBn, any Oracle database instance that uses ASM will have two ASM-related background processes: RBAL and ASM background (ASMB). RBAL performs global opens of the disks that are part of the ASM disk group, and ASMB connects to the ASM instance as a foreground process and links the ASM instance and your database instance, sending information such as notifications when a datafile is created or deleted, and when statistics are updated.
You can use the OEM Database Control to manage an ASM instance. Its main page shows your ASM instance’s status. From here, click the Configuration tab to visit the ASM Configuration page, where you can modify the ASM instance’s parameters. You can also go to the ASM main page and check your instance’s performance.
ASM Preferred Mirror Read
ASM provides different levels of mirroring, to support various mirroring strategies. You can create an ASM disk group with the following types of redundancy levels:
• Normal provides two-way mirroring.
• High provides three-way mirroring.
• External bypasses ASM mirroring, and is ideal when you wish to configure hardware RAID to provide redundancy.
The redundancy level you choose determines the amount of disk failure the database will tolerate before it loses data. External redundancy doesn’t require any failure groups since it doesn’t use mirroring. Normal redundancy requires two failure groups. High redundancy requires at least three failure groups. ASM stores copies of data in different failure groups. In a normal redundancy file, ASM always allocates a primary copy and a secondary copy when it allocates a new extent and stores
the two copies in different failure groups By default, ASM always reads the primary copy of a mirrored extent in both normal and high redundancy disk groups. However, at times, it may be more efficient to read from a local copy of an extent, even if it isn’t in the primary failure group. You can use ASM’s preferred mirror read feature to make an ASM instance read from specific failure groups instead of automatically reading from the primary failgroup. This feature is especially useful when dealing with a stretch cluster, in which the individual nodes are spread out.
You must set the ASM_PREFERRED_READ_FAILURE_GROUPS initialization parameter to specify a list of preferred mirrored read failure group names, as shown in this example:
asm_preferred_read_failure_groups=data.locationA,data.locationB
Once you set up a list of preferred failure group names, ASM will prefer to read from disks in those failure groups. The result is that all nodes will read from their local extents, thus leading to improved performance.
You can query the V$ASM_DISK view to find out which disks are in a preferred read failure group:
SQL> select preferred_read from v$asm_disk;
The value of the PREFERRED_READ column will be Y if a disk belongs to a preferred read failure group.
Comments