Skip Headers
Oracle® Database Storage Administrator's Guide
11g Release 1 (11.1)

Part Number B31107-01
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Go to next page
View PDF

2 Preparing Storage for ASM

This chapter describes how to prepare your storage sub-system before you configure Automatic Storage Management (ASM). When preparing your storage to use ASM, first determine the storage option for your system and then prepare the disk storage for the specific operating system environment as described in this chapter. This chapter contains the following topics:

Preparing Disks for ASM

You can create an ASM disk group using one of the following storage resources:

The procedures for preparing storage resources for ASM are:

  1. Identify or create the storage devices for ASM by identifying all of the storage resource device names that you can use to create an ASM disk group. For example, on Linux systems, device names are typically presented from the /dev directory with the /dev/device_name_identifier name syntax.

  2. Change the ownership and the permissions on storage device resources. For example, the following steps are required on Linux systems:

    • Change the user and group ownership of devices to oracle:dba

    • Change the device permissions to read/write

    • On older Linux versions, you must configure raw device binding

After you have configured ASM, ensure that disk discovery has been configured correctly by setting the ASM_DISKSTRING initialization parameter.


Setting the ownership to oracle:dba is just one example that corresponds to the default settings. A non-default installation may require different settings. In general, the owner of the disk devices should be the same as the owner of the Oracle binary. The group ownership should be OSDBA of the ASM instance, which is defined at installation.

See Also:

"ASM_DISKSTRING" for more information about the ASM_DISKSTRING parameter

For detailed information about preparing disks for an ASM installation, refer to your platform-specific installation guide for Oracle Database, Oracle Clusterware, and Oracle Real Application Clusters (Oracle RAC).

ASM and Multipathing

Multipathing solutions provide failover by using redundant physical path components. These components include adapters, cables, and switches that reside between the server and the storage sub-system. If one or more of these components fails, then applications can still access their data, eliminating a single point of failure with the Storage Area Network (SAN), Host Bus Adapter, interface cable, or host port on a multiported storage array.

Multipathing is a software technology implemented at the operating system device driver level. Multipathing creates a pseudo device to facilitate the sharing and balancing of I/O operations across all of the available I/O paths. Multipathing also improves system performance by distributing the I/O load across all available paths. This provides a higher level of data availability through automatic failover and failback.

Although ASM is not designed with multipathing functionality, ASM does operate with multipathing technologies. Multipathing technologies are available from many sources. Storage vendors offer multipathing products to support their specific storage products, while software vendors usually develop multipathing products to support several server platforms and storage products.

See Also:

Your storage or software vendor multipathing documentation for more information about multipathing options for specific platforms and storage products

Using ASM with Multipathing

ASM produces an error if ASM discovers multiple disk device paths. Because a single disk can appear multiple times in a multipath configuration, you must configure ASM to discover only the multipath disk.

With ASM, you can ensure the discovery of a multipath disk by setting the value of the initialization parameter ASM_DISKSTRING equal to the name of the pseudo device that represents the multipath disk. For example, if you are using EMC PowerPath multipathing software, you might set ASM_DISKSTRING to '/dev/rdsk/emcpower*'. When I/O is sent to the pseudo device, the multipath driver intercepts it and provides load balancing to the underlying subpaths. When using ASMLIB with ASM on Linux, you can ensure the discovery of the multipath disk by configuring ASM to scan the multipath disk first or to exclude the single path disks when scanning.

See Also:

Recommendations for Storage Preparation

The following are guidelines for preparing storage for use with ASM:

Storage Considerations for Database Administrators

If you are a database administrator who is responsible for configuring your system's storage, then you need to consider not only the initial capacity of your system, but also your plans for future growth. ASM simplifies the task of accommodating growth. However, your growth plans can affect choices such as the size of the LUNs that are presented as ASM disks.

You need to also consider that I/O performance depends your host bus adapter (HBA) and your storage fabric, not just the storage disks. As you scale up the number of nodes in a cluster, you also need to scale up the storage subsystem.

For high availability, storage is only one component. Within storage, Oracle recommends that you configure the database work area to be separate from the recovery area. You also need a method to protect against disk failures by using hardware mirroring or host-based mirroring from a normal or high redundancy disk group. Furthermore, you also need to consider multipathing for HBAs and the fabric when considering storage availability. With ASM mirroring, the failure group configuration also affects high availability.