| Oracle® Database Storage Administrator's Guide 11g Release 1 (11.1) Part Number B31107-01 |
|
|
View PDF |
| Oracle® Database Storage Administrator's Guide 11g Release 1 (11.1) Part Number B31107-01 |
|
|
View PDF |
This chapter describes Automatic Storage Management (ASM) concepts and provides an overview of ASM features. This chapter contains the following topics:
For a list of the terms that are used in the Oracle Database Storage Administrator's Guide and their definitions, refer to the Glossary in this guide.
ASM is a volume manager and a file system for Oracle database files that supports single-instance Oracle Database and Oracle Real Application Clusters (Oracle RAC) configurations. ASM is Oracle's recommended storage management solution that provides an alternative to conventional volume managers, file systems, and raw devices.
ASM uses disk groups to store datafiles; an ASM disk group is a collection of disks that ASM manages as a unit. Within a disk group, ASM exposes a file system interface for Oracle database files. The content of files that are stored in a disk group are evenly distributed, or striped, to eliminate hot spots and to provide uniform performance across the disks. The performance is comparable to the performance of raw devices.
You can add or remove disks from a disk group while a database continues to access files from the disk group. When you add or remove disks from a disk group, ASM automatically redistributes the file contents and eliminates the need for downtime when redistributing the content.
The ASM volume manager functionality provides flexible server-based mirroring options. The ASM normal and high redundancy disk groups enable two-way and three-way mirroring respectively. You can use external redundancy to enable a Redundant Array of Inexpensive Disks (RAID) storage subsystem to perform the mirroring protection function.
ASM also uses the Oracle Managed Files (OMF) feature to simplify database file management. OMF automatically creates files in designated locations. OMF also names files and removes them while relinquishing space when tablespaces or files are deleted.
ASM reduces the administrative overhead for managing database storage by consolidating data storage into a small number of disk groups. This enables you to consolidate the storage for multiple databases and to provide for improved I/O performance.
ASM files can coexist with other storage management options such as raw disks and third-party file systems. This capability simplifies the integration of ASM into pre-existing environments.
Oracle Enterprise Manager includes a wizard that enables you to migrate non-ASM database files to ASM. ASM also has easy to use management interfaces such as SQL*Plus, the ASMCMD command-line interface, and Oracle Enterprise Manger.
This section describes concepts for the key ASM components and it contains the following topics:
See Also:
Chapter 2, "Preparing Storage for ASM" for more details about preparing your storage environmentAn ASM instance is built on the same technology as an Oracle Database instance. An ASM instance has a System Global Area (SGA) and background processes that are similar to those of Oracle Database. However, because ASM performs fewer tasks than a database, an ASM SGA is much smaller than a database SGA. In addition, ASM has a minimal performance effect on a server. ASM instances mount disk groups to make ASM files available to database instances; ASM instances do not mount databases.
ASM metadata is the information that ASM uses to control a disk group and the metadata resides within the disk group. ASM metadata includes the following information:
The disks that belong to a disk group
The amount of space that is available in a disk group
The filenames of the files in a disk group
The location of disk group datafile data extents
A redo log that records information about atomically changing data blocks
ASM and database instances require shared access to the disks in a disk group. ASM instances manage the metadata of the disk group and provide file layout information to the database instances.
ASM instances can be clustered using Oracle Clusterware; there is one ASM instance for each cluster node. If there are several database instances for different databases on the same node, then the database instances share the same single ASM instance on that node.
If the ASM instance on a node fails, then all of the database instances on that node also fail. Unlike a file system failure, an ASM instance failure does not require restarting the operating system. In an Oracle RAC environment, the ASM and database instances on the surviving nodes automatically recover from an ASM instance failure on a node.
Figure 1-1 shows a single node configuration with one ASM instance and multiple database instances. The ASM instance manages the metadata and provides space allocation for the ASM files. When a database instance creates or opens an ASM file, it communicates those requests to the ASM instance. In response, the ASM instance provides file extent map information to the database instance.
Figure 1-1 ASM for Single-Instance Oracle Databases
In Figure 1-1, there are two disk groups: one disk group has four disks and the other has two disks. The database can access both disk groups. The configuration in Figure 1-1 shows multiple database instances, but only one ASM instance is needed to serve the multiple database instances.
Figure 1-2 shows an ASM cluster in an Oracle RAC environment where ASM provides a clustered pool of storage. There is one ASM instance for each node serving multiple Oracle RAC or single-instance databases in the cluster. All of the databases are consolidated and sharing the same two ASM disk groups.
Figure 1-2 ASM Cluster Configuration with Oracle RAC
A clustered storage pool can be shared by multiple single-instance Oracle Databases as shown in Figure 1-3. In this case, multiple databases share common disk groups. A shared ASM storage pool is achieved by using Oracle Clusterware. However, in such environments an Oracle RAC license is not required.
ASM instances that are on separate nodes do not need to be part of an ASM cluster and do not communicate with each other. However, multiple nodes that are not part of an ASM cluster cannot share a disk group. To share a disk group among multiple nodes, you must install Oracle Clusterware on all of the nodes, regardless of whether you install Oracle RAC on the nodes.
Figure 1-3 ASM Cluster with Single-Instance Oracle Databases
A disk group consists of multiple disks and is the fundamental object that ASM manages. Each disk group contains the metadata that is required for the management of space in the disk group.
Files are allocated from disk groups. Any ASM file is completely contained within a single disk group. However, a disk group might contain files belonging to several databases and a single database can use files from multiple disk groups. For most installations you need only a small number of disk groups, usually two, and rarely more than three.
Disk group components include disks, files, and allocation units. Figure 1-4 shows the relationships among ASM disk group components.
Mirroring protects data integrity by storing copies of data on multiple disks. The disk group type determines the mirroring levels with which Oracle creates files in a disk group.
When you create a disk group, you specify an ASM disk group type based on one of the following three redundancy levels:
Normal for 2-way mirroring
High for 3-way mirroring
External to not use ASM mirroring, such as when you configure hardware RAID for redundancy
The disk group type determines the mirroring levels with which Oracle creates files in a disk group. The redundancy level controls how many disk failures are tolerated without dismounting the disk group or losing data.
ASM mirroring is more flexible than traditional RAID mirroring because you can specify the redundancy level for each file. Two files can share the same disk group with one file being mirrored while the other is not.
When ASM allocates an extent for a normal redundancy file, ASM allocates a primary copy and a secondary copy. ASM chooses the disk on which to store the secondary copy in a different failure group other than the primary copy. Failure groups are used to place mirrored copies of data. Each copy is on a disk in a different failure group. The simultaneous failure of all disks in a failure group does not result in data loss.
If you specify normal redundancy for a file, then ASM stores two copies of the file extents in the disk group. ASM selects the disk for the secondary copies of the extents from a failure group other than the failure group in which the primary copies reside.
You define the failure groups for a disk group when you create an ASM disk group. After a disk group is created, you cannot alter the redundancy level of the disk group. To change the redundancy level of a disk group, create another disk group with the appropriate redundancy and then move the files to the new disk group. Oracle recommends that you create failure groups of equal size to avoid space imbalance and uneven distribution of mirror data.
If you omit the failure group specification, then ASM automatically places each disk into its own failure group. Normal redundancy disk groups require at least two failure groups. High redundancy disk groups require at least three failure groups. Disk groups with external redundancy do not use failure groups.
See Also:
"ASM Mirroring and Failure Groups" for more information about mirroring and failure groupsASM disks are the storage devices that are provisioned to ASM disk groups. Examples of ASM disks include:
A disk or partition from a storage array
An entire disk or the partitions of a disk
Logical volumes
Network-attached files (NFS)
When you add a disk to a disk group, you either assign a disk name or the disk is given an ASM disk name automatically. This name is different from the name used by the operating system. In a cluster, a disk may be assigned different operating system device names on different nodes, but the disk has the same ASM disk name on all of the nodes. In a cluster, an ASM disk must be accessible from all of the instances that share the disk group.
If the disks are the same size, then ASM spreads the files evenly across all of the disks in the disk group. This allocation pattern maintains every disk at the same capacity level and ensures that all of the disks in a disk group have the same I/O load. Because ASM load balances among all of the disks in a disk group, different ASM disks should not share the same physical drive.
Every ASM disk is divided into allocation units (AU). An AU is the fundamental unit of allocation within a disk group. A file extent consists of one or more AU. An ASM file consists of one or more file extents.
When you create a disk group, you can set the ASM AU size to be between 1 MB and 64 MB in powers of two, such as, 1, 2, 4, 8, 16, 32, or 64. Larger AU sizes typically provide performance advantages for data warehouse applications that use large sequential reads.
Files that are stored in ASM disk groups are called ASM files. Each ASM file is contained within a single ASM disk group. Oracle Database communicates with ASM in terms of files. This is identical to the way Oracle Database uses files on any file system. You can store the following file types in ASM disk groups:
Control files
Datafiles, temporary datafiles, and datafile copies
SPFILEs
Online redo logs, archive logs, and Flashback logs
RMAN backups
Disaster recovery configurations
Change tracking bitmaps
Data Pump dumpsets
Note:
Oracle executables and ASCII files, such as alert logs and trace files, cannot be stored in ASM disk groups.ASM automatically generates ASM file names as part of database operations, including tablespace creation. ASM file names begin with a plus sign (+) followed by a disk group name. You can specify user-friendly aliases for ASM files and create a hierarchical directory structure for the aliases. The following sections describe the ASM file components:
The contents of ASM files are stored in a disk group as a collection of data extents that are stored on individual disks within disk groups. Each extent resides on an individual disk. Extents consist of one or more AU. To accommodate increasingly larger files, ASM uses variable size extents.
Variable size extents enable support for larger ASM files, reduce SGA memory requirements for very large databases, and improve performance for file create and open operations. An ASM file begins with an extent equal to one AU. As the file size increases, the extent size also increases to 8 AU and then to 64 AU at a predefined number of extents. The size of the extent map that defines a file can be smaller by a factor of 8 and 64 depending on the file size. The initial extent size is equal to the allocation unit size and it increases by a factor of 8 and 64 at predefined thresholds. This feature is automatic for newly created files.
Figure 1-4 shows the ASM file extent relationship with allocation units. Extent size is always equal to AU up to the first 2000 extents. Figure 1-4 shows the first eight extents distributed on four ASM disks. The extent size becomes 8*AU. This is shown as bold rectangles labeled with the extent numbers 20,001 to 20,007, and so on. The next increment for an ASM extent is 64*AU which is not shown in the figure.
The ASM coarse striping is always equal to the disk group AU size, but fine striping size always remains 128KB in any configuration (not shown in the figure). The ASM extent map memory overhead is reduced by approximately a factor of 1/8 or 1/64 depending on the ASM file size.
Figure 1-4 ASM File Allocation in a Disk Group
ASM striping has two primary purposes:
To balance loads across all of the disks in a disk group
To reduce I/O latency
Coarse-grained striping provides load balancing for disk groups while fine-grained striping reduces latency for certain file types by spreading the load more widely.
To stripe data, ASM separates files into stripes and spreads data evenly across all of the disks in a disk group. The stripes are equal in size to the effective AU. The coarse-grained stripe size is always equal to the AU size. The fine-grained stripe size always equals 128 KB; this provides lower I/O latency for small I/O operations such as redo log writes.
Templates are collections of attribute values that are used to specify file mirroring and striping attributes for an ASM file when it is created. When creating a file, you can include a template name and assign desired attributes based on an individual file rather than the file type.
A default template is provided for every Oracle file type, but you can customize templates to meet unique requirements. Each disk group has a default template associated with each file type.
See Also:
Chapter 5, "Administering ASM Files, Directories, and Templates" for more information about ASM files, directories, and templatesThis section describes ASM disk group administration and it contains the following topics:
The disk discovery process locates the operating system names for disks that ASM can access. Disk discovery is also used to find all of the disks that comprise a disk group to be mounted. This can include the disks that you want to add to a disk group and the disks that you might consider adding to a disk group.
An ASM instance requires an ASM_DISKSTRING initialization parameter value to specify its discovery strings. Only pathnames that the ASM instance has permission to open are discovered. The exact syntax of a discovery string depends on the platform and ASMLIB libraries. The pathnames that an operating system accepts are always usable as discovery strings.
See Also:
"ASM_DISKSTRING" for information about the
ASM_DISKSTRING initialization parameter, and "ASM Disk Discovery" for information about disk discoveryA disk group must be mounted by a local ASM instance before database instances can access the files in the disk group. Mounting the disk group requires discovering all of the disks and locating the files in the disk group that is being mounted.
You can explicitly dismount a disk group. Oracle reports an error if you attempt todismount a disk group when any of the disk group files are open. It is possible to have disks fail in excess of the ASM redundancy setting. If this happens, then the disk group is forcibly dismounted. This shuts down any database instances that are using the disk group.
See Also:
"Mounting and Dismounting Disk Groups" for more information about disk groupsThe discovery string specifies the disk or disks that you can add. These disks include disks that are already in the disk group as well as new disks.
You can add a disk to an existing disk group to add space and to improve throughput. The discovery string specifies the disk or disks that you want to add. This can include disks that are already in the disk group as well as new disks. The disks that you add must be discovered by every ASM instance using the ASM_DISKSTRING initialization parameter. After you add a disk, ASM rebalancing operations move data onto the new disk. To minimize the rebalancing I/O, it is more efficient to add multiple disks at the same time.
You can drop a disk from a disk group if it fails or to re-provision capacity. You can also manually drop a disk that has excessive soft errors before the disk fails. Use the ASM disk name to drop a disk, not the discovery string device name. If an error occurs while writing to a disk, then Oracle drops the disk automatically.
See Also:
"Altering Disk Groups" for more information about altering disk group membershipRebalancing a disk group moves data between disks to ensure that every file is evenly spread across all of the disks in a disk group. When all of the files are evenly dispersed, all of the disks are evenly filled to the same percentage; this ensures load balancing. Rebalancing does not relocate data based on I/O statistics nor is rebalancing started as a result of statistics. ASM rebalancing operations are controlled by the size of the disks in a disk group.
ASM automatically initiates a rebalance after storage configuration changes, such as when you add, drop, or resize disks. The power setting parameter determines the speed with which rebalancing operations occur.
You can manually start a rebalance to change the power setting of a running rebalance. A rebalance is automatically restarted if the instance on which the rebalancing is running stops; databases can remain operational during rebalancing operations. A rebalance has almost no effect on database performance because only one megabyte at a time is locked for relocation and only writes are blocked.
See Also:
"Manually Rebalancing Disk Groups" for more information about disk rebalancing