Brief Notes on Automatic storage Management

Oracle ASM uses disk groups to store data files. An ASM disk group is a collection of disks managed 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 is evenly distributed to eliminate hot spots and to provide uniform performance across the disks. The performance is comparable to the performance of raw devices. [From Oracle® Automatic Storage Management Administrator's Guide 11g Release 2].


ASM Disk Groups

An ASM disk group consists of one or more disks and is the fundamental object that ASM manages. Each disk group is self contained and has its own ASM metadata. It is that ASM metadata that an ASM instance manages.

The idea with ASM is to have small number of disk groups. In ASM versions before 11.2, two disk groups should be sufficient - one for datafiles and one for backups/archive logs. In 11.2 you would want to create a separate disk group for ASM spfile, Oracle Cluster Registry (OCR) and voting disks - provided you opt to place those objects in an ASM disk group.

ASM Disks
Disks to be used by ASM have to be set up and provisioned by OS/storage administrator before ASM installation/setup. Disks can be local physical devices (IDE, SATA, SCSI, etc), SAN based LUNs (iSCSI, FC, FCoE, etc) or NAS/NFS based disks. Disks to be used for ASM should be partitioned. Even if the whole disk is to be used by ASM, it should have a single partition.
The above is true for all environments except for Exadata - where ASM makes use of grid disks, created from cell disks and presented to ASM via LIBCELL interface.

An ASM disk group can have up to 10,000 disks. Maximum size for an individual ASM disk is 2 TB. Due to bug 6453944, it is possible to add disks over 2 TB to an ASM disk group. The fix for bug 6453944 is in 10.2.0.4, 11.1.0.7 and 11.2. MOS Doc ID 736891.1 has more on that.

ASM looks for disks in the OS location specified by ASM_DISKSTRING initialization parameter. All platforms have the default value, so this parameter does not have to be specified. In a cluster, ASM disks can have different OS names on different nodes. In fact, ASM does not care about the OS disk names, as those are not kept in ASM metadata.

ASM Files

Any ASM file is allocated from and completely contained within a single disk group. However, a disk group might contain files belonging to several databases and a single database can have files in multiple disk groups.

ASM can store all Oracle database file types - datafiles, control files, redo logs, backup sets, data pump files, etc - but not binaries or text files. In addition to that, ASM also stores its metadata files within the disk group. ASM has its own file numbering scheme - independent of database file numbering. ASM file numbers under 256 are reserved for ASM metadata files.

ASM Cluster File System (ACFS), introduced in 11.2, extends ASM support to database and application binaries, trace and log files, and in fact any files that can be stored on a traditional file systems. And most importantly, the ACFS is a cluster file system.

ASM Allocation Units

An ASM allocation unit (AU) is the fundamental space unit within an ASM disk group . Every ASM disk is divided into allocation units.

When a disk group is created, the allocation unit size can be set with the disk group attribute AU_SIZE (in ASM versions 11.1 and later). The AU size can be 1, 2, 4, 8, 16, 32 or 64 MB. If not explicitly set, the AU size defaults to 1 MB (4MB in Exadata).

AU size is a disk group attribute, so each disk group can have a different AU size.

ASM Extents

An ASM extent consists of one or more allocation units. An ASM file consists of one or more ASM extents.

We distinguish between physical and virtual extents. A virtual extent, or an extent set, consists of one physical extent in an external redundancy disk group, at least two physical extents in a normal redundancy disk group and at least three physical extents in a high redundancy disk group.

Before ASM version 11.1 we had uniform extent size. ASM version 11.1 introduced the variable sized extents that enable support for larger data files, reduce (ASM and database) SGA memory requirements for very large databases, and improve performance for file create and open operations. The initial extent size equals the disk group AU_SIZE and it increases by a factor of 4 or 16 at predefined thresholds. This feature is automatic for newly created and resized data files with disk group compatibility attributes COMPATIBLE.ASM and COMPATIBLE.RDBMS set to 11.1 or higher.

The extent size of a file varies as follows:

• Extent size always equals the disk group AU_SIZE for the first 20,000 extent sets
• Extent size equals 4*AU_SIZE for the next 20,000 extent sets
• Extent size equals 16*AU_SIZE for the next 20,000 and higher extent sets

Together combined allocation unit and Extent size the distribution of extents is like somewhat below, Each extent is copied /created in each disk evenly,

Note the size of the extents may vary in the disks but in the files & Also observe the Cyan color boxes are the ASM Metadata content.

ASM Mirroring

ASM mirroring protects data integrity by storing multiple copies of the same data on different disks. When a disk group is created, ASM administrator can specify the disk group redundancy as follows:

• External - no ASM mirroring

• Normal - 2-way mirroring

• High - 3-way mirroring

ASM mirrors extents - it does not mirror disks or blocks. ASM file mirroring is the result of mirroring of the extents that constitute the file . In ASM we can specify the redundancy level per file. For example, one file in a normal redundancy disk group, can have its extents mirrored once (default behavior). Another file, in the same disk group, can be triple mirrored - provided there are at least three failgroups in the disk group. In fact all ASM metadata files are triple mirrored in a normal redundancy disk group - provided there are at least three failgroups.

ASM Failgroups

ASM disks within a disk group are partitioned into failgroups (also referred to as failure groups or fail groups). The failgroups are defined at the time the disk group is created. If we omit the failgroup specification, then ASM automatically places each disk into its own failgroup. The only exception is Exadata, where all disks from the same storage cell are automatically placed in the same failgroup.

Normal redundancy disk groups require at least two failgroups. High redundancy disk groups require at least three failgroups. Disk groups with external redundancy do not have failgroups.

When an extent is allocated for a mirrored file, ASM allocates a primary copy and a mirror copy. Primary copy is store on one disk and the mirror copy on some other disk in a different failgroup.

When adding disks to an ASM disk group for which failgroups are manually specified, it is imperative to add the disks to the correct failgroup.

The brown colour boxes are metadata headers of the disk, each disk contain the metadata header in failuregroup containing the distribution of extents spread across in the disk

Further, The Red color boxes are the extents in failure group 1, called as primary extents and the purple ones are the secondary extents a mirrored copy of the primary extents.

In case of High redudancy the extents of secondary were two as it contains three failure groups.

Source:- Diagrams picked up from www.juliandyke.com and modified a bit

Next Post:- ASM Metadata Contents (the brown boxes above)

-Thanks

Geek DBA