# Configuring the Components of Automatic Storage Management - Oracle 10g

This section starts by presenting a brief overview of the components of Automatic Storage Management and discusses some considerations and guidelines that you should be aware of as you configure your ASM instance. Then, specific operations that you use to configure and maintain the ASM instance are discussed.

If you have a database instance running and are actively using Automatic Storage Management, you can keep the database open and running while you reconfigure disk groups.

The SQL statements introduced in this section are only available in an ASM instance. You must first start the ASM instance.

The following topics are contained in this section:

• Considerations and Guidelines for Configuring an ASM Instance
• Creating a Disk Group
• Altering the Disk Membership of a Disk Group
• Mounting and Dismounting Disk Groups
• Managing Disk Group Templates
• Managing Disk Group Directories
• Managing Alias Names for ASM Filenames
• Dropping Files and Associated Aliases from a Disk Group
• Checking Internal Consistency of Disk Group Metadata
• Dropping Disk Groups

Considerations and Guidelines for Configuring an ASM Instance

The following are some considerations and guidelines to be aware of as you configure Automatic Storage Management.

Determining the Number of Disk Groups
The following criteria can help you determine the number of disk groups that you create:

• Disks in a given disk group should have similar size and performance characteristics. If you have several different types of disks in terms of size and performance, then it would be better to form several disk groups accordingly.
• For recovery reasons, you might feel more comfortable having separate disk groups for your database files and flash recovery area files. Using this approach, even with the loss of one disk group, the database would still be intact.

Storage Arrays and Automatic Storage Management

With Automatic Storage Management, the definition of the logical volumes of a storage array is critical to database performance. Automatic Storage Management cannot optimize database data placement when the storage array disks are subdivided or aggregated. Aggregating and subdividing the physical volumes of an array into logical volumes can hide the physical disk boundaries from Automatic Storage Management. Consequently, careful consideration of storage array configuration is required.

Consider Performance Characteristics when Grouping Disks

Automatic Storage Management eliminates the need for manual disk tuning. However, to ensure consistent performance, you should avoid placing dissimilar disks in the same disk group. For example, the newest and fastest disks might reside in a disk group reserved for the database work area, and slower drives could reside in a disk group reserved for the flash recovery area.

Automatic Storage Management load balances file activity by uniformly distributing file extents across all disks in a disk group. For this technique to be effective it is important that the disks used in a disk group be of similar performance characteristics.

There may be situations where it is acceptable to temporarily have disks of different sizes and performance co-existing in a disk group. This would be the case when migrating from an old set of disks to a new set of disks. The new disks would be added and the old disks dropped. As the old disks are dropped, their storage is migrated to the new disks while the disk group in online.

Effects of Adding and Dropping Disks from a Disk Group

Automatic Storage Management automatically rebalances--distributes file data evenly across all the disks of a disk group--whenever disks are added or dropped. ASM allocates files in such a way that rebalancing is not required when the number of disks is static. A disk is not released from a disk group until data is moved off of the disk through rebalancing. Likewise, a newly added disk cannot support its share of the I/O workload until rebalancing completes. It is more efficient to add or drop multiple disks at the same time so that they are rebalanced as a single operation. This avoids unnecessary movement of data.

You can add or drop disks without shutting down the database. However, a performance impact on I/O activity may result.

Failure Groups and Mirroring

Mirroring of metadata and user data is achieved through failure groups. ASM requires at least two failure groups for normal redundancy disk groups and at least three failure groups for high redundancy disk groups. System reliability can be hampered if an insufficient number of failure groups are provided. Consequently, failure group configuration is very important to creating a highly reliable system.

Scalability
ASM imposes the following limits:

• 63 disk groups in a storage system
• 10,000 ASM disks in a storage system
• 4 petabyte maximum storage for each ASM disk
• 40 exabyte maximum storage for each storage system
• 1 million files for each disk group
• 2.4 terabyte maximum storage for each file

Creating a Disk Group

You use the CREATE DISKGROUP statement to create disk groups. This statement enables you to assign a name to the disk group and to specify the disks that are to be formatted as ASM disks belonging to the disk group. You specify the disks as one or more operating system dependent search strings that Automatic Storage Management then uses to find the disks.

