12 Using Automatic Storage Management

Operating System Authentication for ASM

Using operating system authentication, the authorization to connect locally with the SYSDBA privilege is granted through the use of a special operating system user group, generically referred to as OSDBA. (On UNIX, OSDBA is typically the dba group.) See "Using Operating System Authentication" for more information about OSDBA.

By default, members of the OSDBA group are authorized to connect with the SYSDBA privilege on all instances on the node, including the ASM instance. Users who connect to the ASM instance with SYSDBA privilege have complete administrative access to all disk groups that are managed by that ASM instance.

Password File Authentication for ASM

To enable remote administration of ASM (through Oracle Net Services), a password file must be created for ASM. A password file is also required for Enterprise Manager to connect to ASM.

The Oracle Database Configuration Assistant (DBCA) creates a password file for ASM when it initially configures ASM disk groups. Like a database password file, the only user added to the password file upon creation is SYS. If you want to add other users to the password file, you must share the password file with a database instance and add the users with the database.

If you configure an ASM instance without using DBCA, you must create a password file yourself. See "Creating and Maintaining a Password File" for more information.

Initialization Parameters for ASM Instances

The following initialization parameters relate to an ASM instance. Parameters that start with ASM_ cannot be set in database instances.

/dev/rdsk/*

/dev/rdsk/*s3,/dev/rdsk/*s4

/dev/rdsk/*s[34]

Tuning Rebalance Operations

If the POWER clause is not specified in an ALTER DISKGROUP command, or when rebalance is implicitly invoked by adding or dropping a disk, the rebalance power defaults to the value of the ASM_POWER_LIMIT initialization parameter. You can adjust this parameter dynamically. The higher the limit, the faster a rebalance operation may complete. Lower values cause rebalancing to take longer, but consume fewer processing and I/O resources. This leaves these resources available for other applications, such as the database. The default value of 1 minimizes disruption to other applications. The appropriate value is dependent upon your hardware configuration as well as performance and availability requirements.

If a rebalance is in progress because a disk is manually or automatically dropped, increasing the power of the rebalance shortens the window during which redundant copies of that data on the dropped disk are reconstructed on other disks.

The V$ASM_OPERATION view provides information that can be used for adjusting ASM_POWER_LIMIT and the resulting power of rebalance operations. The V$ASM_OPERATION view also gives an estimate in the EST_MINUTES column of the amount of time remaining for the rebalance operation to complete. You can see the effect of changing the rebalance power by observing the change in the time estimate.

Improving Disk Discovery Time

The value for the ASM_DISKSTRING initialization parameter is an operating system–dependent value used by ASM to limit the set of paths that the discovery process uses to search for disks. When a new disk is added to a disk group, each ASM instance that has the disk group mounted must be able to discover the new disk using its ASM_DISKSTRING.

In many cases, the default value (NULL) is sufficient. Using a more restrictive value may reduce the time required for ASM to perform discovery, and thus improve disk group mount time or the time for adding a disk to a disk group. It may be necessary to dynamically change the ASM_DISKSTRING before adding a disk so that the new disk will be discovered through this parameter.

Note that the default value of ASM_DISKSTRING may not find all disks in all situations. If your site is using a third-party vendor ASMLib, that vendor may have discovery string conventions you must use for ASM_DISKSTRING. In addition, if your installation uses multipathing software, the software may place pseudo-devices in a path that is different from the operating system default. Consult the multipathing vendor documentation for details.

Behavior of Database Initialization Parameters in an ASM Instance

If you specify a database instance initialization parameter in an ASM initialization parameter file, it can have one of these effects:

• If the parameter is not valid in the ASM instance, it produces an ORA-15021 error.

• If the database parameter is valid in an ASM instance, for example parameters relating to dump destinations and some buffer cache parameters, ASM accepts the parameter. In general, ASM selects appropriate defaults for any database parameters that are relevant to the ASM instance.

Behavior of ASM Initialization Parameters in a Database Instance

If you specify any of the ASM-specific parameters (names starting with ASM_) in a database instance parameter file, you receive an ORA-15021 error.

ASM Instance Memory Requirements

ASM instances are smaller than database instances. A 64 MB SGA should be sufficient for all but the largest ASM installations. Total memory footprint for a typical ASM instance is approximately 100 MB.

CSS Requirement

The Cluster Synchronization Services (CSS) daemon is required to enable synchronization between ASM and its client database instances. The CSS daemon is normally started (and configured to start upon reboot) when you use Database Configuration Assistant (DBCA) to create your database. If you did not use DBCA to create the database, you must ensure that the CSS daemon is running before you start the ASM instance.

Disk Discovery

When an ASM instance initializes, ASM discovers and examines the contents of all of the disks that are in the paths designated in the ASM_DISKSTRING initialization parameter. For purposes of this discussion, a "disk" is an ASM disk as defined in "Overview of the Components of Automatic Storage Management". Disk discovery also takes place when you:

• Run the ALTER DISKGROUP...ADD DISK and ALTER DISKGROUP...RESIZE DISK commands.

• Query the V$ASM_DISKGROUP and V$ASM_DISK views.

After a disk is successfully discovered, it appears in the V$ASM_DISK view. Disks that belong to a disk group—that is, that have a disk group name in the disk header—have a header status of MEMBER. Disks that were discovered but that have not yet been assigned to a disk group have a header status of either CANDIDATE or PROVISIONED.

The following query shows six MEMBER disks and one CANDIDATE disk.

SQL> select name, header_status, path from v$asm_disk;
 
NAME         HEADER_STATUS PATH
------------ ------------- -------------------------
             CANDIDATE     /dev/rdsk/disk07
DISK06       MEMBER        /dev/rdsk/disk06
DISK05       MEMBER        /dev/rdsk/disk05
DISK04       MEMBER        /dev/rdsk/disk04
DISK03       MEMBER        /dev/rdsk/disk03
DISK02       MEMBER        /dev/rdsk/disk02
DISK01       MEMBER        /dev/rdsk/disk01
 
7 rows selected.

Discovery Rules

Rules for discovery are as follows:

• ASM discovers no more than 10,000 disks. That is, if more than 10,000 disks match the ASM_DISKSTRING initialization parameter, only the first 10,000 are discovered.

• ASM does not discover a disk that contains an operating system partition table, even if the disk is in an ASM_DISKSTRING search path and ASM has read/write permission on the disk.

• If ASM recognizes a disk header as that of an Oracle object, such as the header of an Oracle datafile, the disk is discovered, but can only be added to a disk group with the FORCE keyword. Such a disk appears in V$ASM_DISK with a header status of FOREIGN.

In addition, ASM identifies the following configuration errors during discovery:

• Multiple paths to the same disk

  In this case, if the disk is part of a disk group, disk group mount fails. If the disk is being added to a disk group with the ADD DISK or CREATE DISKGROUP command, the command fails. To correct the error, restrict ASM_DISKSTRING so that it does not include multiple paths to the same disk, or if you are using multipathing software, ensure that you include only the pseudo-device in ASM_DISKSTRING.

• Multiple ASM disks with the same disk header

  This can be caused by a bit copy of one disk onto another. In this case, disk group mount fails.

Disk Group Recovery

Like any other file system or volume manager, if an ASM instance fails, then all Oracle database instances on the same node as the ASM instance and that use a disk group managed by the ASM instance also fail. In a single ASM instance configuration, if the ASM instance fails while ASM metadata is open for update, then after the ASM instance reinitializes, it reads the disk group log and recovers all transient changes.

With multiple ASM instances sharing disk groups, if one ASM instance should fail, another ASM instance automatically recovers transient ASM metadata changes caused by the failed instance. The failure of an Oracle database instance is not significant here because only ASM instances update ASM metadata.

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.

Performance Characteristics when Grouping Disks

ASM eliminates the need for manual I/O 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.

ASM 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 is online.

Effects of Adding and Dropping Disks from a Disk Group

ASM automatically rebalances whenever disks are added or dropped. For a normal drop operation (without the FORCE option), 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.

For a drop operation, when rebalance is complete, ASM takes the disk offline momentarily, and then drops it, setting disk header status to FORMER.

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

How ASM Handles Disk Failures

Depending on the redundancy level of a disk group and how failure groups are defined, the failure of one or more disks could result in either of the following:

• The disks are first taken offline and then automatically dropped.

  The disk group remains mounted and serviceable, and, thanks to mirroring, all disk group data remains accessible. Following the disk drop, ASM performs a rebalance to restore full redundancy for the data on the failed disks.

• The entire disk group is automatically dismounted, which means loss of data accessibility.

Disk failure in this context means individual spindle failure or failure of another disk subsystem component, such as power supply, a controller, or host bus adapter. Here are the rules for how ASM handles disk failures:

• A failure group is considered to have failed if at least one disk in the failure group fails.

• A normal redundancy disk group can tolerate the failure of one failure group. If only one failure group fails, the disk group remains mounted and serviceable, and ASM performs a rebalance of the surviving disks (including the surviving disks in the failed failure group) to restore redundancy for the data in the failed disks. If more than one failure group fails, ASM dismounts the disk group.

• A high redundancy disk group can tolerate the failure of two failure groups. If one or two failure groups fail, the disk group remains mounted and serviceable, and ASM performs a rebalance of the surviving disks to restore redundancy for the data in the failed disks. If more than two failure groups fail, ASM dismounts the disk group.

• An external redundancy disk group cannot tolerate the failure of any disks in the disk group. Any kind of disk failure causes ASM to dismount the disk group.

When considering these rules, remember that if a disk is not explicitly assigned to a failure group with the CREATE DISKGROUP command, ASM puts the disk in its own failure group. Also, failure of one disk in a failure group does not affect the other disks in a failure group. For example, a failure group could consist of 6 disks connected to the same disk controller. If one of the 6 disks fails, the other 5 disks can continue to operate. The failed disk is dropped from the disk group and the other 5 remain in the disk group. Depending on the rules stated previously, the disk group may then remain mounted, or it may be dismounted.

When ASM drops a disk, the disk is not automatically added back to the disk group when it is repaired or replaced. You must issue an ALTER DISKGROUP...ADD DISK command to return the disk to the disk group. Similarly, when ASM automatically dismounts a disk group, you must issue an ALTER DISKGROUP...MOUNT command to remount the disk group.

Failure Groups and Mirroring

Mirroring of metadata and user data is achieved through failure 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. Here are some rules and guidelines for failure groups:

• Each disk in a disk group belongs to exactly one failure group.

• After a disk has been assigned to a failure group, it cannot be reassigned to another failure group. If it needs to be in another failure group, it can be dropped from the disk group and then added back. Because the choice of failure group depends on hardware configuration, a disk does not need to be reassigned unless it is physically moved.

• It is best if all failure groups are the same size. Failure groups of different sizes can lead to wasted disk space.

• ASM requires at least two failure groups to create a normal redundancy disk groups and at least three failure groups to create a high redundancy disk group. This implies that if you do not explicitly define failure groups, a normal redundancy disk group requires at least two disks, and a high redundancy disk group requires at least 3 disks.

• Most systems do not need to explicitly define failure groups. The default behavior of putting every disk in its own failure group works well for most installations. Failure groups are only needed for large, complex systems that need to protect against failures other than individual spindle failures.

• Choice of failure groups depends on the kinds of failures that need to be tolerated without loss of data availability. For small numbers of disks (fewer than 20) it is usually best to use default failure groups, where every disk is in its own failure group. This is true even for large numbers of disks when the main concern is spindle failure. If there is a need to protect against the simultaneous loss of multiple disk drives due to a single component failure, you can specify failure groups. For example, a disk group may be constructed from several small modular disk arrays. If the system needs to continue operation when an entire modular array fails, a failure group should consist of all the disks in one module. If one module fails, a rebalance occurs on the surviving modules to restore redundancy to the data that was on the failed module. You must place disks in the same failure group if they depend on a common piece of hardware whose failure needs to be tolerated with no loss of availability.

• Having a small number of large failure groups may actually reduce availability in some cases. For example, half the disks in a disk group could be on one power supply, while the other half are on a different power supply. If this is used to divide the disk group into two failure groups, tripping the breaker on one power supply could drop half the disks in the disk group. Restoring redundancy for data on the dropped disks would require copying all the data from the surviving disks. This can be done online, but consumes a lot of I/O and leaves the disk group unprotected against a spindle failure during the copy. However, if each disk were in its own failure group, the disk group would be dismounted when the breaker tripped (assuming that this caused more failure groups to fail than the disk group can tolerate). Resetting the breaker would allow the disk group to be manually remounted and no data copying would be needed.

Managing Capacity in Disk Groups

You must have sufficient spare capacity in each disk group to handle the largest failure that you are willing to tolerate. After one or more disks fail, the process of restoring redundancy for all data requires space from the surviving disks in the disk group. If not enough space remains, some files may end up with reduced redundancy.

Reduced redundancy means that one or more extents in the file are not mirrored at the expected level. For example, a reduced redundancy file in a high redundancy disk group has at least one file extent with two or fewer total copies of the extent instead of three. In the case of unprotected files, data extents could be missing altogether. Other causes of reduced redundancy files are disks running out of space or an insufficient number of failure groups. The V$ASM_FILE column REDUNDANCY_LOWERED indicates a file with reduced redundancy.

The following guidelines help ensure that you have sufficient space to restore full redundancy for all disk group data after the failure of one or more disks.

• In a normal redundancy disk group, it is best to have enough free space in your disk group to tolerate the loss of all disks in one failure group. The amount of free space should be equivalent to the size of the largest failure group.

• In a high redundancy disk group, it is best to have enough free space to cope with the loss of all disks in two failure groups. The amount of free space should be equivalent to the sum of the sizes of the two largest failure groups.

The V$ASM_DISKGROUP view contains columns that help you manage capacity:

• REQUIRED_MIRROR_FREE_MB indicates the amount of space that must be available in the disk group to restore full redundancy after the worst failure that can be tolerated by the disk group.

• USABLE_FILE_MB indicates the amount of free space, adjusted for mirroring, that is available for new files.

USABLE_FILE_MB is computed by subtracting REQUIRED_MIRROR_FREE_MB from total free space in the disk group and then adjusting for mirroring. For example, in a normal redundancy disk group, where by default mirrored files take up disk space equal to twice their size, if 4 GB of actual usable file space remains, USABLE_FILE_MB equals roughly 2 GB. You can then add up to a 2 GB file.

The following query shows capacity metrics for a normal redundancy disk group that consists of six 1 GB (1024 MB) disks, each in its own failure group:

select name, type, total_mb, free_mb, required_mirror_free_mb, 
usable_file_mb from v$asm_diskgroup;

NAME         TYPE     TOTAL_MB    FREE_MB REQUIRED_MIRROR_FREE_MB USABLE_FILE_MB
------------ ------ ---------- ---------- ----------------------- --------------
DISKGROUP1   NORMAL       6144       3768                    1024           1372

The REQUIRED_MIRROR_FREE_MB column shows that 1 GB of extra capacity must be available to restore full redundancy after one or more disks fail. Note that the first three numeric columns in the query results are raw numbers. That is, they do not take redundancy into account. Only the last column is adjusted for normal redundancy. Notice that:

FREE_MB - REQUIRED_MIRROR_FREE_MB = 2 * USABLE_FILE_MB

or

3768 - 1024 = 2 * 1372 = 2744

Negative Values of USABLE_FILE_MB Due to the relationship between FREE_MB, REQUIRED_MIRROR_FREE_MB, and USABLE_FILE_MB, USABLE_FILE_MB can go negative. Although this is not necessarily a critical situation, it does mean that:

• Depending on the value of FREE_MB, you may not be able to create new files.

• The next failure may result in files with reduced redundancy.

If USABLE_FILE_MB becomes negative, it is strongly recommended that you add more space to the disk group as soon as possible.

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

• Maximum files sizes as shown in the following table:

  Disk Group Type	Maximum File Size
  External redundancy	35 TB
  Normal redundancy	5.8 TB
  High redundancy	3.9 TB

  
  

Adding Disks to a Disk Group

You use the ADD clause of the ALTER DISKGROUP statement to 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. This is discussed in "Creating a Disk Group".

The new disks will gradually start to carry their share of the workload as rebalancing progresses.

ASM 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:

ALTER DISKGROUP dgroup1 ADD DISK
     '/devices/diska5' NAME diska5,
     '/devices/diska6' NAME diska6;

Because no FAILGROUP clauses are included in the ALTER DISKGROUP statement, each disk is assigned to its own failure group. 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 /devices:

On a server that runs Unix, Solaris, or Linux and that does not have ASMLib installed, issuing the following statement would successfully add disks /devices/diska5 through /devices/diska8 to dgroup1.

ALTER DISKGROUP dgroup1 ADD DISK
     '/devices/diska[5678]';

The following statement would successfully add disks /devices/diska5 and /devices/diskd5 to dgroup1.

ALTER DISKGROUP dgroup1 ADD DISK
     '/devices/disk*5';

The following statement would fail because /devices/diska1 - /devices/diska4 already belong to dgroup1.

ALTER DISKGROUP dgroup1 ADD DISK
     '/devices/diska*';

The following statement would fail because the search string matches disks that are contained in other disk groups. Specifically, /devices/diska4 belongs to disk group dgroup1 and /devices/diskb4 belongs to disk group dgroup2.

ALTER DISKGROUP dgroup1 ADD DISK
     '/devices/disk*4';

The following statement would successfully add /devices/diska5 and /devices/diskd1 through /devices/diskd8 to disk group dgroup1. It does not matter that /devices/diskd5 is included in both search strings. This statement runs with a rebalance power of 5, and does not return until the rebalance operation is complete.

ALTER DISKGROUP dgroup1 ADD DISK
      '/devices/disk*5',
      '/devices/diskd*'
       REBALANCE POWER 5 WAIT;

The following use of the FORCE clause enables /devices/diskc3 to be added to dgroup2, even though it is a current member of dgroup3.

ALTER DISKGROUP dgroup2 ADD DISK
     '/devices/diskc3' FORCE;

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. A drop disk operation may fail if not enough space is available on the other disks. If you intend to add some disks and drop others, it is prudent to add disks first to ensure that enough space is available for the drop operation. The best approach is to perform both the add and drop with the same ALTER DISKGROUP statement. This can reduce total time spent rebalancing.

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/diska5 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 drops diska5 from disk group dgroup1, and also illustrates how multiple actions are possible with one ALTER DISKGROUP statement.

ALTER DISKGROUP dgroup1 DROP DISK diska5
     ADD FAILGROUP failgrp1 DISK '/devices/diska9' NAME diska9;

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 ASM 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 failure group failgrp1 of disk group dgroup1. If the new size is greater than disk capacity, the statement will fail.

ALTER DISKGROUP dgroup1 
     RESIZE DISKS IN FAILGROUP failgrp1 SIZE 100G;

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, because ASM 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. A value of 0 halts a rebalancing operation until the statement is either implicitly or explicitly reinvoked. The default rebalance power is set by the ASM_POWER_LIMIT initialization parameter. See "Tuning Rebalance Operations" for more information.

The power level of an ongoing rebalance operation can be changed by entering the rebalance statement with a new level.

The ALTER DISKGROUP...REBALANCE command by default returns immediately so that you can issue other commands while the rebalance operation takes place asynchronously in the background. You can query the V$ASM_OPERATION view for the status of the rebalance operation.

If you want the ALTER DISKGROUP...REBALANCE command to wait until the rebalance operation is complete before returning, you can add the WAIT keyword to the REBALANCE clause. This is especially useful in scripts. The command also accepts a NOWAIT keyword, which invokes the default behavior of conducting the rebalance operation asynchronously. You can interrupt a rebalance running in wait mode by typing CTRL-C on most platforms. This causes the command to return immediately with the message ORA-01013: user requested cancel of current operation, and to continue the rebalance operation asynchronously.

Additional rules for the rebalance operation include the following:

• The ALTER DISKGROUP...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.

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

• The REBALANCE clause (with its associated POWER and WAIT/NOWAIT keywords) can also be used in ALTER DISKGROUP commands that add, drop, or resize disks.

Manually Rebalancing a Disk Group: Example The following example manually rebalances the disk group dgroup2. The command does not return until the rebalance operation is complete.

ALTER DISKGROUP dgroup2 REBALANCE POWER 5 WAIT;

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 Assuming no subdirectory exists under the directory +dgoup1/mydir, the following statement fails:

ALTER DISKGROUP dgroup1
     ADD DIRECTORY '+dgroup1/mydir/first_dir/second_dir';

Renaming a Directory

The RENAME DIRECTORY clause of the ALTER DISKGROUP statement enables you to rename a directory. System created directories (those containing system-generated 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;

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:

ALTER DISKGROUP dgroup1 ADD ALIAS '+dgroup1/mydir/second.dbf'
     FOR '+dgroup1/sample/datafile/mytable.342.3';

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.

ALTER DISKGROUP dgroup1 ADD ALIAS '+dgroup1/mydir/second.dbf'
     FOR '+dgroup1.342.3';

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:

ALTER DISKGROUP dgroup1 RENAME ALIAS '+dgroup1/mydir/datafile.dbf'
     TO '+dgroup1/payroll/compensation.dbf';

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 drops an alias:

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

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

ALTER DISKGROUP dgroup1 
     DROP ALIAS '+dgroup1/sample/datafile/mytable.342.3';