12 Using Automatic Storage Management

Installation of ASM

Automatic Storage Management is always installed by the Oracle Universal Installer when you install your database software. The Database Configuration Assistant (DBCA) determines if an ASM instance already exists, and if not, then you are given the option of creating and configuring an ASM instance as part of database creation and configuration. If an ASM instance already exists, then it is used instead.

DBCA also configures your instance parameter file and password file.

Authentication for Accessing an ASM Instance

Automatic Storage Management 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.

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

Using operating system authentication, the authorization to connect with the SYSDBA privilege is granted through the use of an operating system group. On UNIX, this is typically the dba group. By default, members of the dba 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.

Setting Initialization Parameters for an ASM Instance

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.

Starting Up an ASM Instance

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

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

  Using a server parameter file is recommended because it eliminates the need to make manual changes to a text initialization parameter file.

• For ASM instances, STARTUP tries to mount the disk groups specified by the initialization parameter ASM_DISKGROUPS and not the database.

Further, the SQL*Plus STARTUP command parameters are interpreted by Automatic Storage Management as follows:

The following is a sample SQL*Plus session where 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 147936196 bytes
Fixed Size 324548 bytes
Variable Size 96468992 bytes
Database Buffers 50331648 bytes
Redo Buffers 811008 bytes
ASM diskgroups mounted

Shutting Down an ASM Instance

Using SQL*Plus, Automatic Storage Management shutdown is initiated by issuing the SHUTDOWN command. For example:

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

Disk Group Fixed Tables

A number of fixed tables, visible from both the ASM and database instances are provided for administrative and debugging purposes. These views are discussed in "Viewing Information About Automatic Storage Management".

Considerations and Guidelines for Configuring an ASM Instance

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

Creating a Disk Group

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

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

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

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

However, you can force a disk that is already a member of another disk group to become a member of the disk group you are creating by specifying the 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. Once the disk is repaired, it is no longer part of any disk group, but it still has an ASM header. The FORCE flag is required to use the disk in a new disk group. The original disk group must not be mounted, and the disk must have a disk group header, otherwise the operation fails. Note that if you do this, you may cause another disk group to become unusable. If you specify NOFORCE, which is the default, you receive an error if you attempt to include a disk that already belongs to another disk group.

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

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

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

/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. Since NORMAL REDUNDANCY level is specified for the disk group, then Automatic Storage Management provides redundancy for all files created in dgroup1 according to the attributes specified in the disk group templates.

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

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

Altering the Disk Membership of a Disk Group

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

Automatic Storage Management automatically rebalances file extents when the composition of a disk group changes. Because rebalancing can be a long running operation, the ALTER DISKGROUP statement does not wait until the operation is complete before returning. To monitor progress of these long running operations, query the V$ASM_OPERATION dynamic performance view.

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

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

ALTER DISKGROUP dgroup1 ADD DISK
     '/devices/diska2',
     '/devices/diskd4';

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

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

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

ALTER DISKGROUP dgroup1 DROP DISK diska5;

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

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

ALTER DISKGROUP dgroup1 UNDROP DISKS;  

ALTER DISKGROUP dgroup2 REBALANCE POWER 5;

Mounting and Dismounting Disk Groups

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

There may be times that you want to mount or dismount disk groups manually. For these actions use the ALTER DISKGROUP ... MOUNT or ALTER DISKGROUP ... DISMOUNT statement. You can mount or dismount disk groups by name, or specify ALL.

If you try to dismount a disk group that contains open files, the statement will fail, unless you also specify the FORCE clause.

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

ALTER DISKGROUP ALL DISMOUNT;

The following statement mounts disk group dgroup1:

ALTER DISKGROUP dgroup1 MOUNT; 

Managing Disk Group Templates

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

You can add new templates to a disk group, change existing ones, or drop templates using clauses of the ALTER DISKGROUP statement. The V$ASM_TEMPLATE view lists all of the templates known to the ASM instance.

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

ALTER DISKGROUP dgroup2 ADD TEMPLATE unreliable 
     ATTRIBUTES (UNPROTECTED);

ALTER DISKGROUP dgroup2 ALTER TEMPLATE reliable 
     ATTRIBUTES (COARSE);

ALTER DISKGROUP dgroup2 DROP TEMPLATE unreliable;

Managing Disk Group Directories

Every ASM disk group contains a hierarchical directory structure consisting of the fully qualified names of the files in the disk group, along with alias filenames. A fully qualified filename, also called a system alias, is always generated automatically by Automatic Storage Management when a file is created.

You can create an additional (more user-friendly) alias for each ASM filename during file creation. You can also create an alias for an existing filename using clauses of the ALTER DISKGROUP statement as described in "Managing Alias Names for ASM Filenames". But you must first create a directory structure to support whatever alias file naming convention you choose to use.

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

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

ALTER DISKGROUP dgroup1
     ADD DIRECTORY 'dgroup1/mydir/does_not_exist/second_dir;

ALTER DISKGROUP dgroup1 RENAME DIRECTORY '+dgroup1/mydir'
     TO '+dgroup1/yourdir';