You can specify the disks as belonging to specific failure groups, and you can specify the redundancy level for the disk group. If you do not specify a disk as belonging to a failure group, that disk comprises its own failure group. The redundancy level can be specified as NORMAL REDUNDANCY or HIGH REDUNDANCY, as defined by the disk group templates. You can also specify EXTERNAL REDUNDANCY for external redundancy disk groups, which do not have failure groups. You might do this if you want to use storage array protection features instead.

Automatic Storage Management programmatically determines the size of each disk. If for some reason this is not possible, or if you want to restrict the amount of space used on a disk, you are able to specify a SIZE clause for each disk. Automatic Storage Management creates operating system independent names for the disks in a disk group that you can use to reference the disks in other SQL statements.

Optionally, you can provide your own name for a disk using the NAME clause. The ASM instance ensures that any disk being included in a disk group is addressable and usable. This requires reading the first block of the disk to determine if it already belongs in a disk group. If not, a header is written. It is not possible for a disk to be a member of multiple disk groups.

However, you can force a disk that is already a member of another disk group to become a member of the disk group you are creating by specifying the FORCEclause. For example, a disk with an ASM header might have failed temporarily, so that its header could not be cleared when it was dropped from its disk group. Once the disk is repaired, it is no longer part of any disk group, but it still has an ASM header. The FORCE flag is required to use the disk in a new disk group. The original disk group must not be mounted, and the disk must have a disk group header, otherwise the operation fails. Note that if you do this, you may cause another disk group to become unusable. If you specify NOFORCE, which is the default, you receive an error if you attempt to include a disk that already belongs to another disk group.

The CREATE DISKGROUP statement mounts the disk group for the first time, and adds the disk group name to the ASM_DISKGROUPS initialization parameter if a server parameter file is being used. If a text initialization parameter file is being used and you want the disk group to be automatically mounted at instance startup, then you must remember to add the disk group name to the ASM_DISKGROUPS initialization parameter before the next time that you shut down and restart the ASM instance.

Creating a Disk Group: Example

The following examples assume that the ASM_DISKSTRING is set to '/devices/*'. Assume the following:

• ASM disk discovery identifies the following disks in directory /devices.

• The disks diska1 - diska4 are on a separate SCSI controller from disks diskb1 - diskb4.

The following SQL*Plus session illustrates starting an ASM instance and creating a disk group named dgroup1.

In this example, dgroup1 is composed of eight disks that are defined as belonging to either failure group controller1 or controller2. Since NORMAL REDUNDANCY level is specified for the disk group, then Automatic Storage Management provides redundancy for all files created in dgroup1 according to the attributes specified in the disk group templates.

For example, in the system default template shown in the table in "Managing Disk Group Templates" on page 12-21, normal redundancy for the online redo log files (ONLINELOG template) is two-way mirroring. This means that when one copy of a redo log file extent is written to a disk in failure group controller1, a mirrored copy of the file extent is written to a disk in failure group controller2. You can see that to support normal redundancy level, at least two failure groups must be defined.

Since no NAME clauses are provided for any of the disks being included in the disk group, the disks are assigned the names of dgroup1_0001, dgroup1_0002, ...,dgroup1_0008.

Altering the Disk Membership of a Disk Group

At a later time after the creation of a disk group, you can change its composition by adding more disks, resizing disks, or dropping disks. You use clauses of the ALTER DISKGROUP statement to perform these actions. You can perform multiple operations with one ALTER DISKGROUP statement.

