By Jim Czuprynski
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.
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
ARCHIVELOG
archive_log
parameter
coarse
Archived Redo Log Backup Pieces
BACKUPSET
backupset
Specified by client
coarse
Control Files
CONTROLFILE
controlfile
CF or BCF
fine
Control File Autobackups
AUTOBACKUP
autobackup
Specified by client
coarse
Cross-Platform Converted Data Files
XTRANSPORT
N/A
N/A
coarse
Data Files
DATAFILE
datafile
coarse
Data File Backup Pieces
BACKUPSET
backupset
Specified by client
coarse
Data File Backup Image Copies
BACKUPSET
datafile
coarse
DataGuard Broker Configurations
DATAGUARDCONFIG
drc
drc
coarse
DataPump DUMPSet
DUMPSET
dumpset
dump
coarse
Flashback Logs
FLASHBACK
rlog
fine
Online Redo Logs
ONLINELOG
online_log
log_
fine
Server Initialization Parameters
PARAMETERFILE
init
spfile
coarse
TEMPFILEs
TEMPFILE
temp
coarse
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:
ASM1DG1.ORCL.DATAFILE.TBSASM.257.1
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:
ASM1DG1.257.1
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.
Coarse vs. Fine-Grained Striping
When a new disk group is created, ASM will spread files in 1MB allocation unit (AU) chunks across all of the disks in a disk group. This default method, called coarse striping, eliminates the need for manual disk tuning. When striping is completed, all disks in the same ASM disk group should have about the same size and performance characteristics; this helps to insure that optimal I/O is attainable. For most installations, only a small number of disk groups should be sufficient (e.g., one disk group designated as a work area and one for a recovery area). Thus, even though the number of files and disks may increase, a constant number of disk groups will probably have to be managed.
Most ASM files stored in the ASM instance will perform well with normal (coarse) striping. However, Files like online redo logs, flashback logs, and control files typically require low latency. For these file types, ASM provides fine-grained (128K) striping. In this case, each AU is striped, and this tends to break up medium-sized I/O operations into many smaller I/O operations that will be executed in parallel.
Failure Groups
ASM failure groups provide mechanisms to prevent the failure of a set of disks within a single particular disk group that share a common resource whose failure must be tolerated. A typical example of this concept is a series of disks connected to a single, common disk controller. In this situation, if the controller failed, all the other disks on the controller's common bus would also be unavailable, even though all of the individual disks are still working fine. (Note that what constitutes a failure group tends to be site-specific and will depend upon the failure level(s) that a site can accept.)
By default, ASM assigns each disk to its own failure group. The DBA can, of course, select a different disk grouping when creating a disk group or adding a disk to a disk group. Once a set of failure groups are identified, ASM will tend to optimize file layout so that the possibility of data unavailability because of the failure of a shared resource is reduced.
Disk Group Mirroring
ASM provides three types of disk group mirroring possibilities. The first type, external redundancy, does not utilize failure groups at all and thus provides no mirroring. This type of redundancy is best when either the DBA has decided to rely upon external OS-level hardware mirroring, or when data loss is an acceptable risk due to media failure. Normal-redundancy disk groups are the ASM default, and they support two-way mirroring that insures two copies of a file extent will always exist on the disk group. Finally, high-redundancy disk groups support triple mirroring, which insures that there will always be three copies of each file extent on the disk group.
When ASM allocates a new primary extent for a file to one disk in a disk group, it allocates a mirror copy of that extent to another disk on one of the several available "partner" disks in the same disk group. Because ASM ensures that a primary extent and its mirror copy never reside in the same failure group, ASM can thus tolerate simultaneous failures of multiple disks in a single failure group. In addition, since ASM mirrors file extents instead of disks, ASM requires spare capacity only within that disk group, not among all disks.
When a disk fails – and all disks eventually do! - ASM reads the mirrored contents from the surviving disks and then automatically rebuilds the complete contents of the disk that has failed onto the surviving disks in the disk group. This also has the advantage of spreading out the I/O hit from the recovery from a disk failure across several disks.
Disk Group Rebalancing
ASM automatically rebalances a disk group whenever disks are added or dropped. Therefore, the rebalancing process requires no intervention. Because ASM uses special indexing techniques to distribute extents over all available disks in a disk group, re-striping of the data is not required; instead, ASM only moves enough data proportionally versus the amount of storage that's been added or removed. This evenly redistributes the files and keeps a balanced I/O load across all disks in the disk group.
Oracle recommends that, to avoid unnecessary data movement, it is generally more efficient to add or drop multiple disks simultaneously. This tends to insure that the disks will be rebalanced in a single operation.
Creating New Disk Groups
On to some practical examples! I have already set up some additional simulated disks on my Linux server, so I will next create a new ASM disk group via the CREATE DISKGROUP SQL command. See Listing 3.3 for the sample code I used.
Adding New Disks
If I want to add one or more ASM disks to an existing ASM disk group, I can use the ALTER DISKGROUP ADD DISK command. ASM performs the addition of ASM disks to an ASM disk group in a single operation. I can add specific ASM disks to a disk group by name, or I can choose to use a disk discovery string. The nice thing about the disk discovery string is that if ASM detects ASM disks that are already part of an ASM disk group in the folder specified by that string, the disks will be ignored and only those ASM disks that are not yet in use will be added.
When I add an ASM disk to a disk group, the ASM instance will determine if the disk is addressable and usable; if so, then the ASM disk is formatted and rebalanced. Rebalancing tends to be time-consuming because it moves extents from every file in the ASM disk group onto the new ASM disk. Though an ASM rebalancing operation does not block any ongoing database operations, rebalancing will definitely have at least some impact on the I/O load on the system. I can also tell the ASM instance to expend more resources on the rebalancing by increasing the value of the ASM_POWER initialization parameter.
See Listing 3.4 for an example of adding a new disk to an existing disk group while requesting a higher than normal amount of resources for rebalancing the affected ASM disk group.
Resizing Disks
I can easily resize an existing ASM disk via the ALTER DISKGROUP
Verifying ASM Disk Groups
Keeping my ASM disk groups in ship-shape condition should be one of my primary concerns. I can issue the ALTER DISKGROUP
Manually Rebalancing a Disk Group
Even though ASM will automatically rebalance a disk group when any operation other than a MOUNT, DISMOUNT, or CHECK has been issued, I also have the option to initiate a disk rebalancing manually. Issuing the ALTER DISKGROUP
If the optional POWER directive is specified, ASM will rebalance the disk group using the integer value to override the value that the ASM_POWER_LIMIT initialization parameter has set forth. I can thus override the speed of a potential rebalancing or change the power level of an ongoing rebalance operation by changing the POWER directive's value. In addition, if I set POWER to zero (0), any rebalancing on the disk group is halted until I directly or implicitly invoke the rebalancing operation again. See Listing 3.7 for an example of manual rebalancing a selected ASM disk group.
Mounting and Dismounting ASM Disk Groups
Dismounting a mounted ASM disk group is performed via the ALTER DISKGROUP
Removing Disks from a Disk Group
I can issue the ALTER DISKGROUP
Dropping a Disk Group
Finally, I can drop an entire existing ASM disk group – along with all of its files - via the DROP DISKGROUP command. If the disk group does still contain any files besides internal ASM metadata, then I have to specify the INCLUDING CONTENTS option as well. Also, the disk group to be dropped must be mounted. ASM will first validate that none of the disk group files are open, and then remove all of the assigned ASM disks and the disk group itself from the ASM instance. ASM will also overwrite the header of each previously used ASM disk to remove any remaining ASM formatting information. Listing 3.10 shows an example of this command.
Migrating a Database to ASM Storage
As discussed in the prior article in this series, ASM files cannot be accessed through normal operating system interfaces. Therefore, RMAN is the only means for copying files from regular storage to ASM, and is the only tool a DBA can use to migrate an entire database from regular to ASM storage. Oracle recommends the following process for a full database migration:
Step 1. Take a complete backup of the database before proceeding with any migration efforts. This will provide a relatively safe fallback position in case any of the migration steps outlined below should fail.
Step 2. Gather the file names of the current control files and online redo logs using V$CONTROLFILE and V$LOGFILE.
Step 3. Shut down the database in consistent mode using either SHUTDOWN IMMEDIATE, SHUTDOWN TRANSACTIONAL, or SHUTDOWN NORMAL. This is a crucial step.
Step 4. Change the database's server parameter file:
Set the necessary OMF destination parameters to the desired ASM disk group.
Remove the CONTROL_FILES parameter.
Step 5. Restore a control file from backup. This will migrate the control files to ASM storage automatically. Note that if an OMF control file is created but there is a server parameter file, then a CONTROL_FILES initialization parameter entry will also be created in the server parameter file.
Step 6. Issue ALTER DATABASE MOUNT; to mount the database.
Step 7. Edit and run an RMAN command file that:
Backs up the database
Switches the current data files to the backups
Renames the online redo logs. You can move only tablespaces or data files using the BACKUP AS COPY command
Step 8. Once the DBA is certain that the migration has been successful, she can delete the original database files left behind in the "regular" storage directories.
An example RMAN command script to accomplish Step 7 is shown in Listing 3.11.
Conclusion
While I have endeavored to introduce practical examples of how to employ Automatic Storage Management (ASM) within multiple Oracle 10g environments, I have truly just scratched the scratch on the surface of what ASM can accomplish. ASM places extremely powerful file management tools into the hands of every Oracle DBA, and it is definitely worth the effort to explore its features no matter the size of the database environment.
References and Additional Reading
While there is no substitute for direct experience, reading the manual is not a bad idea, either. I have drawn upon the following Oracle 10g documentation for the deeper technical details of this article:
B10739-01 Oracle Database Administrator's Guide, Chapter 12
B10743-01 Oracle Database Concepts, Chapter 14
B10755-01 Oracle Database Reference
B10759-01 Oracle Database SQL Reference
No comments:
Post a Comment