Skip Headers
Oracle® Database Administrator's Guide
10g Release 2 (10.2)

B14231-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
Next
PDF · Mobi · ePub

12 Using Automatic Storage Management

This chapter discusses some of the concepts behind Automatic Storage Management and describes how to use it. It contains the following topics:

What Is Automatic Storage Management?

Automatic Storage Management (ASM) is an integrated file system and volume manager expressly built for Oracle database files. ASM provides the performance of raw I/O with the easy management of a file system. It simplifies database administration by eliminating the need for you to directly manage potentially thousands of Oracle database files. It does this by enabling you to divide all available storage into disk groups. You manage a small set of disk groups and ASM automates the placement of the database files within those disk groups.

In the SQL statements that you use for creating database structures such as tablespaces, control files, and redo and archive log files, you specify file location in terms of disk groups. ASM then creates and manages the associated underlying files for you.

Mirroring and Striping

ASM extends the power of Oracle-managed files. With Oracle-managed files, files are created and managed automatically for you, but with ASM you get the additional benefits of features such as mirroring and striping.

ASM divides files into 1 MB extents and spreads each file's extents evenly across all disks in the disk group. This optimizes performance and disk utilization, making manual I/O performance tuning unnecessary.

ASM mirroring is more flexible than operating system mirrored disks because ASM mirroring enables the redundancy level to be specified on a per-file basis. Thus two files can share the same disk group with one file being mirrored while the other is not. Mirroring takes place at the extent level. If a file is mirrored, depending upon redundancy level set for the file, each extent has one or more mirrored copies, and mirrored copies are always kept on different disks in the disk group. Table 12-1 describes the three mirroring options that ASM supports on a per-file basis.

Table 12-1 ASM Mirroring Options

Mirroring Option Description

2-way mirroring

Each extent has 1 mirrored copy.

3-way mirroring

Each extent has 2 mirrored copies.

Unprotected

ASM provides no mirroring. Used when mirroring is provided by the disk subsystem itself.


Dynamic Storage Configuration

ASM enables you to change the storage configuration without having to take the database offline. It automatically rebalances—redistributes file data evenly across all the disks of the disk group—after you add disks to or drop disks from a disk group.

Should a disk failure occur, ASM automatically rebalances to restore full redundancy for files that had extents on the failed disk. When you replace the failed disk with a new disk, ASM rebalances the disk group to spread data evenly across all disks, including the replacement disk.

Interoperability with Existing Databases

ASM does not eliminate any existing database functionality. Existing databases using file systems or with storage on raw devices can operate as they always have. New files can be created as ASM files while existing ones are administered as before. Databases can have a mixture of ASM files and non-ASM files.

ASM Instance

ASM is implemented as a special kind of Oracle instance, with its own System Global Area (SGA) and background processes. The ASM instance typically has a much smaller SGA than a database instance.

Single Instance and Clustered Environments

Each database server that has database files managed by ASM needs to be running an ASM instance. A single ASM instance can service one or more single-instance databases on a stand-alone server. Each ASM disk group can be shared among all the databases on the server.

In a clustered environment, each node runs an ASM instance, and the ASM instances communicate with each other on a peer-to-peer basis. This is true for both Real Application Clusters (RAC) environments, and non-RAC clustered environments where multiple single-instance databases across multiple nodes share a clustered pool of storage that is managed by ASM. If a node is part of a Real Application Clusters (RAC) system, the peer-to-peer communications service is already installed on that server. If the node is part of a cluster where RAC is not installed, the Oracle Clusterware, Cluster Ready Services (CRS), must be installed on that node.

An ASM instance on a node in a cluster can manage storage simultaneously for one or more RAC database instances and one or more single instance databases.

See Also:

Oracle Database Concepts for an overview of Automatic Storage Management

Overview of the Components of Automatic Storage Management

The components of Automatic Storage Management (ASM) are disk groups, disks, failure groups, files, and templates.

Disk Groups

The primary component of ASM is the disk group. A disk group consists of a grouping of disks that are managed together as a unit. You configure ASM by creating disk groups to store database files. Oracle provides SQL statements that create and manage disk groups, their contents, and their metadata.

The disk group type determines the levels of mirroring that files in the disk group can be created with. You specify disk group type when you create the disk group. Table 12-2 lists ASM disk group types, their supported mirroring levels, and their default mirroring levels. The default mirroring level indicates the mirroring level that a file is created with unless you designate a different mirroring level. (See Templates, later in this section.)

Table 12-2 Mirroring Options for Each Disk Group Type

Disk Group Type Supported Mirroring Levels Default Mirroring Level

Normal redundancy


2-way
3-way
Unprotected (none)

2-way

High redundancy

3-way

3-way

External redundancy

Unprotected (none)

Unprotected


If you do not specify a disk group type (redundancy level) when you create a disk group, the disk group defaults to normal redundancy.

As Table 12-2 indicates, files in a high redundancy disk group are always 3-way mirrored, files in an external redundancy disk group have no ASM mirroring, and files in a normal redundancy disk group can be 2-way or 3-way mirrored or unprotected, with 2-way mirroring as the default. Mirroring level for each file is set by templates, which are described later in this section.

Disks

The disks in a disk group are referred to as ASM disks. On Windows operating systems, an ASM disk is always a partition. On all other platforms, an ASM disk can be:

Note:

Although you can also present a volume (a logical collection of disks) for management by ASM, it is not recommended to run ASM on top of another host-based volume manager.

When an ASM instance starts, it automatically discovers all available ASM disks. Discovery is the process of determining every disk device to which the ASM instance has been given I/O permissions (by some operating system mechanism), and of examining the contents of the first block of such disks to see if they are recognized as belonging to a disk group. ASM discovers disks in the paths that are listed in an initialization parameter, or if the parameter is NULL, in an operating system–dependent default path.

Failure Groups

Failure groups define ASM disks that share a common potential failure mechanism. An example of a failure group is a set of SCSI disks sharing the same SCSI controller. Failure groups are used to determine which ASM disks to use for storing redundant copies of data. For example, if two-way mirroring is specified for a file, ASM automatically stores redundant copies of file extents in separate failure groups. Failure groups apply only to normal and high redundancy disk groups. You define the failure groups in a disk group when you create or alter the disk group.

Description of admin070.gif follows
Description of the illustration admin070.gif

Files

Files written on ASM disks are ASM files, whose names are automatically generated by ASM. You can specify user-friendly alias names (or just aliases) for ASM files, and you can create a hierarchical directory structure for these aliases. Each ASM file is completely contained within a single disk group, and is evenly spaced over all of the ASM disks in the disk group.

Templates

Templates are collections of file attribute values, and are used to set mirroring and striping attributes of each type of database file (datafile, control file, redo log file, and so on) created in ASM disk groups. Each disk group has a default template associated with each file type. See "Managing Disk Group Templates" for more information.

You can also create your own templates to meet unique requirements. You can then include a template name when creating a file, thereby assigning desired attributes on an individual file basis rather than on the basis of file type. See "About ASM Filenames" for more information.

Administering an Automatic Storage Management Instance

Administering an Automatic Storage Management (ASM) instance is similar to managing a database instance, but with fewer tasks. An ASM instance does not require a database instance to be running for you to administer it.

You can perform all ASM administration tasks with SQL*Plus.

Note:

To administer ASM with SQL*Plus, you must set the ORACLE_SID environment variable to the ASM SID before you start SQL*Plus. If ASM and the database have different Oracle homes, you must also set the ORACLE_HOME environment variable to point to the ASM Oracle home. Depending on platform, you may have to change other environment variables as well. See "Selecting an Instance with Environment Variables" for more information.

The default ASM SID for a single instance database is +ASM, and the default SID for ASM on Real Application Clusters nodes is +ASMnode#.

You can also use Oracle Enterprise Manager (EM) or the Database Configuration Assistant (DBCA) for configuring and altering disk groups. DBCA eases the configuration and creation of your database while EM provides an integrated graphical approach for managing both your ASM instance and database instance. See Appendix A of Oracle Database 2 Day DBA for instructions on administering an ASM instance with EM.

This section contains the following topics:

See Also:

Oracle Database 2 Day DBA for information on administering ASM with Enterprise Manager.