Automatic Storage Management automatically rebalances file extents when the composition of a disk group changes. Because rebalancing can be a long running operation, the ALTER DISKGROUP statement does not wait until the operation is complete before returning. To monitor progress of these long running operations, query the V$ASM_OPERATION dynamic performance view. Adding Disks to a Disk Group The ADD clause of the ALTER DISKGROUP statement lets you add disks to a disk group, or to add a failure group to the disk group. The ALTER DISKGROUP clauses that you can use when adding disks to a disk group are similar to those that can be used when specifying the disks to be included when initially creating a disk group. The new disks will gradually start to carry their share of the workload as rebalancing progresses. Automatic Storage Management behavior when adding disks to a disk group is best illustrated through examples. Adding Disks to a Disk Group: Example 1 The following statement adds disks to dgroup1: Since no FAILGROUP clauses are included in the ALTER DISKGROUP statement, each disk is assigned to its own failgroup. The NAME clauses assign names to the disks, otherwise they would have been assigned system generated names. Adding Disks to a Disk Group: Example 2 The statements presented in this example demonstrate the interactions of disk discovery with the ADD DISK operation. Assume that disk discovery now identifies the following disks in directory Issuing the following statement adds disks /devices/diska5 -/devices/diska8 to dgroup1. It ignores /devices/diska1 -/devices/diska4 because they already belong to dgroup1, but does not fail because the other disks that match the search string are not already members of any other disk group. The following statement will fail, since the /devices/diska2 search string only matches a disk that already belongs to dgroup1: ALTER DISKGROUP dgroup1 ADD DISK '/devices/diska2', '/devices/diskd4'; The following statement to add disks to dgroup1 will fail because the search string matches a disk that is contained in another disk group. Specifically, The following statement succeeds in adding /devices/diskc4 and /devices/diskd1 - /devices/diskd4 to disk group dgroup1. It does not matter that /devices/diskd4 is included in both search strings (or that /devices/diska4 and /devices/diskb4 are already members of dgroup1). The following use of the FORCE clause allows /devices/diskc3 to be added to dgroup2, even though it is a current member of dgroup3. For this statement to succeed, dgroup3 cannot be mounted. Dropping Disks from Disk Groups To drop disks from a disk group, use the DROP DISK clause of the ALTER DISKGROUP statement. You can also drop all of the disks in specified failure groups using the DROP DISKS IN FAILGROUP clause. When a disk is dropped, the disk group is rebalanced by moving all of the file extents from the dropped disk to other disks in the disk group. The header on the dropped disk is cleared. If you specify the FORCE clause for the drop operation, the disk is dropped even if Automatic Storage Management cannot read or write to the disk. You cannot use the FORCE flag when dropping a disk from an external redundancy disk group. Dropping Disks from Disk Groups: Example 1 This example drops diska5 (the operating system independent name assigned to /devices/c0t4d0s2 in "Adding Disks to a Disk Group: Example 1") from disk group dgroup1. ALTER DISKGROUP dgroup1 DROP DISK diska5; Dropping Disks from Disk Groups: Example 2 This example also shows dropping diska5 from disk group dgroup1, but it illustrates how multiple actions are possible with one ALTER DISKGROUP statement. Resizing Disks in Disk Groups The RESIZE clause of ALTER DISKGROUP enables you to perform the following operations: • Resize all disks in the disk group • Resize specific disks • Resize all of the disks in a specified failure group If you do not specify a new size in the SIZE clause then Automatic Storage Management uses the size of the disk as returned by the operating system. This could be a means of recovering disk space when you had previously restricted the size of the disk by specifying a size smaller than disk capacity. The new size is written to the ASM disk header record and if the size of the disk is increasing, then the new space is immediately available for allocation. If the size is decreasing, rebalancing must relocate file extents beyond the new size limit to available space below the limit. If the rebalance operation can successfully relocate all extents, then the new size is made permanent, otherwise the rebalance fails. Resizing Disks in Disk Groups: Example The following example resizes all of the disks in failgroup failgrp1 of disk group dgroup1. If the new size is greater than disk capacity, the statement will fail. Undropping Disks in Disk Groups The UNDROP DISKS clause of the ALTER DISKGROUP statement enables you to cancel all pending drops of disks within disk groups. If a drop disk operation has already completed, then this statement cannot be used to restore it. This statement cannot be used to restore disks that are being dropped as the result of a DROP DISKGROUP statement, or for disks that are being dropped using the FORCE clause. Undropping Disks in Disk Groups: Example The following example cancels the dropping of disks from disk group dgroup1: ALTER DISKGROUP dgroup1 UNDROP DISKS; Manually Rebalancing a Disk Group You can manually rebalance the files in a disk group using the REBALANCE clause of the ALTER DISKGROUP statement. This would normally not be required, since Automatic Storage Management automatically rebalances disk groups when their composition changes. You might want to do a manual rebalance operation if you want to control the speed of what would otherwise be an automatic rebalance operation. The POWER clause of the ALTER DISKGROUP ... REBALANCE statement specifies the degree of parallelization, and thus the speed of the rebalance operation. It can be set to a value from 0 to 11, where a value of 0 stops rebalancing and a value of 11 (the default) causes rebalancing to occur as fast as possible. The power level of an ongoing rebalance operation can be changed by entering the rebalance statement with a new level. If you specify a power level of 0, rebalancing is halted until the statement is either implicitly or explicitly reinvoked. The dynamic initialization parameter ASM _POWER _LIMIT specifies a limit on the degree of parallelization for rebalance operations. Even if you specify a higher value in the POWER clause, the degree of parallelization will not exceed the value specified by the ASM _POWER _LIMIT parameter. The ALTER DISK GROUP ... REBALANCE statement uses the resources of the single node upon which it is started. ASM can perform one rebalance at a time on a given instance. The rebalance power is constrained by the value of the ASM_POWER_LIMIT initialization parameter. You can query the V$ASM_OPERATION view for help adjusting ASM_POWER_LIMIT and the resulting power of rebalance operations. If the DESIRED_POWER column value is less than the ACTUAL_POWER column value for a given rebalance operation, then ASM_POWER_LIMIT is impacting the rebalance. The EST_MINUTES column indicates the amount of time remaining for the operation to complete. You can see the effect of changing the power of rebalance by observing the change in the time estimate.

