Oracle 10g Automatic Storage Management (ASM), Part 3: Advanced Features

Synopsis. Oracle 10g’s Automatic Storage
Management (ASM) features offer powerful tools to Oracle DBAs to create and
manage a robust, flexible, scalable file storage system ready for access by any
existing Oracle database instance. This article – the third and final in this
series – navigates the myriad ASM file naming conventions and templates,
provides examples of ASM storage management commands for adding and removing
disks and disk groups, and covers how to convert an entire Oracle database to
use ASM storage instead of regular file system storage.

The previous
in this series presented complete demonstrations of how to set up
an ASM instance in both Linux and Windows NT, as well as how to use Oracle 10g’s
Enterprise Manager (EM) to monitor and manage an ASM instance. This article
will focus on ASM instance administration, including how to add, alter,
and remove ASM disks and disk groups
, how to increase the survivability
of ASM disk groups
with additional striping and mirroring features, and how
to migrate an entire Oracle database from regular to ASM storage.

Before I turn my attention to those topics, though, I
will review how ASM’s file naming conventions help to make quick work of
organizing database files and components within an ASM instance.

ASM Naming Conventions

The first thing I noticed when I began my ASM explorations
was the unique method of file naming that ASM employs. All ASM file
names are based on the Oracle Flexible Architecture (OFA) standard. ASM
also employs Oracle Managed File (OMF) structures and rules for file creation,
which means that Oracle will clean up after itself when files are no longer
needed. For example, if I drop a tablespace, ASM will figure out which
datafile(s) are no longer required and will then automatically remove the
physical files without any intervention on my part. If an RMAN backup fails,
ASM (through OMF) will simply delete any partial files created as part of that
failed backup.

One big advantage of this approach is that I have a lot less
to worry about when it comes to physical file management. Instead of being
concerned about whether I’m using "acceptable" names for physical
files, I can simply let ASM worry about this instead, thus freeing me up to
concentrate on which logical objects I need to create to support my database.

ASM File Templates

ASM uses file templates to figure out how to configure
the myriad attributes for a new Oracle database file. A file template is simply
a named collection of attributes associated with an ASM disk group;
whenever a new file is created within a disk group, these attributes are
applied to the file. Templates also help to simplify file creation because they
can be used to map complex file attributes to a single specification. Certain attributes of an ASM file are set forever
when the file is initially created, including the file’s protection policy
and striping policy.

Default Templates. When a disk group is created, ASM
associates it with a set of initial system default templates that
include default attributes for the various Oracle database file types
like control files (CONTROLFILE) or data files (DATAFILE). Also, the DBA can
mandate whether files created via the template should be two-way or three-way
mirrored, as well as whether files created under that template are COARSE or
FINE striped. Table 3.1 lists these default templates and their

Table 3.1: ASM Default File
Templates and Attributes

Database File Type

ASM Default Template

ASM File Type

ASM Tag Assigned

ASM Default Striping

Archived Redo Logs





Archived Redo Log Backup



Specified by client


Control Files





Control File Autobackups



Specified by client


Cross-Platform Converted
Data Files





Data Files





Data File Backup Pieces



Specified by client


Data File Backup Image





DataGuard Broker





DataPump DUMPSet





Flashback Logs





Online Redo Logs





Server Initialization










These system default templates cannot be deleted; depending
on the defined disk group redundancy characteristics, the system templates are
created with the attributes exactly as shown. However, some of the attributes
of the default templates can be modified (except for redundancy and striping,
of course). It is also possible to add new user-defined file templates for
special types of database files; this can assist in standardization of database
physical and logical structures. See Listing 3.1 for
examples of how to create and drop user-defined templates.

There is one unfortunate drawback of ASM file templates: If
an ASM file attribute needs to be modified after the file has been created,
the file must be copied via RMAN into a new file with the new settings.
Changing the template that was originally used to create the ASM file does not
automatically populate the change to the file itself.

ASM File Names: Some Illustrations

To demonstrate these sundry naming patterns, I will use an
actual example of just one ASM file — the datafile for the TBSASM tablespace –
to show how templates and file naming conventions combine to help manage ASM
file naming standards. Which pattern to use for an ASM file name depends on
the context of how the filename is going to be used: (a) when an existing
file is being referenced; (b) during the creation of just one file;
and (c) during the creation of multiple files.

Fully-Qualified Names. When an ASM-managed file is
created, ASM assigns the file a fully-qualified, unique file name. This file
name – also known as a system alias – is the most detailed description
of the ASM file, so it is the most direct method to access any ASM file. Since
ASM constructs the system alias automatically when the file is created, fully-qualified
names are not permitted to be specified when creating the file, and no user is
permitted to modify this name.

Here is an actual example of a fully-qualified ASM file
name; it is the name of the file that represents the datafile for the TBSASM