Installing ASM

Because ASM is integrated into the database server, you use the Oracle Universal Installer (OUI) and the Database Configuration Assistant (DBCA) to install and initially configure it. OUI has options to either install and configure a database that uses ASM for storage management, or to install and configure an ASM instance by itself, without creating a database instance. Refer to the Oracle Database Installation Guide for your operating system for details on installing ASM.

ASM Installation Tips

Keep the following in mind when installing ASM:

  • When running more than one database instance on a single server or node, it is recommended that you install ASM in its own Oracle home on that server or node. This is advisable even if you are running only one database instance but plan to add one or more database instances to the server or node in the future.

    With separate Oracle homes, you can upgrade and patch ASM and databases independently, and you can deinstall database software without impacting the ASM instance.

    If an ASM instance does not already exist and you select the OUI option to install and configure ASM only, OUI installs ASM in its own Oracle home.

  • If you are running a single database instance on a server or node and have no plans to add one or more database instances to this server or node, ASM and the database can share a single Oracle home

    If an ASM instance does not already exist and you select the OUI option to create a database that uses ASM for storage, OUI creates this single-home configuration.

  • When you install ASM in a single-instance configuration, DBCA creates a separate server parameter file (SPFILE) and password file for the ASM instance.

  • When installing ASM in a clustered environment where the ASM Oracle home is shared among all nodes, DBCA creates an SPFILE for ASM. In a clustered environment without a shared ASM Oracle home, DBCA installs a text initialization parameter file (PFILE) for ASM on each node.

  • Before installing ASM, you may want to install the ASM support library, ASMLib. ASMLib is an application program interface (API) developed by Oracle to simplify the operating system–to-database interface, and to exploit the capabilities and strengths of vendors' storage arrays. The purpose of ASMLib, which is an optional add-on to ASM, is to provide an alternative interface for the ASM-enabled kernel to discover and access block devices. It provides storage and operating system vendors the opportunity to supply extended storage-related features. These features provide benefits such as improved performance and greater data integrity.

    See the ASM page of the Oracle Technology Network web site at http://www.oracle.com/technology/products/database/asm for more information on ASMLib. To download ASMLib for Linux, go to http://www.oracle.com/technology/tech/linux/asmlib.

Authentication for Accessing an ASM Instance

ASM security considerations derive from the fact that a particular ASM instance is tightly bound to one or more database instances operating on the same server. In effect, the ASM instance is a logical extension of these database instances. Both the ASM instance and the database instances must have equivalent operating system access rights (read/write) to the disk group member disks. For UNIX this is typically provided through shared UNIX group membership. See the Oracle Database Installation Guide for your operating system for information on how to ensure that the ASM and database instances have the proper access to member disks.

ASM instances do not have a data dictionary, so the only way to connect to one is as an administrator. This means that you use operating system authentication and connect as SYSDBA, or when connecting remotely through Oracle Net Services, you use a password file.

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.

Note:

The user that is the software owner for the database Oracle home (typically, the user named oracle) must be a member of the OSDBA group defined for the ASM Oracle home. This is automatically the case when ASM and a single instance of Oracle Database share the same Oracle home. If you install the ASM and database instances in separate Oracle homes, you must ensure that you configure the proper group memberships, otherwise the database instance will not be able to connect to the 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.

Setting Initialization Parameters for an ASM Instance

The ASM instance has its own initialization parameter file, which, like that of the database instance, can be a server parameter file (SPFILE) or a text file.

Note:

For ASM installations in clustered environments, server parameter files (SPFILEs) are not used unless there is a shared ASM Oracle home. Without a shared ASM Oracle home, each ASM instance gets its own text initialization parameter file (PFILE).