Rebalancing continues across a failure of the ASM instance performing the rebalance.

Manually Rebalancing a Disk Group: Example

The following example manually rebalances the disk group dgroup2:

ALTER DISKGROUP dgroup2 REBALANCE POWER 5;

Mounting and Dismounting Disk Groups

Disk groups that are specified in the ASM_DISKGROUPS initialization parameter are mounted automatically at ASM instance startup. This makes them available to all database instances running on the same node as Automatic Storage Management. The disk groups are dismounted at ASM instance shutdown. Automatic Storage Management also automatically mounts a disk group when you initially create it, and dismounts a disk group if you drop it.

There may be times that you want to mount or dismount disk groups manually. For these actions use the ALTER DISKGROUP ... MOUNT or ALTER DISKGROUP ... DISMOUNT statement. You can mount or dismount disk groups by name, or specify ALL. If you try to dismount a disk group that contains open files, the statement will fail, unless you also specify the FORCE clause.

Dismounting Disk Groups: Example

The following statement dismounts all disk groups that are currently mounted to the ASM instance:

ALTER DISKGROUP ALL DISMOUNT;

Mounting Disk Groups: Example

The following statement mounts disk group dgroup1:

ALTER DISKGROUP dgroup1 MOUNT;

Managing Disk Group Templates

A template is a named collection of attributes that are applied to files created within a disk group. Oracle provides a set of initial system default templates that Automatic Storage Management associates with a disk group when it is created. The table that follows lists the system default templates and the attributes they apply to the various file types that Automatic Storage Management supports.

