Architecture

The ASM database comprises the following components:

• ASM instance
• Disks
• Disk groups
• Failure groups
• ASM templates
• Background processes
• Cluster synchronization services
• ASM allocation units

ASM instance

An ASM instance is an Oracle instance that includes many of the usual background processes and the memory structure of any Oracle instance. However, if you compare this against a normal Oracle RDBMS instance, this new instance is not a complete instance but a smaller subset of a regular RDBMS instance. This means that while most of the background processes are present in an ASM instance and administrators can make a connection to the ASM instance, no queries or dynamic views (with the exception of a few views required by ASM) are available. ASM architecture is vastly different from an RDBMS instance and contains no physical files, such as log files, control files, or datafiles. The primary function of the ASM instance is to manage the storage system. Apart from being the owner of the disks, the ASM instance acts as a bridge between the Oracle database and the physical storage. To differentiate between a regular database instance and an ASM instance, Oracle has introduced a new parameter called INSTANCE_TYPE. The parameter INSTANCE_TYPE has two possible values, ASM and RDBMS, which represent ASM and a regular database instance, respectively.

SQL> show parameter instance_type

NAME TYPE VALUE

--------------------------- ----------- ----------------

instance_type string asm

Disks

ASM is no different. It also requires disks, but disks are allocated to ASM before they are striped and mirrored. ASM will perform its own striping by default and optional mirroring.

In other words, ASM has inherent automatic file-level striping and mirroring capabilities.

A disk can be a partition of a physical spindle, the entire spindle, or a RAID group set, depending on how the storage array presents the LUN to the operating system. Each operating system will have its own unique representation of SCSI disk naming. For example, on Solaris systems, the disks will generally have the following SCSI name format: CwTxDySz, where

“C” is the controller number, “T” is the target, “D” is the LUN/disk number, and “S” is the partition. Again, on Solaris systems, it is a best practice to create a partition on the disk, whereas on certain others it is not. In SAN environments, the disks are appropriately zoned or LUN masked within the SAN fabric and are visible to the operating system. Once disks have been identified, they need to be discovered by ASM. On Linux based systems, disks can be configured as direct raw devices or can be ASM aware using the ASMLIB utility.

When ASM scans for disks, it will use that string (listed below) and find any devices it has permission to open. Upon successful discovery, the V$ASM_DISK view on the ASM instance will list these disks.

Default ASM Disk Strings

Operating System Default Search String