The ASM parameter file name is distinguished from the database file name by the SID embedded in the name. (The SID for ASM defaults to +ASM for a single-instance database and +ASMnode# for Real Application Clusters nodes.) The same rules for file name, default location, and search order that apply to the database initialization parameter file apply to the ASM initialization parameter file. Thus, on single-instance Unix platforms, the server parameter file for ASM would have the following path:

$ORACLE_HOME/dbs/spfile+ASM.ora

For more information about initialization parameter files, see "Understanding Initialization Parameters".

Some initialization parameters are specifically relevant to an ASM instance. Of those initialization parameters intended for a database instance, only a few are relevant to an ASM instance. You can set those parameters at database creation time using Database Configuration Assistant or later using Enterprise Manager. The remainder of this section describes setting the parameters manually by editing the initialization parameter file.

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.

Name Description
INSTANCE_TYPE Must be set to ASM

Note: This is the only required parameter. All other parameters take suitable defaults for most environments.

ASM_POWER_LIMIT The default power for disk rebalancing.

Default: 1, Range: 0 – 11

See Also: "Tuning Rebalance Operations"

ASM_DISKSTRING A comma-separated list of strings that limits the set of disks that ASM discovers. May include wildcard characters. Only disks that match one of the strings are discovered. String format depends on the ASM library in use and on the operating system. The standard system library for ASM supports glob pattern matching.

For example, on a Solaris server that does not use ASMLib, to limit discovery to disks that are in the /dev/rdsk/ directory, ASM_DISKSTRING would be set to:

/dev/rdsk/*

Note that the asterisk cannot be omitted. To limit discovery to disks in this directory that have a name that ends in s3 or s4, ASM_DISKSTRING would be set to:

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

This could be simplified to:

/dev/rdsk/*s[34]

The ? character, when used as the first character of a path, expands to the Oracle home directory. Depending on operating system, when the ? character is used elsewhere in the path, it is a wildcard for a single character.

Default: NULL. A NULL value causes ASM to search a default path for all disks in the system to which the ASM instance has read/write access. The default search path is platform-specific. See the Oracle Database Administrator's Reference for UNIX Systems on OTN for a list of default search paths for Unix platforms. For the Windows platform, the default search path is \\.\ORCLDISK*. See the Oracle Database Installation Guide for Windows or the Real Application Clusters Quick Installation Guide for Oracle Database Standard Edition for Windows for more information.

See Also: "Improving Disk Discovery Time"

ASM_DISKGROUPS A list of the names of disk groups to be mounted by an ASM instance at startup, or when the ALTER DISKGROUP ALL MOUNT statement is used.

Default: NULL (If this parameter is not specified, then no disk groups are mounted.)

This parameter is dynamic, and if you are using a server parameter file (SPFILE), you should not need to manually alter this value. ASM automatically adds a disk group to this parameter when the disk group is successfully created or mounted, and automatically removes a disk group from this parameter when the disk group is dropped or dismounted. However, when using a text initialization parameter file (PFILE), you must edit the initialization parameter file to add the name of any disk group that you want automatically mounted at instance startup, and remove the name of any disk group that you no longer want automatically mounted.

Note: Issuing the ALTER DISKGROUP...ALL MOUNT or ALTER DISKGROUP...ALL DISMOUNT command does not affect the value of this parameter.


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.

See Also:

"Manually Rebalancing a Disk Group" for more information.

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.

Starting Up an ASM Instance

ASM instances are started similarly to Oracle database instances with some minor differences:

  • To connect to the ASM instance with SQL*Plus, you must set the ORACLE_SID environment variable to the ASM SID. (The default ASM SID for a single instance database is +ASM, and the default SID for ASM on Real Application Clusters is +ASMnode#.) Depending on your operating system and whether or not you installed ASM in its own Oracle home, you may have to change other environment variables. For more information, see "Selecting an Instance with Environment Variables".

  • The initialization parameter file, which can be a server parameter file, must contain:

    INSTANCE_TYPE = ASM
    
    

    This parameter signals the Oracle executable that an ASM instance is starting and not a database instance.

  • The STARTUP command, rather than trying to mount and open a database, tries to mount the disk groups specified by the initialization parameter ASM_DISKGROUPS. If ASM_DISKGROUPS is blank, the ASM instance starts and warns that no disk groups were mounted. You can then mount disk groups with the ALTER DISKGROUP...MOUNT command.

The SQL*Plus STARTUP command parameters are interpreted by ASM as follows:

STARTUP Parameter Description
FORCE Issues a SHUTDOWN ABORT to the ASM instance before restarting it
MOUNT, OPEN Mounts the disk groups specified in the ASM_DISKGROUPS initialization parameter. This is the default if no command parameter is specified.
NOMOUNT Starts up the ASM instance without mounting any disk groups

The following is a sample SQL*Plus session in which an ASM instance is started.

% sqlplus /nolog
SQL> CONNECT / AS sysdba
Connected to an idle instance.

SQL> STARTUP
ASM instance started

Total System Global Area   71303168 bytes
Fixed Size                  1069292 bytes
Variable Size              45068052 bytes
ASM Cache                  25165824 bytes
ASM diskgroups mounted

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.

CSS Daemon on the Linux and Unix Platforms

To determine if the CSS daemon is running, issue the command crsctl check cssd. If you receive the message CSS appears healthy, the CSS daemon is running.

To start the CSS daemon and configure the host to always start the daemon upon reboot, do the following:

  1. Log in to the host as root.

  2. Ensure that $ORACLE_HOME/bin is in your PATH environment variable.

  3. Enter the following command:

    localconfig add
    
CSS Daemon on the Windows Platform

You can also use the crsctl and localconfig commands on the Windows platform to check the status of the CSS daemon or to start it. If you prefer to use Windows GUI tools, you can do the following:

To determine if the CSS daemon is properly configured and running, double-click the Services icon in the Windows Control Panel, and look for the OracleCSService service. Its status should be Started and its startup type should be Automatic.

Refer to the Windows documentation for information on how to start a Windows service and how to configure it for Automatic startup.

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.

Note:

The PROVISIONED header status implies that an additional platform-specific action has been taken by an administrator to make the disk available for ASM. For example, on Windows, the administrator used asmtool or asmtoolg to stamp the disk with a header, or on Linux, the administrator used ASMLib to prepare the disk for ASM.

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.

Shutting Down an ASM Instance

Automatic Storage Management shutdown is initiated by issuing the SHUTDOWN command in SQL*Plus.

You must first ensure that the ORACLE_SID environment variable is set to the ASM SID to connect to the ASM instance. Depending on your operating system and whether or not you installed ASM in its own Oracle home, you may have to change other environment variables before starting SQL*Plus. For more information, see "Selecting an Instance with Environment Variables".

% sqlplus /nolog
SQL> CONNECT / AS sysdba
Connected.
SQL> SHUTDOWN NORMAL

The table that follows lists the SHUTDOWN modes and describes the behavior of the ASM instance in each mode.

SHUTDOWN Mode Action Taken By Automatic Storage Management
NORMAL, IMMEDIATE, or TRANSACTIONAL ASM waits for any in-progress SQL to complete before doing an orderly dismount of all disk groups and shutting down the ASM instance. If any database instances are connected to the ASM instance, the SHUTDOWN command returns an error and leaves the ASM instance running.
ABORT The ASM instance immediately shuts down without the orderly dismount of disk groups. This causes recovery upon the next startup of ASM. If any database instance is connected to the ASM instance, the database instance aborts.

It is strongly recommended that you shut down all database instances that use the ASM instance before shutting down the ASM instance.

Administering Automatic Storage Management Disk Groups

This section explains how to create and manage your Automatic Storage Management (ASM) disk groups. If you have one or more database instances that use ASM, you can keep them open and running while you administer disk groups.

You can administer ASM disk groups with Database Configuration Assistant (DBCA), Enterprise Manager (EM), or SQL*Plus. In addition, the ASM command-line utility, ASMCMD, enables you to easily view and manipulate files and directories within disk groups.

This section provides details on administration with SQL*Plus, but includes background information that applies to all administration methods.

The SQL statements introduced in this section are only available in an ASM instance.

Note:

All sample SQL*Plus sessions in this section assume that the ORACLE_SID environment variable is changed to the ASM SID before starting SQL*Plus. Depending on your operating system and whether or not you installed ASM in its own Oracle home, other environment variables may have to be changed as well. For more information, see "Selecting an Instance with Environment Variables".

The following topics are contained in this section:

See Also:

Considerations and Guidelines for Configuring Disk Groups

The following are some considerations and guidelines to be aware of as you configure disk groups.

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

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 ASM 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 want ASM to mirror files, you specify the redundancy level as NORMAL REDUNDANCY (2-way mirroring by default for most file types) or HIGH REDUNDANCY (3-way mirroring for all files). You specify EXTERNAL REDUNDANCY if you want no mirroring by ASM. For example, you might choose EXTERNAL REDUNDANCY if you want to use storage array protection features. See the Oracle Database SQL Reference for more information on redundancy levels. See "Overview of the Components of Automatic Storage Management" and "Failure Groups and Mirroring" for information on failure groups.

ASM 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. ASM 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. Disk names are available in the V$ASM_DISK view.

The ASM instance ensures that any disk being included in the newly created disk group is addressable and is not already a member of another disk group. This requires reading the first block of the disk to determine if it already belongs to a disk group. If not, a header is written. It is not possible for a disk to be a member of multiple disk groups.

If a disk has a header indicates that it is part of another disk group, you can force it to become a member of the disk group you are creating by specifying the FORCE clause. 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. After 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 initialization parameter is set to '/devices/*'. Assume the following:

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

/devices/diska1
/devices/diska2
/devices/diska3
/devices/diska4
/devices/diskb1
/devices/diskb2
/devices/diskb3
/devices/diskb4
  • 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.

% SQLPLUS /NOLOG
SQL> CONNECT / AS SYSDBA
Connected to an idle instance.
SQL> STARTUP NOMOUNT
SQL> CREATE DISKGROUP dgroup1 NORMAL REDUNDANCY 
  2  FAILGROUP controller1 DISK
  3 '/devices/diska1',
  4 '/devices/diska2',
  5 '/devices/diska3',
  6 '/devices/diska4'
  7 FAILGROUP controller2 DISK
  8 '/devices/diskb1',
  9 '/devices/diskb2',
 10 '/devices/diskb3',
 11 '/devices/diskb4';

In this example, dgroup1 is composed of eight disks that are defined as belonging to either failure group controller1 or controller2. Because NORMAL REDUNDANCY level is specified for the disk group, ASM provides mirroring for each type of database file according to the mirroring settings in the system default templates.

For example, in the system default templates shown in Table 12-5, default redundancy for the online redo log files (ONLINELOG template) for a normal redundancy disk group is MIRROR. 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 the default mirroring of a normal redundancy disk group, at least two failure groups must be defined.

Note:

If you do not specify failure groups, each disk is automatically placed in its own failure group.

Because 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.

Note:

If you do not provide a NAME clause and you assigned a label to a disk through ASMLib, the label is used as the disk name.

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.

ASM automatically rebalances when the composition of a disk group changes. Because rebalancing can be a long running operation, the ALTER DISKGROUP statement by default 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.

If you want the ALTER DISKGROUP statement to wait until the rebalance operation is complete before returning, you can add the REBALANCE WAIT clause. This is especially useful in scripts. The statement also accepts a REBALANCE NOWAIT clause, which invokes the default behavior of conducting the rebalance operation asynchronously in the background. 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 operation asynchronously. Typing CTRL-C does not cancel the rebalance operation or any disk add, drop, or resize operations.

To control the speed and resource consumption of the rebalance operation, you can include the REBALANCE POWER clause in statements that add, drop, or resize disks. See "Manually Rebalancing a Disk Group" for more information on this clause.

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.

Note:

If you do not provide a NAME clause and you assigned a label to a disk through ASMLib, the label is used as the disk name.

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:


/devices/diska1 -- member of dgroup1
/devices/diska2 -- member of dgroup1
/devices/diska3 -- member of dgroup1
/devices/diska4 -- member of dgroup1
/devices/diska5 -- candidate disk
/devices/diska6 -- candidate disk
/devices/diska7 -- candidate disk
/devices/diska8 -- candidate disk

/devices/diskb1 -- member of dgroup1
/devices/diskb2 -- member of dgroup1
/devices/diskb3 -- member of dgroup1
/devices/diskb4 -- member of dgroup2

/devices/diskc1 -- member of dgroup2
/devices/diskc2 -- member of dgroup2
/devices/diskc3 -- member of dgroup3
/devices/diskc4 -- candidate disk

/devices/diskd1 -- candidate disk
/devices/diskd2 -- candidate disk
/devices/diskd3 -- candidate disk
/devices/diskd4 -- candidate disk
/devices/diskd5 -- candidate disk
/devices/diskd6 -- candidate disk
/devices/diskd7 -- candidate disk
/devices/diskd8 -- candidate disk

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.

WARNING:

The ALTER DISKGROUP...DROP DISK statement returns before the drop and rebalance operations are complete. Do not reuse, remove, or disconnect the dropped disk until the HEADER_STATUS column for this disk in the V$ASM_DISK view changes to FORMER. You can query the V$ASM_OPERATION view to determine the amount of time remaining for the drop/rebalance operation to complete. For more information, see Oracle Database SQL Reference and Oracle Database Reference.

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.

Caution:

A DROP FORCE operation leaves data at reduced redundancy for as long as it takes for the subsequent rebalance operation to complete. This increases your exposure to data loss if there is a subsequent disk failure during rebalancing. DROP FORCE should be used only with great care.

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;

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 ASM. The disk groups are dismounted at ASM instance shutdown. ASM 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; 

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;

See Oracle Database SQL Reference for additional CHECK clause syntax.

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 disk group 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, ASM 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, ASM 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 disk group contains any files.

Managing Disk Group Directories

ASM disk groups contain a system-generated hierarchical directory structure for storing ASM files. The system-generated filename that ASM assigns to each file represents a path in this directory hierarchy. The following is an example of a system-generated filename:

+dgroup2/sample/controlfile/Current.256.541956473

The plus sign represents the root of the ASM file system. The dgroup2 directory is the parent directory for all files in the dgroup2 disk group. The sample directory is the parent directory for all files in the sample database, and the controlfile directory contains all control files for the sample database.

You can create your own directories within this hierarchy to store aliases that you create. Thus, in addition to having user-friendly alias names for ASM files, you can have user-friendly paths to those names.

This section describes how to use the ALTER DISKGROUP statement to create a directory structure for aliases. It also describes how you can rename a directory or drop a directory.

See Also:

  • The chapter on ASMCMD in Oracle Database Utilities. ASMCMD is a command line utility that you can use to easily create aliases and directories in ASM disk groups.

  • "About ASM Filenames" for a discussion of ASM filenames and how they are formed

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;

Managing Alias Names for ASM Filenames

Alias names (or just "aliases") are intended to provide a more user-friendly means of referring to ASM files, rather than using the system-generated filenames.

You can create an alias for a file when you create it in the database, or you can add an alias to an existing file using the ADD ALIAS clause of the ALTER DISKGROUP statement. You can create an alias in any system-generated or user-created ASM directory. You cannot create an alias at the root level (+), however.

The V$ASM_ALIAS view contains a row for every alias name known to the ASM instance. This view also contains ASM directories.

Note:

V$ASM_ALIAS also contains a row for every system-generated filename. These rows are indicated by the value 'Y' in the column SYSTEM_CREATED.

See Also:

The chapter on ASMCMD in Oracle Database Utilities. ASMCMD is a command line utility that you can use to easily create aliases.

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';

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:

ALTER DISKGROUP dgroup1
     DROP FILE '+dgroup1/sample/datafile/mytable.342.372642';

Managing Disk Group Templates

Templates are used to set redundancy (mirroring) and striping attributes of files created in an ASM disk group. When a file is created, redundancy and striping attributes are set for that file based on an explicitly named template or the system template that is the default template for the file type.

When a disk group is created, ASM creates a set of default templates for that disk group. The set consists of one template for each file type (data file, control file, redo log file, and so on) supported by ASM. For example, a template named ONLINELOG provides the default file redundancy and striping attributes for all redo log files written to ASM disks. Default template settings depend on the disk group type. For example, the default template for datafiles for a normal redundancy disk group sets 2-way mirroring, while the corresponding default template in a high redundancy disk group sets 3-way mirroring.You can modify these default templates. Table 12-5 lists the default templates and the attributes that they apply to matching files. As the table shows, the initial redundancy value of each default template depends on the type of disk group that the template belongs to.

Note:

The striping attribute of templates applies to all disk group types (normal redundancy, high redundancy, and external redundancy). However, the mirroring attribute of templates applies only to normal redundancy disk groups, and is ignored for high-redundancy disk groups (where every file is always 3-way mirrored) and external redundancy disk groups (where no files are mirrored by ASM). Nevertheless, each type of disk group gets a full set of templates, and the redundancy value in each template is always set to the proper default for the disk group type.

Using clauses of the ALTER DISKGROUP statement, you can add new templates to a disk group, modify existing ones, or drop templates. The reason to add templates is to create the right combination of attributes to meet unique requirements. You can then reference a template name when creating a file, thereby assigning desired attributes on an individual file basis rather than on the basis of file type.The V$ASM_TEMPLATE view lists all of the templates known to the ASM instance.

Template Attributes

Table 12-3 shows the permitted striping attribute values, and Table 12-4 shows the permitted redundancy values for ASM templates. These values correspond to the STRIPE and REDUND columns of V$ASM_TEMPLATE.

Table 12-3 Permitted Values for ASM Template Striping Attribute

Striping Attribute Value Description

FINE

Striping in 128KB chunks.

COARSE

Striping in 1MB chunks.


Table 12-4 Permitted Values for ASM Template Redundancy Attribute

Redundancy Attribute Value Resulting Mirroring in Normal Redundancy Disk Group Resulting Mirroring in High Redundancy Disk Group Resulting Mirroring in External Redundancy Disk Group

MIRROR

2-way mirroring

3-way mirroring

(Not allowed)

HIGH

3-way mirroring

3-way mirroring

(Not allowed)

UNPROTECTED

No mirroring

(Not allowed)

No mirroring


Table 12-5 ASM System Default Templates Attribute Settings

Template Name Striping Mirroring, Normal Redundancy Disk Group Mirroring, High Redundancy Disk Group Mirroring, External Redundancy Disk Group

CONTROLFILE

FINE

HIGH

HIGH

UNPROTECTED

DATAFILE

COARSE

MIRROR

HIGH

UNPROTECTED

ONLINELOG

FINE

MIRROR

HIGH

UNPROTECTED

ARCHIVELOG

COARSE

MIRROR

HIGH

UNPROTECTED

TEMPFILE

COARSE

MIRROR

HIGH

UNPROTECTED

BACKUPSET

COARSE

MIRROR

HIGH

UNPROTECTED

PARAMETERFILE

COARSE

MIRROR

HIGH

UNPROTECTED

DATAGUARDCONFIG

COARSE

MIRROR

HIGH

UNPROTECTED

FLASHBACK

FINE

MIRROR

HIGH

UNPROTECTED

CHANGETRACKING

COARSE

MIRROR

HIGH

UNPROTECTED

DUMPSET

COARSE

MIRROR

HIGH

UNPROTECTED

XTRANSPORT

COARSE

MIRROR

HIGH

UNPROTECTED

AUTOBACKUP

COARSE

MIRROR

HIGH

UNPROTECTED


Adding Templates to a Disk Group

To add a new template for a disk group, you use the ADD TEMPLATE clause of the ALTER DISKGROUP statement. You specify the name of the template, its redundancy attribute, and its striping attribute.

Note:

If the name of your new template is not one of the names listed in Table 12-5, it is not used as a default template for database file types. To use it, you must reference its name when creating a file. See "About ASM Filenames" for more information.

The syntax of the ALTER DISKGROUP command for adding a template is as follows:

ALTER DISKGROUP disk_group_name ADD TEMPLATE template_name 
  ATTRIBUTES ([{MIRROR|HIGH|UNPROTECTED}] [{FINE|COARSE}]);

Both types of attribute are optional. If no redundancy attribute is specified, the value defaults to MIRROR for a normal redundancy disk group, HIGH for a high redundancy disk group, and UNPROTECTED for an external redundancy disk group. If no striping attribute is specified, the value defaults to COARSE.

Adding Templates to a Disk Group: Example 1 The following statement creates a new template named reliable for the normal redundancy disk group dgroup2:

ALTER DISKGROUP dgroup2 ADD TEMPLATE reliable ATTRIBUTES (HIGH FINE);

Adding Templates to a Disk Group: Example 2 This statement creates a new template named unreliable that specifies files are to be unprotected (no mirroring). (Oracle discourages the use of unprotected files unless hardware mirroring is in place; this example is presented only to further illustrate how the attributes for templates are set.)

ALTER DISKGROUP dgroup2 ADD TEMPLATE unreliable ATTRIBUTES (UNPROTECTED);

See Also:

Oracle Database SQL Reference for more information on the ALTER DISKGROUP...ADD TEMPLATE command.

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 template unreliable from dgroup2:

ALTER DISKGROUP dgroup2 DROP TEMPLATE unreliable;

Using Automatic Storage Management in the Database

This section discusses how you use Automatic Storage Management (ASM) to manage database files.

Note:

This section does not address Real Application Clusters environments. For this information, see Oracle Real Application Clusters Installation and Configuration Guide and Oracle Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide.

When you use ASM, Oracle database files are stored in ASM disk groups. Your Oracle Database then benefits from the improved performance, improved resource utilization, and higher availability provided by ASM. Most ASM files are Oracle-managed files. See Table 12-7 and Chapter 11, "Using Oracle-Managed Files" for more information.

Note:

ASM supports good forward and backward compatibility between 10.x versions of Oracle Database and 10.x versions of ASM. That is, any combination of versions 10.1.x.y and 10.2.x.y for either the ASM instance or the database instance works correctly, with one caveat: For a 10.1.x.y database instance to connect to a 10.2.x.y ASM instance, the database must be version 10.1.0.3 or later.

When mixing software versions, ASM functionality reverts to the functionality of the earliest version in use. For example, a 10.1.0.3 database working with a 10.2.0.0 ASM instance does not exploit new features in ASM 10.2.0.0. Conversely, a 10.2.0.0 database working with a 10.1.0.2 ASM instance behaves as a 10.1.0.2 database instance when interacting with ASM. Two columns in the view V$ASM_CLIENT, SOFTWARE_VERSION and COMPATIBLE_VERSION, display version information. These columns are described in Oracle Database Reference.

Oracle database files that are stored in disk groups are not visible to the operating system or its utilities, but are visible to RMAN, ASMCMD, and to the XML DB repository.

This following topics are contained in this section:

What Types of Files Does ASM Support?

ASM supports most file types required by the database. However, most administrative files cannot be stored on a ASM disk group. These include trace files, audit files, alert logs, backup files, export files, tar files, and core files.

Table 12-6 lists file types, indicates if they are supported, and lists the system default template that provides the attributes for file creation. Some of the file types shown in the table are related to specific products or features, and are not discussed in this book.

Table 12-6 File Types Supported by Automatic Storage Management

File Type Supported Default Templates

Control files

yes

CONTROLFILE

Datafiles

yes

DATAFILE

Redo log files

yes

ONLINELOG

Archive log files

yes

ARCHIVELOG

Trace files

no

n/a

Temporary files

yes

TEMPFILE

Datafile backup pieces

yes

BACKUPSET

Datafile incremental backup pieces

yes

BACKUPSET

Archive log backup piece

yes

BACKUPSET

Datafile copy

yes

DATAFILE

Persistent initialization parameter file (SPFILE)

yes

PARAMETERFILE

Disaster recovery configurations

yes

DATAGUARDCONFIG

Flashback logs

yes

FLASHBACK

Change tracking file

yes

CHANGETRACKING

Data Pump dumpset

yes

DUMPSET

Automatically generated control file backup

yes

AUTOBACKUP

Cross-platform transportable datafiles

yes

XTRANSPORT

Operating system files

no

n/a


See Also:

"Managing Disk Group Templates" for a description of the system default templates

About ASM Filenames

Every file created in ASM gets a system-generated filename, otherwise known as a fully qualified filename. The fully qualified filename represents a complete path name in the ASM file system. An example of a fully qualified filename is:

+dgroup2/sample/controlfile/Current.256.541956473

You can use the fully qualified filename to reference (read or retrieve) an ASM file. You can also use other abbreviated filename formats, described later in this section, to reference an ASM file.

ASM generates a fully qualified filename upon any request to create a file. A creation request does not—in fact, cannot—specify a fully qualified filename. Instead, it uses a simpler syntax to specify a file, such as an alias or just a disk group name. ASM then creates the file, placing it in the correct ASM "path" according to file type, and then assigns an appropriate fully qualified filename. If you specify an alias in the creation request, ASM also creates the alias so that it references the fully qualified filename.

ASM file creation requests are either single file creation requests or multiple file creation request.

Single File Creation Request This is a request to create a single file, such as a datafile or a control file. The form of the ASM filename in this type of request is either an alias (such as +dgroup2/control/ctl.f) or a disk group name preceded by a plus sign. You use the alias or disk group name where a filename is called for in a statement, such as CREATE TABLESPACE or CREATE CONTROLFILE.

Note:

'/ ' and '\' are interchangeable in filenames. Filenames are case insensitive, but case retentive.

Multiple File Creation Request This is a request that can occur multiple times to create an ASM file. For example, if you assign a value to the initialization parameter DB_CREATE_FILE_DEST, you can issue a CREATE TABLESPACE statement (without a filename specification) multiple times. Each time, ASM creates a different unique datafile name.

One form of the ASM filename to use in this type of request is an incomplete filename, which is just a disk group name preceded by a plus sign. In this case, you set DB_CREATE_FILE_DEST to an incomplete filename (for example, +dgroup2), and whenever a command is executed that must create a database file in DB_CREATE_FILE_DEST, the file is created in the designated disk group and assigned a unique fully qualified name. You can use an incomplete filename in other *_DEST initialization parameters.

Note:

Every time ASM creates a fully qualified name, it writes an alert log message containing the ASM-generated name. You can also find the generated name in database views displaying Oracle file names, such as V$DATAFILE and V$LOGFILE. You can use this name, or an abbreviated form of it, if you later need to reference an ASM file in a SQL statement. Like other Oracle database filenames, ASM filenames are kept in the control file and the RMAN catalog.

The sections that follow provide details on each of the six possible forms of an ASM filename:

The following table specifies the valid contexts for each filename form, and if the form is used for file creation, whether the created file is an Oracle-managed file (OMF).

Table 12-7 Valid Contexts for the ASM Filename Forms

Filename Form Valid Context OMF
Reference Single-File Creation Multiple File Creation Created as Oracle-managed?

Fully qualified filename

Yes

No

No

 

Numeric filename

Yes

No

No

 

Alias filename

Yes

Yes

No

No

Alias with template filename

No

Yes

No

No

Incomplete filename

No

Yes

Yes

Yes

Incomplete filename with template

No

Yes

Yes

Yes


Note:

Fully qualified and numeric filenames can be used in single-file create if you specify the REUSE keyword, as described in "Using ASM Filenames in SQL Statements".

Fully Qualified ASM Filename

This form of ASM filename can be used for referencing existing ASM files. It is the filename that ASM always automatically generates when an ASM file is created.

A fully qualified filename has the following form:

+group/dbname/file_type/file_type_tag.file.incarnation 

where:

  • +group is the disk group name preceded by a plus sign.

    You can think of the plus sign (+) as the root directory of the ASM file system, like the slash (/) in Unix operating systems.

  • dbname is the DB_UNIQUE_NAME of the database to which the file belongs.

  • file_type is the Oracle file type and can be one of the file types shown in Table 12-8.

  • file_type_tag is type specific information about the file and can be one of the tags shown in Table 12-8.

  • file.incarnation is the file/incarnation pair, used to ensure uniqueness.

An example of a fully qualified ASM filename is:

+dgroup2/sample/controlfile/Current.256.541956473 

Table 12-8 Oracle File Types and Automatic Storage Management File Type Tags

Automatic Storage Management file_type Description Automatic Storage Management file_type_tag Comments

CONTROLFILE

Control files and backup control files

Current

Backup

--

DATAFILE

Datafiles and datafile copies

tsname

Tablespace into which the file is added

ONLINELOG

Online logs

group_group#

--

ARCHIVELOG

Archive logs

thread_thread#_seq_sequence#

--

TEMPFILE

Tempfiles

tsname

Tablespace into which the file is added

BACKUPSET

Datafile and archive log backup pieces; datafile incremental backup pieces

hasspfile_timestamp

hasspfile can take one of two values: s indicates that the backup set includes the spfile; n indicates that the backup set does not include the spfile.

PARAMETERFILE

Persistent parameter files

spfile

 

DAATAGUARDCONFIG

Data Guard configuration file

db_unique_name

Data Guard tries to use the service provider name if it is set. Otherwise the tag defaults to DRCname.

FLASHBACK

Flashback logs

log_log#

--

CHANGETRACKING

Block change tracking data

ctf

Used during incremental backups

DUMPSET

Data Pump dumpset

user_obj#_file#

Dump set files encode the user name, the job number that created the dump set, and the file number as part of the tag.

XTRANSPORT

Datafile convert

tsname

--

AUTOBACKUP

Automatic backup files

hasspfile_timestamp

hasspfile can take one of two values: s indicates that the backup set includes the spfile; n indicates that the backup set does not include the spfile.


Numeric ASM Filename

The numeric ASM filename can be used for referencing existing files. It is derived from the fully qualified ASM filename and takes the form:

 +group.file.incarnation 

Numeric ASM filenames can be used in any interface that requires an existing file name.

An example of a numeric ASM filename is:

+dgroup2.257.541956473

Alias ASM Filenames

Alias ASM filenames, otherwise known as aliases, can be used both for referencing existing ASM files and for creating new ASM files. Alias names start with the disk group name preceded by a plus sign, after which you specify a name string of your choosing. Alias filenames are implemented using a hierarchical directory structure, with the slash (/) or backslash (\) character separating name components. You can create an alias in any system-generated or user-created ASM directory. You cannot create an alias at the root level (+), however.

When you create an ASM file with an alias filename, the file is created with a fully qualified name, and the alias filename is additionally created. You can then access the file with either name.

Alias ASM filenames are distinguished from fully qualified filenames or numeric filenames because they do not end in a dotted pair of numbers. It is an error to attempt to create an alias that ends in a dotted pair of numbers. Examples of ASM alias filenames are:

+dgroup1/myfiles/control_file1
+dgroup2/mydir/second.dbf

Oracle Database references database files by their alias filenames, but only if you create the database files with aliases. If you create database files without aliases and then add aliases later, the database references the files by their fully qualified filenames. The following are examples of how the database uses alias filenames:

  • Alias filenames appear in V$ views. For example, if you create a tablespace and use an alias filename for the datafile, the V$DATAFILE view shows the alias filename.

  • When a controlfile points to datafiles and online redo log files, it can use alias filenames.

  • The CONTROL_FILES initialization parameter can use the alias filenames of the controlfiles. The Database Configuration Assistant (DBCA) creates controlfiles with alias filenames.

Note:

Files created using an alias filename are not considered Oracle-managed files and may require manual deletion in the future if they are no longer needed.

See Also:

Alias ASM Filename with Template

An alias ASM filename with template is used only for ASM file creation operations. It has the following format:

+dgroup(template_name)/alias 

Alias filenames with template behave identically to alias filenames. The only difference is that a file created with an alias filename with template receives the mirroring and striping attributes specified by the named template. The template must belong to the disk group that the file is being created in.

The creation and maintenance of ASM templates is discussed in "Managing Disk Group Templates".

An example of an alias ASM filename with template is:

+dgroup1(my_template)/config1

Explicitly specifying a template name, as in this example, overrides the system default template for the type of file being created.

Note:

Files created using an alias filename with template are not considered Oracle-managed files and may require manual deletion in the future if they are no longer needed.

Incomplete ASM Filename

Incomplete ASM filenames are used only for file creation operations and are used for both single and multiple file creation. They consist only of the disk group name. ASM uses a system default template to determine the ASM file mirroring and striping attributes. The system template that is used is determined by the file type that is being created. For example, if you are creating a datafile for a tablespace, the datafile template is used.

An example of using an incomplete ASM filename is setting the DB_CREATE_FILE_DEST initialization parameter to:

+dgroup1

With this setting, every time you create a tablespace, a datafile is created in the disk group dgroup1, and each datafile is assigned a different fully qualified name. See "Creating ASM Files Using a Default Disk Group Specification" for more information.

Incomplete ASM Filename with Template

Incomplete ASM filenames with templates are used only for file creation operations and are used for both single and multiple file creation. They consist of the disk group name followed by the template name in parentheses. When you explicitly specify a template in a file name, ASM uses the specified template instead of the default template for that file type to determine mirroring and striping attributes for the file.

An example of using an incomplete ASM filename with template is setting the DB_CREATE_FILE_DEST initialization parameter to:

+dgroup1(my_template)

Starting the ASM and Database Instances

Start the ASM and database instances in the following order:

  1. Start the ASM Instance.

    You start the ASM instance on the same node as the database before you start the database instance. Starting an ASM instance is discussed in "Starting Up an ASM Instance"

  2. Start the database instance.

    Consider the following before you start your database instance:

    • When using SQL*Plus to start the database, you must first set the ORACLE_SID environment variable to the database SID. If ASM and the database have different Oracle homes, you must also set the ORACLE_HOME environment variable. Depending on platform, you may have to change other environment variables as well.

    • You must have the INSTANCE_TYPE initialization parameter set as follows:

      INSTANCE_TYPE = RDBMS

      This the default.

    • If you want ASM to be the default destination for creating database files, you must specify an incomplete ASM filename in one or more of the following initialization parameters (see "Creating ASM Files Using a Default Disk Group Specification"):

      • DB_CREATE_FILE_DEST

      • DB_CREATE_ONLINE_LOG_DEST_n

      • DB_RECOVERY_FILE_DEST

      • CONTROL_FILES

      • LOG_ARCHIVE_DEST_n

      • LOG_ARCHIVE_DEST

      • STANDBY_ARCHIVE_DEST

    • Some additional initialization parameter considerations:

      • LOG_ARCHIVE_FORMAT is ignored if a disk group is specified for LOG_ARCHIVE_DEST (for example, LOG_ARCHIVE_DEST = +dgroup1).

      • DB_BLOCK_SIZE must be one of the standard block sizes (2K, 4K, 8K, 16K or 32K bytes).

      • LARGE_POOL_SIZE must be set to at least 1 MB.

Your database instance is now able to create ASM files. You can keep your database instance open and running when you reconfigure disk groups. When you add or remove disks from a disk group, ASM automatically rebalances file data in the reconfigured disk group to ensure a balanced I/O load, even while the database is running.

Creating and Referencing ASM Files in the Database

ASM files are Oracle-managed files unless you created the file using an alias. Any Oracle-managed file is automatically deleted when it is no longer needed. An ASM file is deleted if the creation fails.

Creating ASM Files Using a Default Disk Group Specification

Using the Oracle-managed files feature for operating system files, you can specify a directory as the default location for the creation of datafiles, tempfiles, redo log files, and control files. Using the Oracle-managed files feature for ASM, you can specify a disk group, in the form of an incomplete ASM filename, as the default location for creation of these files, and additional types of files, including archived log files. As for operating system files, the name of the default disk group is stored in an initialization parameter and is used whenever a file specification (for example, DATAFILE clause) is not explicitly specified during file creation.

The following initialization parameters accept the multiple file creation context form of ASM filenames as a destination:

Initialization Parameter Description
DB_CREATE_FILE_DEST Specifies the default disk group location in which to create:
  • Datafiles

  • Tempfiles

If DB_CREATE_ONLINE_LOG_DEST_n is not specified, then also specifies the default disk group for:

  • Redo log files

  • Control file

DB_CREATE_ONLINE_LOG_DEST_n Specifies the default disk group location in which to create:
  • Redo log files

  • Control files

DB_RECOVERY_FILE_DEST If this parameter is specified and DB_CREATE_ONLINE_LOG_DEST_n and CONTROL_FILES are not specified, then this parameter specifies a default disk group for a flash recovery area that contains a copy of:
  • Control file

  • Redo log files

If no local archive destination is specified, then this parameter implicitly sets LOG_ARCHIVE_DEST_10 to the USE_DB_RECOVERY_FILE_DEST value.

CONTROL_FILES Specifies a disk group in which to create control files.

The following initialization parameters accept the multiple file creation context form of the ASM filenames and ASM directory names as a destination:

Initialization Parameter Description
LOG_ARCHIVE_DEST_n Specifies a default disk group or ASM directory as destination for archiving redo log files
LOG_ARCHIVE_DEST Optional parameter to use to specify a default disk group or ASM directory as destination for archiving redo log files. Use when specifying only one destination.
STANDBY_ARCHIVE_DEST Relevant only for a standby database in managed recovery mode. It specifies a default disk group or ASM directory that is the location of archive logs arriving from a primary database. Not discussed in this book. See Oracle Data Guard Concepts and Administration.

The following example illustrates how an ASM file, in this case a datafile, might be created in a default disk group.

Creating a Datafile Using a Default Disk Group: Example Assume the following initialization parameter setting:

DB_CREATE_FILE_DEST = '+dgroup1'

The following statement creates tablespace tspace1.

CREATE TABLESPACE tspace1;

ASM automatically creates and manages the datafile for tspace1 on ASM disks in the disk group dgroup1. File extents are stored using the attributes defined by the default template for a datafile.

Using ASM Filenames in SQL Statements

You can specify ASM filenames in the file specification clause of your SQL statements. If you are creating a file for the first time, use the creation form of an ASM filename. If the ASM file already exists, you must use the reference context form of the filename, and if you are trying to re-create the file, you must add the REUSE keyword. The space will be reused for the new file. This usage might occur when, for example, trying to re-create a control file, as shown in "Creating a Control File in ASM".

If a reference context form is used with the REUSE keyword and the file does not exist, an error results.

Partially created files resulting from system errors are automatically deleted.

Using an ASM Filename in a SQL Statement: Example The following is an example of specifying an ASM filename in a SQL statement. In this case, it is used in the file creation context:

CREATE TABLESPACE  tspace2 DATAFILE '+dgroup2' SIZE 200M AUTOEXTEND ON;

The tablespace tspace2 is created and is comprised of one datafile of size 200M contained in the disk group dgroup2. The datafile is set to auto-extensible with an unlimited maximum size. An AUTOEXTEND clause can be used to override this default.

Creating a Database in ASM

The recommended method of creating your database is to use the Database Configuration Assistant (DBCA). However, if you choose to create your database manually using the CREATE DATABASE statement, then ASM enables you to create a database and all of its underlying files with a minimum of input from you.

The following is an example of using the CREATE DATABASE statement, where database files are created and managed automatically by ASM.

Creating a Database in ASM: Example

This example creates a database with the following ASM files:

  • A SYSTEM tablespace datafile in disk group dgroup1.

  • A SYSAUX tablespace datafile in disk group dgroup1. The tablespace is locally managed with automatic segment-space management.

  • A multiplexed online redo log is created with two online log groups, one member of each in dgroup1 and dgroup2 (flash recovery area).

  • If automatic undo management mode is enabled, then an undo tablespace datafile in directory dgroup1.

  • If no CONTROL_FILES initialization parameter is specified, then two control files, one in drgoup1 and another in dgroup2 (flash recovery area). The control file in dgroup1 is the primary control file.

The following initialization parameter settings are included in the initialization parameter file:

DB_CREATE_FILE_DEST = '+dgroup1'
DB_RECOVERY_FILE_DEST = '+dgroup2'
DB_RECOVERY_FILE_DEST_SIZE = 10G

The following statement is issued at the SQL prompt:

SQL> CREATE DATABASE sample;

Creating Tablespaces in ASM

When ASM creates a datafile for a permanent tablespace (or a tempfile for a temporary tablespace), the datafile is set to auto-extensible with an unlimited maximum size and 100 MB default size. You can use the AUTOEXTEND clause to override this default extensibility and the SIZE clause to override the default size.

Automatic Storage Management applies attributes to the datafile, as specified in the system default template for a datafile as shown in the table in "Managing Disk Group Templates". You can also create and specify your own template.

Files in a tablespace may be in both ASM files and non-ASM files as a result of the tablespace history. RMAN commands enable non-ASM files to be relocated to a ASM disk group and enable ASM files to be relocated as non-ASM files.

The following are some examples of creating tablespaces using Automatic Storage Management. The examples assume that disk groups have already been configured.

Creating a Tablespace in ASM: Example 1

This example illustrates "out of the box" usage of Automatic Storage Management. You let Automatic Storage Management create and manage the tablespace datafile for you, using Oracle supplied defaults that are adequate for most situations.

Assume the following initialization parameter setting:

DB_CREATE_FILE_DEST = '+dgroup2'

The following statement creates the tablespace and its datafile:

CREATE TABLESPACE tspace2;

Creating a Tablespace in ASM: Example 2

The following statements create a tablespace that uses a user defined template (assume it has been defined) to specify the redundancy and striping attributes of the datafile:

SQL> ALTER SYSTEM SET DB_CREATE_FILE_DEST = '+dgroup1(my_template)';
SQL> CREATE TABLESPACE tspace3;

Creating a Tablespace in ASM: Example 3

The following statement creates an undo tablespace with a datafile that has an alias name, and with attributes that are set by the user defined template my_undo_template. It assumes a directory has been created in disk group dgroup3 to contain the alias name and that the user defined template exists. Because an alias is used to create the datafile, the file is not an Oracle-managed file and will not be automatically deleted when the tablespace is dropped.

CREATE UNDO TABLESPACE myundo 
     DATAFILE '+dgroup3(my_undo_template)/myfiles/my_undo_ts' SIZE 200M; 

The following statement drops the file manually after the tablespace has been dropped:

ALTER DISKGROUP dgroup3 DROP FILE '+dgroup3/myfiles/my_undo_ts';

Creating Redo Logs in ASM

Online redo logs can be created in multiple disk groups, either implicitly in the initialization parameter file or explicitly in an ALTER DATABASE...ADD LOGFILE statement. Each online log should have one log member in multiple disk groups. The filenames for log file members are automatically generated.

All partially created redo log files, created as a result of a system error, are automatically deleted.

Adding New Redo Log Files: Example

The following example creates a log file with a member in each of the disk groups dgroup1 and dgroup2.

The following parameter settings are included in the initialization parameter file:

DB_CREATE_ONLINE_LOG_DEST_1 = '+dgroup1'
DB_CREATE_ONLINE_LOG_DEST_2 = '+dgroup2'

The following statement is issued at the SQL prompt:

ALTER DATABASE ADD LOGFILE;

Creating a Control File in ASM

Control files can be explicitly created in multiple disk groups. The filenames for control files are automatically generated. If an attempt to create a control file fails, partially created control files will be automatically be deleted.

There may be times when you need to specify a control file by name. Alias filenames are provided to allow administrators to reference ASM files with human-understandable names. The use of an alias in the specification of the control file during its creation allows the DBA to later refer to the control file with a human-meaningful name. Furthermore, an alias can be specified as a control file name in the CONTROL_FILES initialization parameter. Control files created without aliases can be given alias names at a later time. The ALTER DISKGROUP...CREATE ALIAS statement is used for this purpose.

When creating a control file, datafiles and log files stored in an ASM disk group should be given to the CREATE CONTROLFILE command using the file reference context form of their ASM filenames. However, the use of the RESETLOGS option requires the use of a file creation context form for the specification of the log files.

Creating a Control File in ASM: Example 1

The following CREATE CONTROLFILE statement is generated by an ALTER DATABASE BACKUP CONTROLFILE TO TRACE command for a database with datafiles and log files created on disk groups dgroup1 and dgroup2:

CREATE CONTROLFILE REUSE DATABASE "SAMPLE" NORESETLOGS ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 2
    MAXDATAFILES 30
    MAXINSTANCES 1
    MAXLOGHISTORY 226
LOGFILE
  GROUP 1 (
    '+DGROUP1/db/onlinelog/group_1.258.541956457',
    '+DGROUP2/db/onlinelog/group_1.256.541956473'
  ) SIZE 100M,
  GROUP 2 (
    '+DGROUP1/db/onlinelog/group_2.257.541956477',
    '+DGROUP2/db/onlinelog/group_2.258.541956487'
  ) SIZE 100M
DATAFILE
  '+DGROUP1/db/datafile/system.260.541956497',
  '+DGROUP1/db/datafile/sysaux.259.541956511'
CHARACTER SET US7ASCII
;

Creating a Control File in ASM: Example 2

This example is a CREATE CONTROLFILE statement for a database with datafiles, but uses a RESETLOGS clause, and thus uses the creation context form for log files:

CREATE CONTROLFILE REUSE DATABASE "SAMPLE" RESETLOGS ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 2
    MAXDATAFILES 30
    MAXINSTANCES 1
    MAXLOGHISTORY 226
LOGFILE
  GROUP 1 (
    '+DGROUP1',
    '+DGROUP2'
  ) SIZE 100M,
  GROUP 2 (
    '+DGROUP1',
    '+DGROUP2'
  ) SIZE 100M
DATAFILE
  '+DGROUP1/db/datafile/system.260.541956497',
  '+DGROUP1/db/datafile/sysaux.259.541956511'
CHARACTER SET US7ASCII
;

Creating Archive Log Files in ASM

Disk groups can be specified as archive log destinations in the LOG_ARCHIVE_DEST and LOG_ARCHIVE_DEST_n initialization parameters. When destinations are specified in this manner, the archive log filename will be unique, even if archived twice. All partially created archive files, created as a result of a system error, are automatically deleted.

If LOG_ARCHIVE_DEST is set to a disk group name, LOG_ARCHIVE_FORMAT is ignored. Unique filenames for archived logs are automatically created by the Oracle database. If LOG_ARCHIVE_DEST is set to a directory in a disk group, LOG_ARCHIVE_FORMAT has its normal semantics.

The following sample archive log names might be generated with DB_RECOVERY_FILE_DEST set to +dgroup2. SAMPLE is the value of the DB_UNIQUE_NAME parameter:

+DGROUP2/SAMPLE/ARCHIVELOG/2003_09_23/thread_1_seq_38.614.541956473
+DGROUP2/SAMPLE/ARCHIVELOG/2003_09_23/thread_4_seq_35.609.541956477
+DGROUP2/SAMPLE/ARCHIVELOG/2003_09_23/thread_2_seq_34.603.541956487
+DGROUP2/SAMPLE/ARCHIVELOG/2003_09_25/thread_3_seq_100.621.541956497
+DGROUP2/SAMPLE/ARCHIVELOG/2003_09_25/thread_1_seq_38.614.541956511

Recovery Manager (RMAN) and ASM

RMAN is critical to ASM and is responsible for tracking the ASM filenames and for deleting obsolete ASM files. Because ASM files cannot be copied through normal operating system interfaces (other than with the XML DB repository through FTP or HTTP/WebDAV), RMAN is the preferred means of copying ASM files. RMAN is the only method for performing backups of a database containing ASM files.

RMAN can also be used for moving databases or files into ASM storage.

Migrating a Database to Automatic Storage Management

With a new installation of Oracle Database and Automatic Storage Management (ASM), you initially create your database in ASM. If you have an existing Oracle database that stores database files in the operating system file system or on raw devices, you can migrate some or all of these database files to ASM.

There are two ways to migrate database files to ASM:

Accessing Automatic Storage Management Files with the XML DB Virtual Folder

Automatic Storage Management (ASM) files and directories can be accessed through a virtual folder in the XML DB repository. The repository path to the virtual folder is /sys/asm. The folder is virtual because its contents do not actually reside in the repository; they exist as normal ASM files and directories. /sys/asm provides a means to access and manipulate the ASM files and directories with programmatic APIs such as the DBMS_XDB package and with XML DB protocols such as FTP and HTTP/WebDAV.

A typical use for this capability might be to view /sys/asm as a Web Folder in a graphical user interface (with the WebDAV protocol), and then copy a Data Pump dumpset from an ASM disk group to an operating system file system by dragging and dropping.

You must log in as a user other than SYS and you must have been granted the DBA role to access /sys/asm with XML DB protocols.

Note:

The FTP protocol is initially disabled for a new XML DB installation. To enable it, you must set the FTP port to a non-zero value. The easiest way to do this is with the catxdbdbca.sql script. This script takes two arguments. The first is the FTP port number, and the second is the HTTP/WebDAV port number. The following example configures the FTP port number to 7787, and the HTTP/WebDAV port number to 8080:
SQL> @?/rdbms/admin/catxdbdbca.sql 7787 8080

Another way to set these port numbers is with the XDB Configuration page in Enterprise Manager.

See Also:

Oracle XML DB Developer's Guide for information on Oracle XML DB, including additional ways to configure port numbers for the XML DB protocol servers, and Oracle Database PL/SQL Packages and Types Reference for information on the DBMS_XDB package.

Inside /sys/asm

The ASM virtual folder is created by default during XML DB installation. If the database is not configured to use ASM, the folder is empty and no operations are permitted on it.

The ASM virtual folder contains folders and subfolders that follow the hierarchy defined by the structure of an ASM fully qualified file name. Thus, /sys/asm contains one subfolder for every mounted disk group, and each disk group folder contains one subfolder for each database that uses the disk group. (In addition, a disk group folder may contain files and folders corresponding to aliases created by the administrator.) Continuing the hierarchy, the database folders contain file type folders, which contain the ASM files. This hierarchy is shown in the following diagram, which for simplicity, excludes directories created for aliases.

Description of admin075.gif follows
Description of the illustration admin075.gif

Restrictions

The following are usage restrictions on /sys/asm:

  • You cannot create hard links to existing ASM files or directories with APIs such as DBMS_XDB.LINK.

  • You cannot rename (move) an ASM file to another disk group or to a directory outside ASM.

Sample FTP Session

In the following sample FTP session, the disk groups are DATA and RECOVERY, the database name is MFG, and dbs is a directory that was created for aliases. All files in /sys/asm are binary.

ftp> open myhost 7777
ftp> user system
ftp> passwd dba
ftp> cd /sys/asm
ftp> ls
DATA
RECOVERY
ftp> cd DATA
ftp> ls
dbs
MFG
ftp> cd dbs
ftp> ls
t_dbl.f
t_axl.f
ftp> binary
ftp> get t_dbl.f t_axl.f
ftp> put t_db2.f

Viewing Information About Automatic Storage Management

You can use these views to query information about Automatic Storage Management:

View Description
V$ASM_DISKGROUP In an ASM instance, describes a disk group (number, name, size related info, state, and redundancy type).

In a DB instance, contains one row for every ASM disk group mounted by the local ASM instance.

This view performs disk discovery every time it is queried.

V$ASM_DISK In an ASM instance, contains one row for every disk discovered by the ASM instance, including disks that are not part of any disk group.

In a DB instance, contains rows only for disks in the disk groups in use by that DB instance.

This view performs disk discovery every time it is queried.

V$ASM_DISKGROUP_STAT Has the same columns as V$ASM_DISKGROUP, but to reduce overhead, does not perform a discovery when it is queried. It therefore does not return information on any disks that are new to the storage system. For the most accurate data, use V$ASM_DISKGROUP instead.
V$ASM_DISK_STAT Has the same columns as V$ASM_DISK, but to reduce overhead, does not perform a discovery when it is queried. It therefore does not return information on any disks that are new to the storage system. For the most accurate data, use V$ASM_DISK instead.
V$ASM_FILE In an ASM instance, contains one row for every ASM file in every disk group mounted by the ASM instance.

In a DB instance, contains no rows.

V$ASM_TEMPLATE In an ASM or DB instance, contains one row for every template present in every disk group mounted by the ASM instance.
V$ASM_ALIAS In an ASM instance, contains one row for every alias present in every disk group mounted by the ASM instance.

In a DB instance, contains no rows.

V$ASM_OPERATION In an ASM instance, contains one row for every active ASM long running operation executing in the ASM instance.

In a DB instance, contains no rows.

V$ASM_CLIENT In an ASM instance, identifies databases using disk groups managed by the ASM instance.

In a DB instance, contains one row for the ASM instance if the database has any open ASM files.


See Also:

Oracle Database Reference for details on all of these dynamic performance views