Using Automatic Storage Management
Using Automatic Storage Management
Using Automatic Storage Management
Management
This chapter briefly discusses some of the concepts behind Automatic Storage
Management and describes how to use it. It contains the following topics:
In the SQL statements that you use for creating database structures such as
tablespaces, redo log and archive log files, and control files, you specify file location
in terms of disk groups. Automatic Storage Management then creates and manages the
associated underlying files for you.
Automatic Storage Management is integrated into the database server; you do not
need to install it as a separate product.
See Also:
Oracle Database Concepts for an overview of Automatic Storage
Management
A disk group consists of a grouping of disks that are managed together as a unit.
These disks are referred to as ASM disks. Files written on ASM disks are ASM files,
whose names are automatically generated by Automatic Storage Management. You
can specify user-friendly alias names for ASM files, but you must create a
hierarchical directory structure for these alias names.
You can affect how Automatic Storage Management places files on disks by
specifying failure groups. Failure groups define disks that share components, such
that if one fails then other disks sharing the component might also fail. An example of
what you might define as a failure group would be a set of SCSI disks sharing the
same SCSI controller. Failure groups are used to determine which ASM disks to use
for storing redundant data. For example, if two-way mirroring is specified for a file,
then redundant copies of file extents must be stored in separate failure groups.
Templates are used to provide the attribute information about ASM files created in
ASM disk groups. These templates simplify file creation by mapping complex file
attribute specifications into a single name. For example, a template named ONLINELOG
provides the file redundancy and striping attributes for all redo log files written to
ASM disks. For each disk group, Automatic Storage Management provides a set of
initial system templates, as shown in the table in "Managing Disk Group Templates",
suitable for most needs, but you can modify the templates or create new ones to meet
unique requirements.
Note:
This section discusses the administration of an ASM instance in terms of its startup
and shutdown, and its behavior and interaction with the database instance. The major
part of the administration of an ASM instance, once it is started, is the creation and
maintenance of disk groups and their metadata. This is discussed in "Configuring the
Components of Automatic Storage Management".
• Installation of ASM
• Authentication for Accessing an ASM Instance
• Setting Initialization Parameters for an ASM Instance
• Starting Up an ASM Instance
• Shutting Down an ASM Instance
• Disk Group Fixed Tables
Installation of ASM
DBCA also configures your instance parameter file and password file.
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.
See Also:
Name Description
INSTANCE_TYPE Must be set to INSTANCE_TYPE = ASM.
Default: 1
Default: NULL (This default causes ASM to find all of the disks in a
platform-specific location to which it has read/write access.)
Oracle Database can perform one rebalance at a time on a given instance. The
rebalance power is constrained by the value of the ASM_POWER_LIMIT initialization
parameter. You can 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. If the POWER clause is not specified,
or when rebalance is implicitly invoked by adding or dropping a disk, the power
defaults to the ASM_POWER_LIMIT.
The V$ASM_OPERATION view provides information that can be used for adjusting
ASM_POWER_LIMIT and the resulting power of rebalance operations. If the
DESIRED_POWER column value is less than the ACTUAL_POWER column value for a
given rebalance operation, then ASM_POWER_LIMIT is impacting the rebalance.
The V$ASM_OPERATION view also gives an estimate in the EST_MINUTES column of the
amount of time remaining for the operation to complete. You can see the effect of
changing the power of rebalance by observing the change in the time estimate.
The default value errors on the side of minimizing disruption to other applications.
The appropriate value is dependent upon your hardware configuration as well as
performance and availability requirements.
In many cases, the default value is sufficient. Using a more restrictive value may
reduce the time required for Automatic Storage Management 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.
If your site is using a third-party vendor ASMLIB, that vendor may have discovery
string conventions that should be used for ASM_DISKSTRING.
If you specify any of the ASM specific parameters (names start with ASM_) in a
database instance parameter file, you will receive an ORA-15021 error.
• 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.
• For ASM instances, STARTUP tries to mount the disk groups specified by the
initialization parameter ASM_DISKGROUPS and not the database.
STARTUP
Parameter Description
FORCE Issues a SHUTDOWN ABORT to the ASM instance before restarting
it
MOUNT Mounts the disk groups specified in the ASM_DISKGROUPS
initialization parameter
NOMOUNT Starts up the ASM instance without mounting any disk groups
OPEN Invalid for an ASM instance
% 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
When an ASM instance initializes, ASM is able to discover and look at the contents of
all of the disks in the disk groups that are pointed to by the ASM_DISKSTRING
initialization parameter. This saves you from having to specify a path for each of the
disks in the disk group.
Disk group mounting requires that an ASM instance doing disk discovery be able to
access all the disks within the disk group that any other ASM instance having
previously mounted the disk group believes are members of that disk group. It is vital
that any disk configuration errors be detected before a disk group is mounted.
When an ASM instance fails, then all Oracle database instances on the same node as
that ASM instance and that use a disk group managed by that 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.
% 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 ASM waits for the connected ASM instances (and other ASM SQL
sessions) to exit before shutting down the instance.
IMMEDIATE ASM waits for any in-progress SQL to complete before shutting
down the ASM instance, but does not wait for database instances to
disconnect.
TRANSACTIONAL Same as IMMEDIATE.
ABORT Automatic Storage Management immediately shuts down.
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".
If you have a database instance running and are actively using Automatic Storage
Management, you can keep the database open and running while you reconfigure disk
groups.
The SQL statements introduced in this section are only available in an ASM instance.
You must first start the ASM instance. This is discussed in "Administering an ASM
Instance".
The following are some considerations and guidelines to be aware of as you configure
Automatic Storage Management.
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.
Automatic Storage Management eliminates the need for manual disk tuning.
However, to ensure consistent performance, you should avoid placing dissimilar disks
in the same disk group. For example, the newest and fastest disks might reside in a
disk group reserved for the database work area, and slower drives could reside in a
disk group reserved for the flash recovery area.
You can add or drop disks without shutting down the database. However, a
performance impact on I/O activity may result.
Mirroring of metadata and user data is achieved through failure groups. ASM requires
at least two failure groups for normal redundancy disk groups and at least three failure
groups for high redundancy disk groups. System reliability can be hampered if an
insufficient number of failure groups are provided. Consequently, failure group
configuration is very important to creating a highly reliable system.
Scalability
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.
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.
/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.
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.
The ADD clause of the ALTER DISKGROUP statement lets you add disks to a disk group,
or to add a failure group to the disk group. The ALTER DISKGROUP clauses that you
can use when adding disks to a disk group are similar to those that can be used when
specifying the disks to be included when initially creating a disk group. This is
discussed in "Creating a Disk Group".
The new disks will gradually start to carry their share of the workload as rebalancing
progresses.
Automatic Storage Management behavior when adding disks to a disk group is best
illustrated through examples.
Since no FAILGROUP clauses are included in the ALTER DISKGROUP statement, each
disk is assigned to its own failgroup. The NAME clauses assign names to the disks,
otherwise they would have been assigned system generated names.
Assume that disk discovery now identifies the following disks in directory /devices:
The following statement will fail, since the /devices/diska2 search string only
matches a disk that already belongs to dgroup1:
The following statement to add disks to dgroup1 will fail because the search string
matches a disk that is contained in another disk group. Specifically,
/devices/diskc1 belongs to disk group dgroup2.
When a disk is dropped, the disk group is rebalanced by moving all of the file extents
from the dropped disk to other disks in the disk group. The header on the dropped
disk is cleared. If you specify the FORCE clause for the drop operation, the disk is
dropped even if Automatic Storage Management cannot read or write to the disk. You
cannot use the FORCE flag when dropping a disk from an external redundancy disk
group.
This example drops diska5 (the operating system independent name assigned to
/devices/c0t4d0s2 in "Adding Disks to a Disk Group: Example 1") from disk
group dgroup1.
This example also shows dropping diska5 from disk group dgroup1, but it illustrates
how multiple actions are possible with one ALTER DISKGROUP statement.
The RESIZE clause of ALTER DISKGROUP enables you to perform the following
operations:
If you do not specify a new size in the SIZE clause then Automatic Storage
Management uses the size of the disk as returned by the operating system. This could
be a means of recovering disk space when you had previously restricted the size of the
disk by specifying a size smaller than disk capacity.
The new size is written to the ASM disk header record and if the size of the disk is
increasing, then the new space is immediately available for allocation. If the size is
decreasing, rebalancing must relocate file extents beyond the new size limit to
available space below the limit. If the rebalance operation can successfully relocate all
extents, then the new size is made permanent, otherwise the rebalance fails.
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.
The following example cancels the dropping of disks from disk group dgroup1:
You can manually rebalance the files in a disk group using the REBALANCE clause of
the ALTER DISKGROUP statement. This would normally not be required, since
Automatic Storage Management automatically rebalances disk groups when their
composition changes. You might want to do a manual rebalance operation if you want
to control the speed of what would otherwise be an automatic rebalance operation.
The POWER clause of the ALTER DISKGROUP ... REBALANCE statement specifies the
degree of parallelization, and thus the speed of the rebalance operation. It can be set to
a value from 0 to 11, where a value of 0 stops rebalancing and a value of 11 (the
default) causes rebalancing to occur as fast as possible. The power level of an ongoing
rebalance operation can be changed by entering the rebalance statement with a new
level. If you specify a power level of 0, rebalancing is halted until the statement is
either implicitly or explicitly reinvoked.
The ALTER DISK GROUP ... REBALANCE statement uses the resources of the single
node upon which it is started. ASM can perform one rebalance at a time on a given
instance. The rebalance power is constrained by the value of the ASM_POWER_LIMIT
initialization parameter.
You can query the V$ASM_OPERATION view for help adjusting ASM_POWER_LIMIT and
the resulting power of rebalance operations. If the DESIRED_POWER column value is
less than the ACTUAL_POWER column value for a given rebalance operation, then
ASM_POWER_LIMIT is impacting the rebalance. The EST_MINUTES column indicates the
amount of time remaining for the operation to complete. You can see the effect of
changing the power of rebalance by observing the change in the time estimate.
Rebalancing continues across a failure of the ASM instance performing the rebalance.
See Also:
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:
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.
To add a new template for a disk group use the ADD TEMPLATE clause of the ALTER
DISKGROUP statement. You specify the name of the template, its redundancy attributes,
and its striping attribute.
This statement creates a template that applies the following attributes to files:
This statement creates a new template named unreliable that specifies files are to be
unprotected (no mirroring). Oracle discourages the use of unprotected files; this
example is presented only to further illustrate how the attributes for templates are set.
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.
The following example changes the striping attribute specification of the reliable
template for disk group dgroup2.
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.
This example drops the previously created unprotected template for dgroup2:
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.
See Also:
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.
The following statement creates a hierarchical directory for disk group dgroup1,
which can contain, for example, the alias name +dgroup1/mydir/control_file1:
Renaming a Directory
The RENAME DIRECTORY clause of the ALTER DISKGROUP statement enables you to
rename a directory. System created directories (those containing system alias names)
cannot be renamed.
Renaming a Directory: Example
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.
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
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.
The following statement adds a new alias name for a system generated file name:
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.
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.
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.
The following statement will fail because it attempts to delete a system alias. This is
not allowed:
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.
• 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:
In this example the system generated filename is used to drop the file and any
associated alias:
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:
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.
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.
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.
See Also:
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.
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.
Valid Context
Single-File Multiple-File
Filename Form Reference Creation Creation
Fully qualified filename Yes No No
Numeric filename Yes No No
Alias filename Yes Yes No
Alias with template filename No Yes No
Incomplete filename No Yes Yes
Incomplete filename with No Yes Yes
template
Note:
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. The
fully qualified filename is also referred to as the system alias filename.
A fully qualified filename is derived by Automatic Storage Management and has the
following form:
+group/dbname/file_type/file_type_tag.file.incarnation
Where:
+dgroup2/sample/controlfile/CF.257.1
Table 12-3 Oracle File Types and Automatic Storage Management File
Type Tags
Automatic
Storage
Management Automatic Storage
file_type Description Management file_type_tag Comments
CONTROLFILE Control files Current --
and backup
control files Backup
DATAFILE Datafiles and tsname Tablespace
datafile into which the
copies file is added
ONLINELOG Online logs group_group# --
ARCHIVELOG Archive logs thread_thread#_seq_sequence# --
TEMPFILE Tempfiles tsname Tablespace
Automatic
Storage
Management Automatic Storage
file_type Description Management file_type_tag Comments
into which the
file is added
BACKUPSET Datafile and hasspfile_timestamp hasspfile
archive log can take one
backup of two values:
pieces; s indicates
datafile that the
incremental backup set
backup pieces includes the
spfile; n
indicates that
the backup set
does not
include the
spfile.
PARAMETERFILE Persistent spfile
parameter
files
DAATAGUARDCONFIG Data Guard db_unique_name Data Guard
configuration tries to use
file the service
provider
name if it is
set. Otherwise
the tag
defaults to
DRCname.
FLASHBACK Flashback log_log# --
logs
CHANGETRACKING Block change ctf Used during
tracking data incremental
backups
DUMPSET Data Pump user_obj#_file# Dump set
dumpset files encode
the user
name, the job
number that
created the
dump set, and
the file
number as
part of the
Automatic
Storage
Management Automatic Storage
file_type Description Management file_type_tag Comments
tag.
XTRANSPORT Datafile tsname --
convert
AUTOBACKUP Automatic hasspfile_timestamp hasspfile
backup files 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.
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.
+dgroup2.257.8675309
Alias ASM filenames can be used both for referencing existing ASM files and for
creating new ASM files. Alias names start with the disk group name, after which you
specify a name string of your choosing. Alias filenames are implemented using a
hierarchical directory structure, with the slash (/) character separating name
components. You must have already created the directory structure, using the ALTER
DISKGROUP ... CREATE DIRECTORY statement as explained in "Managing Disk
Group Directories ".
Alias ASM filenames are distinguished from fully qualified or numeric names
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
Files created using an alias are not considered Oracle-managed files and may require
manual deletion in the future if they are no longer needed.
An alias ASM filename with template is used only for ASM file creation operations.
They are of the format:
+dgroup(template_name)/alias
+dgroup1(spfile)/config1
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.
Automatic Storage Management uses a system default template to determine the ASM
file redundancy 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, then the datafile template is used.
+dgroup1
+dgroup1(datafile)
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"
INSTANCE_TYPE = RDBMS
o DB_CREATE_FILE_DEST
o DB_CREATE_ONLINE_LOG_DEST_n
o DB_RECOVERY_FILE_DEST
o CONTROL_FILES
o LOG_ARCHIVE_DEST_n
o LOG_ARCHIVE_DEST
o STANDBY_ARCHIVE_DEST
Some additional initialization parameter considerations:
o LOG_ARCHIVE_FORMAT is ignored if a disk group is specified for
LOG_ARCHIVE_DEST (for example, LOG_ARCHIVE_DEST =
+dgroup1).
o DB_BLOCK_SIZE must be one of the standard block sizes (2K,
4K, 8K, 16K or 32K bytes).
o 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.
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.
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 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 multifile creation context form of
ASM filenames as a destination:
• Datafiles
• Tempfiles
• Control file
DB_CREATE_ONLINE_LOG_DEST_n Specifies the default disk group location in which to
create:
Initialization Parameter Description
• 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 specifies a
default disk group for a flash recovery area that
contains a copy of:
• Control file
• Redo log files
The following initialization parameters accept the multifile 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.
You can specify ASM filenames in the file specification clause of your SQL
statements. If you are creating a file for the first time, then use the creation form of an
ASM filename. If the ASM file already exists, then the filename must be in a
reference context form and, if trying to re-create the file, the REUSE clause specified.
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 Using
Automatic Storage Management".
If a reference context form is used with the REUSE clause, and the file does not exist,
the numeric portion of the reference context form is ignored, and a new file is created
as if the incomplete filename had been specified.
Partially created files resulting from system errors are automatically deleted.
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.
DB_CREATE_FILE_DEST = '+dgroup1'
DB_RECOVERY_FILE_DEST = '+dgroup2'
DB_RECOVERY_FILE_DEST_SIZE = 10G
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.
See Also:
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.
DB_CREATE_FILE_DEST = '+dgroup2'
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:
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.
The following statement drops the file manually after the tablespace has been
dropped:
ALTER DISKGROUP dgroup3 DROP FLE '+dgroup3/myfiles/my_undots';
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'
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 Using Automatic Storage Management: Example
1
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:
+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
RMAN can also be used for moving databases or files into ASM storage.
See Also:
See Also: