Oracle 10g Automatic Storage Management (ASM), Part 3: Advanced Features
January 26, 2006
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 article 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 characteristics.
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 tablespace:
A fully-qualified file name comprises the following five components, and always ends with a special number pair:
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:
SQL> CREATE TABLESPACE tbsasm DATAFILE '+ASM1DG1' SIZE 32M;
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:
SQL> CREATE TEMPORARY TABLESPACE temp01 SQL> TEMPFILE '+ASM1DG1(TEMPFILE)' SIZE 32M;
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 structure, thus making it simple to reference ASM files via common-sense, human-recognizable names. 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 structures 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 ALTER DATABASE SQL> ADD LOGFILE GROUP 4 SQL> MEMBERS 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 file:
CREATE SPFILE '+ASM1DG1/dbfs/(spfile)' FROM PFILE;
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 types, REFERENCE_INDEX will be zeroed out.
See Listing 3.2 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 operation).
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.