A fully-qualified file name comprises the following five
components, and always ends with a special number pair:

  • <group>. The name of the ASM disk group.

  • <dbname>. The database that owns this ASM

  • <file type>. The Oracle file type (e.g.

  • <tag>. Type-specific information about the
    file. In this case, it is the corresponding tablespace name for the datafile.

  • <file>.<incarnation>. A special number pair
    that ASM generates to insure uniqueness.

Numeric Names. This type consists of just two
components, the disk group and the unique numeric identifier that
ends the file name and that is automatically assigned by ASM during file
creation. Therefore, this file name type can only be used for referencing
existing ASM files.
To continue the previous example, here is the file name
that represents the datafile from the TBSASM tablespace:


Incomplete Names. Incomplete ASM file names are used
only for file creation operations. They consist of a disk group name only.
ASM will then use the appropriate default template to translate the incomplete
ASM file name, as defined by its file type. For example, here is the SQL
command I executed originally to create the TBSASM tablespace in the ASM1DG1 disk group:


Incomplete Names With Named Template. Incomplete ASM
file names with named templates are used only for file creation operations.
They consist of a disk group name plus a template name. The
template name determines the file creation attributes of the file. For example:


ASM File Name Aliases

ASM file name aliases can be used to create new or
reference existing ASM files. While aliases do specify a disk group name,
they include a user-friendly name string instead of a file and
incarnation number. (In fact, if I attempt to construct an alias that ended
with a dotted pair of numbers, Oracle will detect the problem and will signal
an error.)

Aliases are implemented using a hierarchical directory
thus making it simple to reference ASM files via common-sense, human-recognizable
. I can create an additional alias for each file during its creation,
or I can create an alias after its creation via the ALTER DISKGROUP ADD ALIAS command.

ASM file name aliases are case-insensitive, and will
always contain a slash (/) that separates its components; each component
is stored in UTF-8 format and may be up to 48 bytes long, but the component
itself cannot contain a slash. The components of alias file names can contain
spaces between sets of characters, but the space should not be the first or
last character of a component. This implies a 48-character limit in a
single-byte language, but in a multi-byte language, this size limit will be
lower depending upon how many multi-byte characters are present in the string.

The total length of an aliased file name, including all
components and all separators, is limited to 256 bytes. I can create directory
as required to support whatever alias naming convention is
desired, but it is important to remember that these directories will still be
subject to the 256-byte limit.

A common use of an ASM file name alias is during the
creation of the database’s control files using the CONTROL_FILES parameter, or
when creating online redo log files. The following example assumes that I have
already created a directory named LOGFILES:

SQL> ‘+ASM1DG1/logfiles/log4a.rdo’ SIZE 32M,
SQL> ‘+ASM1DG1/logfiles/log4b.rdo’ SIZE 32M;

Aliased Names Plus Templates. This file name format
lists the disk group name, an alias name, and a file creation
template name
. It is therefore used only during ASM file creation
operations. For example, this statement assumes that an aliased directory, dbf,
already exists, and that I am creating a server parameter file from a parameter


Finally, it is important to note that an ASM file that was created
by specifying a user alias will not be cleaned up automatically by ASM
when the file is dropped later.

Listing ASM File Name Aliases. To retrieve all ASM
file name aliases stored within the database, the V$ASM_ALIAS dynamic view can be traversed, starting
at the ASM disk group level and then traverse the hierarchy of the alias
information stored within. Note that the REFERENCE_INDEX number is required to traverse
entries that are directory entries in this view; for all other alias entry
will be zeroed out.

See Listing
for examples of how to construct directories and aliases, query the
ASM instance for all available aliases, and drop aliases and directories.

Using ASM File Names in SQL Commands. Instead of
supplying the full ASM file name, any of the other indirect naming methods
mentioned above can be used when specifying an ASM file in a SQL command. This
is in fact one of the biggest benefits of ASM: the need to specify long,
cumbersome file names is reduced in almost every case
. Oracle recommends
using "shorthand" ASM file designations or ASM aliases as much as
possible except for the few specific cases where ASM file names are needed as
parameters (for example, when specifying the names of the database’s online
redo logs during an ALTER DATABASE RENAME FILE

Default File Sizes. When ASM creates a data file for
a permanent table space, or a temporary file for a temporary table space, the
data file is set to auto-extensible with an unlimited maximum size and 100 MB
default size. An AUTOEXTEND clause may override this default. ASM applies
attributes to the files it creates as specified by the corresponding system
default template.

Some Exclusions. Finally, it is important to remember
that ASM does not manage any binary files (i.e. BFILEs), alert logs,
user or background trace files,
or Oracle database password files.
These files must still be named, backed up, and managed via manual methods.

Managing An ASM Instance

Now that I have detailed ASM file naming techniques, I will
turn my attention to the nuts and bolts of managing an ASM instance. Besides
creating new files on the instance, I also need to know how to add new disks
and new disk groups
, modify disk group components, mount and dismount
disk groups, and remove existing disks and disk groups from the ASM
instance. Since ASM disk concepts are at the heart of these operations, an
expanded exploration of ASM striping, mirroring techniques, and disk
failure groups
is in order.

Jim Czuprynski
Jim Czuprynski
Jim Czuprynski has accumulated over 30 years of experience during his information technology career. He has filled diverse roles at several Fortune 1000 companies in those three decades - mainframe programmer, applications developer, business analyst, and project manager - before becoming an Oracle database administrator in 2001. He currently holds OCP certification for Oracle 9i, 10g and 11g. Jim teaches the core Oracle University database administration courses on behalf of Oracle and its Education Partners throughout the United States and Canada, instructing several hundred Oracle DBAs since 2005. He was selected as Oracle Education Partner Instructor of the Year in 2009. Jim resides in Bartlett, Illinois, USA with his wife Ruth, whose career as a project manager and software quality assurance manager for a multinational insurance company makes for interesting marital discussions. He enjoys cross-country skiing, biking, bird watching, and writing about his life experiences in the field of information technology.

Latest Articles