You can add new templates to a disk group, change existing ones, or drop templates using clauses of the ALTER DISKGROUP statement. The V$ASM_TEMPLATE view lists all of the templates known to the ASM instance. Automatic Storage Management System Default File Group Templates Adding Templates to a Disk Group To add a new template for a disk group use the ADD TEMPLATE clause of the ALTER DISKGROUP statement. You specify the name of the template, its redundancy attributes, and its striping attribute. Adding Templates to a Disk Group: Example 1 The following statement creates a new template named reliable: ALTER DISKGROUP dgroup2 ADD TEMPLATE reliable ATTRIBUTES (MIRROR FINE); This statement creates a template that applies the following attributes to files: Modifying a Disk Group Template The ALTER TEMPLATE clause of the ALTER DISKGROUP statement enables you to modify the attribute specifications of an existing system default or user-defined disk group template. Only specified template properties are changed. Unspecified properties retain their current value. When you modify an existing template, only new files created by the template will reflect the attribute changes. Existing files maintain their attributes. Modifying a Disk Group Template: Example The following example changes the striping attribute specification of the reliable template for disk group dgroup2. ALTER DISKGROUP dgroup2 ALTER TEMPLATE reliable ATTRIBUTES (COARSE); Dropping Templates from a Disk Group Use the DROP TEMPLATE clause of the ALTER DISKGROUP statement to drop one or more templates from a disk group. You can only drop templates that are user-defined; you cannot drop system default templates. Dropping Templates from a Disk Group: Example This example drops the previously created unprotected template for dgroup2: ALTER DISKGROUP dgroup2 DROP TEMPLATE unreliable; Managing Disk Group Directories Every ASM disk group contains a hierarchical directory structure consisting of the fully qualified names of the files in the disk group, along with alias filenames. A fully qualified filename, also called a system alias, is always generated automatically by Automatic Storage Management when a file is created. You can create an additional (more user-friendly) alias for each ASM filename during file creation. You can also create an alias for an existing filename using clauses of the ALTER DISKGROUP statement as described in "Managing Alias Names for ASM Filenames". But you must first create a directory structure to support whatever alias file naming convention you choose to use. This section describes how to use the ALTER DISKGROUP statement to create a directory structure for alias filenames. It also describes how you can rename a directory or drop a directory. Creating a New Directory Use the ADD DIRECTORY clause of the ALTER DISKGROUP statement to create a hierarchical directory structure for alias names for ASM files. Use the slash character (/) to separate components of the directory path. The directory path must start with the disk group name, preceded by a plus sign (+), followed by any subdirectory names of your choice. The parent directory must exist before attempting to create a subdirectory or alias in that directory. Creating a New Directory: Example 1 The following statement creates a hierarchical directory for disk group dgroup1, which can contain, for example, the alias name +dgroup1/mydir/control_file1: ALTER DISKGROUP dgroup1 ADD DIRECTORY '+dgroup1/mydir'; Creating a New Directory: Example 2 Assume no subdirectory exists under the directory +dgoup1/mydir, then the following statement will fail: Renaming a Directory The RENAME DIRECTORY clause of the ALTER DISKGROUP statement enables you to rename a directory. System created directories (those containing system alias names) cannot be renamed. Renaming a Directory: Example The following statement renames a directory: ALTER DISKGROUP dgroup1 RENAME DIRECTORY '+dgroup1/mydir' TO '+dgroup1/yourdir'; Dropping a Directory You can delete a directory using the DROP DIRECTORY clause of the ALTER DISKGROUP statement. You cannot drop a system created directory. You cannot drop a directory containing alias names unless you also specify the FORCE clause. Dropping a Directory: Example This statement deletes a directory along with its contents: ALTER DISKGROUP dgroup1 DROP DIRECTORY '+dgroup1/yourdir' FORCE; Managing Alias Names for ASM Filenames After you have created the hierarchical directory structure for alias names, you can create alias names in the disk group. Alias names are intended to provide a more user-friendly means of referring to ASM files, rather than using the fully qualified names (system aliases) that Automatic Storage Management always generates when it creates a file. As mentioned earlier, these alias names can be created when the file is created in the database, or by adding an alias or renaming existing alias names using the ADD ALIAS or RENAME ALIAS clauses of the ALTER DISKGROUP statement. You delete an alias using the DROP ALIAS clause. You cannot delete or rename a system alias. The V$ASM_ALIAS view contains a row for every alias name known to the ASM instance. It contains a column, SYSTEM_CREATED, that specifies if the alias is system generated

Adding an Alias Name for an ASM Filename

Use the ADD ALIAS clause of the ALTER DISKGROUP statement to create an alias name for an ASM filename. The alias name must consist of the full directory path and the alias itself.

Adding an Alias Name for an ASM Filename: Example 1 The following statement adds a new alias name for a system generated file name:

