Automated Storage Management (ASM) tips Oracle Tips by Burleson Consulting June 27, 2015

For more Disk I/O Tuning information, you may want Mike Ault's best-selling book Oracle Disk I/O Tuning.  It's 30% off at this link and you get immediate access to the code depot.

What is Automated Storage Management?

By Mike Ault

Automated Storage Management (ASM) was designed to simplify database administration. ASM eliminates the need for the DBA to directly manage the thousands of Oracle database files that could be present in a modern Oracle instance. ASM does this by enabling ASM disk groups, which are logical units comprised of disks and the files that reside on them. Using ASM, the management of thousands of Oracle files is reduced to managing a small number of disk groups.

The SQL statements used for creating database structures, such as tablespaces, redo logs, archive log files, and control files, must specify file location in terms of ASM disk groups, in order to use ASM. ASM will then create and manage the associated underlying files for you.

ASM is the logical extension of the power of Oracle-managed files (OMF). In previous releases of OMF, files were created and managed automatically for you, but with ASM you reap the additional benefits of features such as ASM disk group mirroring and striping.

ASM was designed to preserve all existing database functionality. Your existing databases will operate as they always have. Existing databases using file systems or with storage on raw devices will operate as they always have. However, even in existing databases, new files can be created as ASM files while old ones are administered in the old way. This means that databases can have a mixture of ASM files, Oracle-managed files, and manually managed files all at the same time.

To turn on ASM 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.

Automated Storage Management (ASM) was designed to simplify database administration. ASM eliminates the need for the DBA to directly manage the thousands of Oracle database files that could be present in a modern Oracle instance. ASM does this by enabling ASM disk groups, which are logical units comprised of disks and the files that reside on them. Using ASM, the management of thousands of Oracle files is reduced to managing a small number of disk groups.

The SQL statements used for creating database structures, such as tablespaces, redo logs, archive log files, and control files, must specify file location in terms of ASM disk groups, in order to use ASM. ASM will then create and manage the associated underlying files for you.

ASM is the logical extension of the power of Oracle-managed files (OMF). In previous releases of OMF, files were created and managed automatically for you, but with ASM you reap the additional benefits of features such as ASM disk group mirroring and striping. ASM was developed by the same group that developed ODM (Oracle Disk Manager) with in Oracle Corporation.

ASM was designed to preserve all existing database functionality. Your existing databases will operate as they always have. Existing databases using file systems or with storage on raw devices will operate as they always have. However, even in existing Oracle 10g Databases, new files can be created as ASM files while old ones are administered in the old way. This means that databases can have a mixture of ASM files, Oracle-Managed files, and manually managed files all at the same time.

Why ASM?

Before we examine the role and position of ASM in the storage stack of the database files, let us look at some of the storage management features that are often used in varying degree of the usage. They include:

• Direct I/O
• Asynchronous I/O
• Striping
• Mirroring
• SAME and Load Balancing

Direct I/O

Buffered I/O uses precious resources like memory and CPU cycles because the Oracle blocks are cached both in the SGA and in the file system buffer cache. By adopting the Direct I/O, a much higher cache hit ratio can be achieved. Oracle can handle cache much more efficiently than a file system can handle. Oracle has a sophisticated touch count based cache replacement algorithm that is sensitive to both the frequency of usage and how recent the data blocks are.

Buffered I/O fills up the file system cache with Oracle Data, where as using the Direct I/O allows non-Oracle data to be cached in the file system much more efficiently. Also the buffered I/O generally involves large physical writes, such as temp file writes. These writes are performed and waited for in series, and therefore they cannot be merged in the device driver or lower layers of the stack, unless a write-back disk cache is in use. This means that a full rotational latency of the physical disk is sustained between every pair of component writes.

Redo Log file writes also suffer from another severe inefficiency if buffered I/O is used. Because redo writes address an arbitrary number of log blocks, and log blocks are small relative to the size of file system buffers, it is normal that the last log block of a redo write does not align with the end of a file system buffer. Therefore, unless the target file system block is already in cache, the operating system must first read that block from disk before the new redo can be copied into part of its file system buffer.

To solve all these problems, the direct I/O is highly desired. The way in which direct I/O is enabled varies from one system to another and also depends on the type of file system type. In some cases it is sufficient to set the filesystemio_options parameter; in some cases a file system mount option is required; and direct I/O can also be configured on a file-by-file basis using special operating system commands. The use of ASM eliminates need for direct I/O configuration.

Installation of ASM

In Oracle Database 10g, the Oracle Universal Installer (OUI) will always install ASM when the database software is installed. The Database Configuration Assistant (DBCA) determines if an ASM instance already exists, and if not, then you will be given the option of creating and configuring an ASM instance as part of the installation. If an ASM instance already exists, then it will be used by default. DBCA automatically configures your ASM instance parameter file and password file.

DBCA eases the configuring and creation of your database, while EM provides an integrated approach for managing both your ASM instance and database instance.

Oracle's Enterprise Manager (EM) product or the Database Configuration Assistant (DBCA) should be used for a GUI interface to ASM that replaces the use of SQL or SQL*Plus for configuring and altering disk groups and their metadata.

Configuration of Automated Storage Management

One of the most significant new features in Oracle 10g release is the introduction of Automated Storage Management (ASM). In order to use the ASM in a shared mode for the use of RAC database, an ASM instance needs to be created for each node of the RAC database involving the same disk devices as input. Each ASM instance has either an SPFILE or PFILE type parameter file.  To use ASM in the RAC environment, select ASM as the storage option when creating the database with the Database Configuration Assistant (DBCA).

Automated Storage Management configuration

To turn on  automated storage management (ASM) facility, you must create a separate ASM instance before you start your database instances. An ASM instance does not require that an Oracle instance be running; as might be the case when you are initially configuring the components managed by the ASM instance. 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 Oracle database server and you do not need to install ASM as a separate product. The Oracle ASM executables are 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.

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

Oracle ASM is useful for automating and simplifying the optimal layout of data files, control files, and log files, especially for RAC. Oracle ASM automatically distributes database files across all available disks (RAID 10), and whenever the storage configuration changes, the database storage is re-balanced. ASM can also be used to provide redundancy, through the mirroring of database files on different disks.

ASM is great for Oracle because it eliminates the management overhead involved with the use of a conventional file system, and there is no need to manually place data files on disks when using ASM. Also, by allowing the administrator to manage just a few disk groups, the administrator is relieved from the tedium of managing hundreds or thousands of files. Using ASM, the DBA needs only manage the 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.
 

Oracle ASM storage concepts

ASM employs several basic concepts. ASM operates on disk groups which is a collection of disks defined by ASM and transparent to the interface. Within the groups, it creates ASM datafiles. Therefore the main building blocks of ASM are:

• ASM disks
• ASM disk groups
• ASM files
• ASM templates

You can run the list data groups (lsdg) ASM command from a bash shell script to quickly see the disk space usage:

#!/bin/bash
. /home/oracle/set_oraenv
sid="+ASM1"
echo "Check Space on "$sid
export ORACLE_SID=$sid
asmcmd << EOF
lsdg
EOF     

Let's explore these ASM concepts in detail.

Components of the ASM instance

There are several components within an 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 the datafiles into 1 MB 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 Oracle ASM disk groups

There are three types of Oracle ASM disk groups:

• Normal redundancy
• High redundancy
• 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.

This is an excerpt from "Oracle RAC & Grid" by Rampant TechPress.