Solaris /dev/rdsk/*

Windows \\.orcl:disk*

Linux (ASMLIB) ORCL:disk*

HPUX /dev/rdsk/*

HP Tru64 /dev/rdisk/*

AIX /dev/rhdisk/*

On successful completion of making the disks ASM aware, the next step is to group these disks into disk groups. Disk group configuration can be done in one of three ways:

1. Interactively from the ASM instance (command line)

2. During the database configuration process using the Database Configuration Assistant (DBCA)

3. Using Enterprise Manager (EM)

Disk groups are similar in concept to volume groups on traditional storage systems.

Best Practice: Ensure that the disks allocated to ASM have appropriate access rights (read/write) to all the databases and ASM instances.

Disk groups

After disks have been discovered by ASM, they can be grouped together for easy management and for Oracle to apply the SAME methodology (i.e., to stripe and mirror the disks). The disk group is the highest-level data structure in ASM and is analogous to the Logical Volume Manager (LVM) provided by several vendors, such as Veritas. However, unlike the LVM volume

groups, the ASM disk groups are not visible to the user. ASM disk groups are only visible to ASM and ASM clients, which include RDBMS instances, RMAN, the ASM command-line interface (asmcmd), and so on. Hence, all access to the Oracle files and other related data must be performed using an Oracle instance and using an Oracle-provided tool such as RMAN or SQL scripts.

How is the ASM instance aware of the disks that have been made ASM aware? Under all operating systems (using Oracle-provided ASM libraries or not), disks to be used by ASM should be made ASM aware. When using tools such as DBCA, disks are automatically discovered by the tool. However, when an ASM instance is manually created, this is achieved by assigning a search string to the ASM_DISKSTRING parameter that is part of the ASM instance.

For example, ASM_DISKSTRING= ‘ORCL:AVOL*’ indicates that all disk volumes with the AVOL suffix created using the Linux ASMLIB routines are candidates used to create disk groups

+ASM1.asm_diskstring='/dev/rdsk/p760*'

Note: Ensure that the ASM instance has been created and started before attempting to create disk groups. ASM instances can be created manually using scripts or using DBCA.

Best Practice: When configuring raw disks for ASM, make sure they are partitioned using utilities such as fdisk on Linux or idisk on HP-UX.The goal is to create one partition that comprises the entire disk.

Syntax create_diskgroup::=

The mirrored disks concept is called a failure group in ASM, the only difference being that mirroring is done at the file extent level and not at the disk level. As a result of this, ASM only uses the spare capacity of space available in existing disk groups instead of the traditional mirroring methods that required an additional hot spare disk. Under this method, when ASM allocates a primary extent of a file to one disk in a disk group, it allocates a mirror copy of that extent to another disk in the disk group.

REDUNDANCY Clause

The REDUNDANCY clause lets you specify the redundancy level of the disk group.

• NORMAL REDUNDANCY requires the existence of at least two failure groups (see the FAILGROUP clause that follows). Automatic Storage Management provides redundancy for all files in the disk group according to the attributes specified in the disk group templates. NORMAL REDUNDANCY disk groups can tolerate the loss of one group. Please refer to ALTERDISKGROUP ... diskgroup_template_clauses for more information on disk group templates.
• HIGH REDUNDANCY requires the existence of at least three failure groups. Automatic Storage Management fixes mirroring at 3-way mirroring, with each extent getting two mirrored copies. HIGH REDUNDANCY disk groups can tolerate the loss of two failure groups.
• EXTERNAL REDUNDANCY indicates that Automatic Storage Management does not provide any redundancy for the disk group. The disks within the disk group must provide redundancy (for example, using a storage array), or you must be willing to tolerate loss of the disk group if a disk fails (for example, in a test environment). You cannot specify the FAILGROUP clause if you specify EXTERNAL REDUNDANCY.

FAILGROUP Clause

Use this clause to specify a name for one or more failure groups. If you omit this clause, and you have specified NORMAL or HIGH REDUNDANCY, then Oracle Database automatically adds each disk in the disk group to its own failure group. The implicit name of the failure group is the same as the operating system independent disk name (see "NAME Clause").

You cannot specify this clause if you are creating an EXTERNAL REDUNDANCY disk group.

qualified_disk_clause

Specify DISK qualified_disk_clause to add a disk to a disk group.

search_string For each disk you are adding to the disk group, specify the operating system dependent search string that Automatic Storage Management will use to find the disk. The search_string must point to a subset of the disks returned by discovery using the strings in the ASM_DISKSTRING initialization parameter. If search_string does not point to any disks the Oracle Database user has read/write access to, then Automatic Storage Management returns an error. If it points to one or more disks that have already been assigned to a different disk group, then Oracle Database returns an error unless you also specify FORCE.

For each valid candidate disk, Automatic Storage Management formats the disk header to indicate that it is a member of the new disk group.

See Also:

The ASM_DISKSTRING initialization parameter for more information on specifying the search string

NAME Clause The NAME clause is valid only if the search_string points to a single disk. This clause lets you specify an operating system independent name for the disk. The name can be up to 30 alphanumeric characters. The first character must be alphabetic. If you omit this clause and you assigned a label to a disk through ASMLIB, then that label is used as the disk name. If you omit this clause and you did not assign a label through ASMLIB, then Automatic Storage Management creates a default name of the form diskgroup_name_####, where #### is the disk number. You use this name to refer to the disk in subsequent Automatic Storage Management operations.

SIZE Clause Use this clause to specify in bytes the size of the disk. If you specify a size greater than the capacity of the disk, then Automatic Storage Management returns an error. If you specify a size less than the capacity of the disk, then you limit the disk space Automatic Storage Management will use. If you omit this clause, then Automatic Storage Management attempts programmatically to determine the size of the disk.

FORCE Specify FORCE if you want Automatic Storage Management to add the disk to the disk group even if the disk is already a member of a different disk group.

Caution:

Using FORCE in this way may destroy existing disk groups.

For this clause to be valid, the disk must already be a member of a disk group and the disk cannot be part of a mounted disk group.

NOFORCE Specify NOFORCE if you want Automatic Storage Management to return an error if the disk is already a member of a different disk group. NOFORCE is the default.

Examples

The following example assumes that the ASM_DISKSTRING parameter is a superset of $ORACLE_HOME/disks/c*, $ORACLE_HOME/disks/c* points to at least one device to be used as an Automatic Storage Management disk, and the Oracle Database user has read/write permission to the disks.

See Also:

Oracle Database Administrator's Guide for information on Automatic Storage Management and using disk groups to simplify database administration

Creating a Diskgroup: Example The following statement creates an Automatic Storage Management disk group dgroup_01 where no redundancy for the disk group is provided by Automatic Storage Management and includes all disks that match the search_string:

CREATE DISKGROUP dgroup_01 EXTERNAL REDUNDANCY DISK '$ORACLE_HOME/disks/c*';

After the disk group is created, the metadata information, including the disk group name, redundancy type, and other creation details such as the creation date, is loaded into the SGA of the ASM instance and written to the appropriate disk headers within each disk group. Creating a new disk group also updates the parameter ASM_DISKGROUPS in the ASM instance.

SQL> show parameter asm_diskgroup

NAME TYPE VALUE

---------------------------- ----------- ------------------------------

asm_diskgroups string ASMGRP1, ASMGRP2

After the disk group is created, the metadata information, including the disk group name, redundancy type, and other creation details such as the creation date, is loaded into the SGA of the ASM instance and written to the appropriate disk headers within each disk group. Creating a new disk group also updates the parameter ASM_DISKGROUPS in the ASM instance.

While a disk can only be allocated to one disk group at a time, a disk group can contain datafiles from many different Oracle databases. Alternatively, a database can store datafiles in multiple disk groups of the same ASM instance.

Based on the disks that have been configured and allocated to a disk group, the header status of the disk changes. For example, the following query indicates the header status is MEMBER:

SQL> SELECT INST_ID,NAME,PATH,STATE,HEADER_STATUS FROM GV$ASM_DISK;

INST_ID NAME PATH STATE HEADER_STATUS

---------- ---------- ---------- -------- ------------

3 AVOL1 ORCL:AVOL1 NORMAL MEMBER

3 AVOL2 ORCL:AVOL2 NORMAL MEMBER

1 AVOL1 ORCL:AVOL1 NORMAL MEMBER

1 AVOL2 ORCL:AVOL2 NORMAL MEMBER

Disks have various header statuses that reflect their membership state with a disk group. Disks can have the following header statuses:

FORMER This state declares that the disk was formerly part of a disk group.

CANDIDATE When a disk is in this state, it is available to be added to a disk group.

MEMBER This state indicates that a disk is already part of a disk group.

PROVISIONED This state is similar to candidate in that the disk is available to disk groups. However, the provisioned state indicates that this disk has been configured or made available using ASMLIB.

Best Practice: Assign the entire disk to a disk group. Assigning multiple slices of the same disk to a disk group can cause significant performance issues.

Once a disk group is defined with a specific redundancy type, if this needs to be changed subsequently, another disk group needs to be created with the appropriate redundancy type, and data must be moved from the existing disk group to the new disk group using RMAN or the supplied PL/SQL package DBMS_FILE_TRANSFER.