Adding an Alias Name for as ASM Filename: Example 2 This statement illustrates another means of specifying the ASM filename for which the alias is to be created. It uses the numeric form of the ASM filename, which is an abbreviated and derived form of the system generated filename.

Renaming an Alias Name for an ASM Filename

Use the RENAME ALIAS clause of the ALTER DISKGROUP statement to rename an alias for an ASM filename. The old and the new alias names must consist of the full directory paths of the alias names.

Renaming an Alias Name for an ASM Filename: Example The following statement renames an alias:

Dropping an Alias Name for an ASM Filename

Use the DROP ALIAS clause of the ALTER DISKGROUP statement to drop an alias for an ASM filename. The alias name must consist of the full directory path and the alias itself. The underlying file to which the alias refers is unchanged.

Dropping an Alias Name for an ASM Filename: Example 1

The following statement deletes an alias:

ALTER DISKGROUP dgroup1 DELETE ALIAS '+dgroup1/payroll/compensation.dbf';

Dropping an Alias Name for an ASM Filename: Example 2 The following statement will fail because it attempts to delete a system alias. This is not allowed:

Dropping Files and Associated Aliases from a Disk Group

You can delete ASM files and their associated alias names from a disk group using the DROP FILE clause of the ALTER DISKGROUP statement. You must use a fully qualified filename, a numeric filename, or an alias name when specifying the file that you want to delete. Some reasons why you might need to delete files include:

• Files created using aliases are not Oracle-managed files. Consequently, they are not automatically deleted.
• A point in time recovery of a database might restore the database to a time before a tablespace was created. The restore does not delete the tablespace, but there is no reference to the tablespace (or its datafile) in the restored database. You can manually delete the datafile.

Dropping an alias does not drop the underlying file on the file system.

Dropping Files and Associated Aliases from a Disk Group: Example 1

The following statement uses the alias name for the file to delete both the file and the alias:

ALTER DISKGROUP dgroup1 DROP FILE '+dgroup1/payroll/compensation.dbf';

Dropping Files and Associated Aliases from a Disk Group: Example 2

In this example the system generated filename is used to drop the file and any associated alias:

Checking Internal Consistency of Disk Group Metadata

You can check the internal consistency of disk group metadata using the ALTER DISKGROUP ... CHECK statement. Checking can be specified for specific files in a disk group, specific disks or all disks in a disk group, or specific failure groups within a disk group. The disk group must be mounted in order to perform these checks.

If any errors are detected, an error message is displayed and details of the errors are written to the alert log. Automatic Storage Management attempts to correct any errors, unless you specify the NOREPAIR clause in your ALTER DISKGROUP ... CHECK statement.

The following statement checks for consistency in the metadata for all disks in the dgroup1 disk group:

ALTER DISKGROUP dgroup1 CHECK ALL;

Dropping Disk Groups

The DROP DISKGROUP statement enables you to delete an ASM disk group and optionally, all of its files. You can specify the INCLUDING CONTENTS clause if you want any files that may still be contained in the disk group also to be deleted. The default is EXCLUDING CONTENTS, which provides syntactic consistency and prevents you from dropping the diskgroup if it has any contents

The ASM instance must be started and the disk group must be mounted with none of the disk group files open, in order for the DROP DISKGROUP statement to succeed. The statement does not return until the disk group has been dropped.

When you drop a disk group, Automatic Storage Management dismounts the disk group and removes the disk group name from the ASM_DISKGROUPS initialization parameter if a server parameter file is being used. If a text initialization parameter file is being used, and the disk group is mentioned in the ASM_DISKGROUPS initialization parameter, then you must remember to remove the disk group name from the ASM_DISKGROUPS initialization parameter before the next time that you shut down and restart the ASM instance.

The following statement deletes dgroup1:

DROP DISKGROUP dgroup1;

After ensuring that none of the files contained in dgroup1 are open, Automatic Storage Management rewrites the header of each disk in the disk group to remove ASM formatting information. The statement does not specify INCLUDING CONTENTS, so the drop operation will fail if the diskgroup contains any files.