Tuning Oracle disk I/O: ASM configuration

Tuning Oracle disk I/O: ASM configuration

Automated Storage Management configuration

To turn on ASM facility, you must create a separate ASM instance before you start your database instances. An ASM instance does not require that a DB instance be running; as might be the case when you are initially configuring the components managed by the ASM instance. But to use Automated Storage Management for managing your Oracle database files, you must have both a database instance and an ASM instance running. Automated Storage Management is integrated into the database server; you do not need to install it as a separate product. The Oracle binaries installed for a normal 10g Oracle are used for the ASM instance. Thus there is no separate Oracle Home for ASM. However, to use ASM files, there must be at least one ASM instance configured and started prior to starting a database instance that uses ASM files.

The Database Configuration Assistant (DBCA) or Server Control Utility (SRVCTL) or Oracle Enterprise Manager (OEM) is used in Oracle Database 10g to configure the Automated Storage Management (ASM) features for conventional and Real Application Clusters (RAC) environments.

ASM is used to automate and simplify the optimal layout of data files, control files, and log files. ASM automatically distributes database files across all available disks, and whenever the storage configuration change, the database storage is rebalanced. ASM can also be used to provide redundancy, through the mirroring of database files.

ASM essentially eliminates the management overhead involved with the use of a conventional file system. There is no need to manually place data on disks when using ASM. Also, by allowing the administrator to manage just a few disk groups, the administrator is relieved from managing hundreds or thousands of files. Using ASM, the DBA will use disk groups for setting up a database. After setup, the DBA need only be concerned with disk groups when monitoring and changing disk allocations within the disk groups.

ASM uses the process of breaking each file into multiple extents and spreading the extents evenly across all of the disks in a disk group. Once ASM disk groups are established, the Oracle database automatically allocates storage space from these disk groups for creating and deleting files.

Unneeded data files are automatically deleted with ASM, rather than requiring a manually issued command, as in previous versions. Automated Storage Management enhances database integrity for databases operating on disks that are not extremely reliable.

ASM concepts

ASM employs several basic concepts. ASM operates on disk groups which is a collection of disks. Within the groups, it creates ASM files. Therefore the main building blocks are:

·         ASM disks

·         ASM disk groups

·         ASM files

·         ASM templates

Let us explore these concepts in detail. The following figure gives a glance of the components in ASM instance and relation with database instance.

Components of the ASM instance

ASM disk groups

A disk group is basically one or more ASM disks that are managed as a single logical unit. Any data-structure stored in an ASM disk group is totally contained within that disk group, or self-contained. A database using ASM disks doesn't have to be shutdown in order for a disk to be added or dropped. ASM rebalances the spread of data to ensure an even I/O load to all disks in a disk group when the disk group configuration changes.

We mentioned that any single ASM file is self-contained in a single ASM disk group. However, an ASM disk group can contain files belonging to several databases, and a single database can use storage from multiple ASM disk groups. You can specify a disk group as the default disk group for files created in a database by specifying the disk group in file destination initialization parameters.

ASM divides files into 1MB extents and spreads the extents for each file evenly across all of the disks in a disk group. ASM uses pointers to record extent location instead of using a mathematical function to track the placement of each extent. When the disk group configuration changes, ASM moves individual extents of a file rather than having to move all extents to adhere to a formula based on the number of disks.

For files, such as log files, that require low latency, ASM provides fine-grained (128k) striping to allow larger I/Os to be split and processed in parallel by multiple disks. At file creation time, you can decide whether or not to use fine-grained striping. File type specific templates in the disk group determine the default behavior.

Most installations will probably have two or more disk groups. The reasons for having multiple different disk groups include the following:

·         To group disks of different manufacturers, different sizes or performance characteristics.

·         To group disks with different external redundancy together; for example, JBOD (just a bunch of disks) would generally not be in the same disk group with disks from a RAID 1+0 or RAID5 configuration, but this is possible using ASM.

·         To separate work and recovery areas for a given database.

Note: In any installation, non-ASM managed operating system storage repositories are required, and are used for swap files, execution libraries, and user file systems. The Oracle database and ASM executable files and libraries must reside on the server's operating system file system and cannot reside in an ASM files.

In case of RAC database environment, files for loading into externals tables are still located on non-ASM file system which can be a cluster file system or local file system.

Types of disk groups

There are three types of ASM disk groups:

1.      Normal redundancy

2.      High redundancy

3.      External redundancy

With normal and high redundancy, the disk group template specifies the ASM redundancy attributes for all files in the disk group.

Configuration of ASM high redundancy provides a greater degree of protection. With external redundancy, ASM does not provide any redundancy for the disk group.

In external redundancy, the underlying disks in the disk group must provide redundancy (for example, using a RAID storage array.) The redundancy level or type is specified at the time of creating the disk groups.