ALTER DISKGROUP dgroup1 DROP DIRECTORY '+dgroup1/yourdir' FORCE;

Managing Alias Names for ASM Filenames

After you have created the hierarchical directory structure for alias names, you can create alias names in the disk group. Alias names are intended to provide a more user-friendly means of referring to ASM files, rather than using the fully qualified names (system aliases) that Automatic Storage Management always generates when it creates a file.

As mentioned earlier, these alias names can be created when the file is created in the database, or by adding an alias or renaming existing alias names using the ADD ALIAS or RENAME ALIAS clauses of the ALTER DISKGROUP statement. You delete an alias using the DROP ALIAS clause. You cannot delete or rename a system alias.

The V$ASM_ALIAS view contains a row for every alias name known to the ASM instance. It contains a column, SYSTEM_CREATED, that specifies if the alias is system generated

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

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

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

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

ALTER DISKGROUP dgroup1 
     DELETE 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.

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

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

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

Checking Internal Consistency of Disk Group Metadata

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

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

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

ALTER DISKGROUP dgroup1 CHECK ALL;

Dropping Disk Groups

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

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

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

The following statement deletes dgroup1:

DROP DISKGROUP dgroup1;

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

What Types of Files Does Automatic Storage Management Support?

Automatic Storage Management 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-2 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.

About ASM Filenames

ASM filenames can take several forms. Some of the forms are used to create ASM files, others are used to reference them. The forms that you use to create files are alias names or incomplete file names, that basically point to a disk group wherein files are created and given fully qualified names by Automatic Storage Management.

When Automatic Storage Management creates a fully qualified name, an alert log message is written containing this ASM generated name. You can also find the generated name in database views displaying Oracle file names, such as V$DATAFILE, V$LOGFILE, and so forth. 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.

These are the forms of an ASM filename:

• Fully Qualified ASM Filename

• Numeric ASM Filename

• Alias ASM Filenames

• Alias ASM Filename with Template

• Incomplete ASM Filename

• Incomplete ASM Filename with Template

The following table specifies the valid contexts for each form of a filename. Single-file creation is relevant for file specifications. Multiple-file creation is relevant in a *_DEST parameter.

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

+dgroup2/sample/controlfile/CF.257.1 

+group.file.incarnation 

+dgroup2.257.8675309 

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

+dgroup(template_name)/alias 

+dgroup1(spfile)/config1

+dgroup1

+dgroup1(datafile)

Starting the ASM and Database Instances

For you to use the functionality of Automatic Storage Management, a database instance requires that an ASM instance is running and that disk groups are configured. Specifically:

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:

   • To start a database instance, you must have the INSTANCE_TYPE initialization parameter set as follows:

     INSTANCE_TYPE = RDBMS

     This the default.

   • Specify an ASM filename for any of the following initialization parameters for which you want Automatic Storage Management to automatically create and manage files (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 8 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, Automatic Storage Management 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.

DB_CREATE_FILE_DEST = '+dgroup1'

CREATE TABLESPACE tspace1;

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

Creating a Database Using Automatic Storage Management

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 Automatic Storage Management 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 Automatic Storage Management.

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 Using Automatic Storage Management

When Automatic Storage Management 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.

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;

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;

The following statement creates an undo tablespace with a datafile that has an alias name and its attributes are set by the user defined template my_undo_temp. 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_temp)/myfiles/my_undo_ts' SIZE 200M; 

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

ALTER DISKGROUP dgroup3 DROP FLE '+dgroup3/myfiles/my_undots';

Creating Redo Logs Using Automatic Storage Management

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.

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 Using Automatic Storage Management

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.

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.3',
    '+DGROUP2/db/onlinelog/group_1.256.3'
  ) SIZE 100M,
  GROUP 2 (
    '+DGROUP1/db/onlinelog/group_2.257.3',
    '+DGROUP2/db/onlinelog/group_2.258.1'
  ) SIZE 100M
DATAFILE
  '+DGROUP1/db/datafile/system.260.3',
  '+DGROUP1/db/datafile/sysaux.259.3'
CHARACTER SET US7ASCII
;

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.3',
  '+DGROUP1/db/datafile/sysaux.259.3'
CHARACTER SET US7ASCII
;

Creating Archive Log Files Using Automatic Storage Management

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. Partially created archive operations resulting from a system error are deleted and do not leave a half written file.

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.3
+DGROUP2/SAMPLE/ARCHIVELOG/2003_09_23/thread_4_seq_35.609.3
+DGROUP2/SAMPLE/ARCHIVELOG/2003_09_23/thread_2_seq_34.603.3
+DGROUP2/SAMPLE/ARCHIVELOG/2003_09_25/thread_3_seq_100.621.3
+DGROUP2/SAMPLE/ARCHIVELOG/2003_09_25/thread_1_seq_38.614.3

Recovery Manager (RMAN) and Automatic Storage Management

RMAN is critical to Automatic Storage Management and is responsible for tracking the ASM filenames and for deleting obsolete ASM files. Since ASM files cannot be accessed through normal operating system interfaces, RMAN is the preferred means of copying ASM files; you can also use FTP through XDB. 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.