Oracle 10g Automatic Storage

Management, Part 1: Overview

By Jim Czuprynski
Synopsis. Oracle 10g's new Automatic Storage Management (ASM) features allow an
Oracle DBA to take advantage of a robust, flexible, scalable file storage system that any
Oracle database instance can access. This article - the first in this series -- provides a highlevel overview of the ASM architecture, and should be helpful to any DBA contemplating the
adoption of ASM for storing Oracle database files as part of a high-volume storage solution.
With the possible exception of having to rebuild a database server from a "cold metal"
starting point, I have to admit that the scenario that holds the most dread for me as an
Oracle DBA is to run out of disk space for a production database's datafiles or tempfiles.
Though, in most cases this situation can be rectified easily - as long as there is sufficient
disk space available, of course! - it always seems that these challenges seem to occur either
at the busiest time of my client's business day, or between 02:00 and 03:00 on an early
Sunday morning when I am scheduled to be out of town enjoying a long weekend. And I
have also encountered my share of unexpected (and unlikely) disk media failures. For
example, I once watched five disks in a 42-disk mirrored storage array fail within a threeweek period after three years of relatively solid performance. The pattern never repeated
itself, but it did teach me the value of a good mirroring strategy!
While a storage area network (SAN) and other logical volume manager (LVM) storage
solutions like EMC are certainly options for guaranteed storage reliability, the costs of these
solutions can be prohibitive for smaller IT organizations. The good news is that Oracle 10g
supplies a new set of disk media storage features called Automatic Storage Management
(ASM) that are aimed directly at insuring a storage solution for smaller enterprise
databases. This series of articles will delve into ASM's rich features and provide examples of
how to implement some simple ASM disk configurations for evaluation purposes so that your
DBA team can make some decisions about whether ASM is worth pursuing for your
organization. I will concentrate this article on a general review of ASM features as well as a
brief explanation of the ASM architecture.
Automatic Storage Management Features
Out-Of-The-Box Functionality. First off, ASM was designed specifically for the storage of
Oracle database files. This means that it is ready "out of the box" for use against any Oracle
database that it services. Though ASM appears to be the intended replacement for Oracle
Cluster File System (OCFS) for the Real Applications Cluster (RAC) environment, that
doesn't mean that your database needs to be deployed under RAC to take advantage of
ASM's myriad features; ASM can be deployed on a single processor (SMP) server just as
easily as it can be deployed on a multiple-node RAC cluster. Moreover, it is simple to
configure using the graphic interface provided by the Database Configuration Assistant
(DBCA), an existing Oracle tool that just about every Oracle DBA has used. Oracle 10g also
provides the standard Enterprise Manager (EM) interface for managing an ASM instance
once it has been created.

Flexible Storage Configuration. Since ASM is in essence its own file management
system, this means that I can add more physical storage, change storage configurations, or
remove extraneous storage without having to shut down my Oracle database to change out
physical hardware. This is a big advantage over traditional hardware configurations, and is
certainly featured in storage-area networks (SANs).
Using ASM also means that I can turn over the majority of my space management tasks to
the ASM instance and let it monitor the growth of my database's tablespaces. In addition,
ASM maintains pre-existing Oracle database functionality, so regular Oracle databases can
continue to operate as usual. New database files can be created as ASM files managed by
the ASM instance, existing database files can be migrated to ASM as time and opportunity
permit, and other database files can continue to exist as "traditional" database files without
ASM file management.
Fault Tolerance. I also expect any file management system to insure that once I write
database information to disk, it will never be lost - unless, of course, I tell the database to
delete that data. One way that DBAs usually guarantee against the inevitable failure of disk
hardware is through mirroring drives via redundant arrays of inexpensive disks (aka RAID)
and striping (writing portions of disk files to different disks so that if one disk is lost the
information is recoverable from another disk in the set). This guards against the inevitable
failure of disk hardware, since even with extremely high estimated mean time between
failures (MTBF), a disk drive will almost certainly fail eventually.
Most operating systems provide controls to set up and monitor disk storage to take
advantage of these redundancy features. Like any good file management system, ASM
provides fault tolerance by allowing me to write duplicate or triplicate copies of any
database files' contents. And if my current server and disk storage system already support
fault tolerance, so much the better! ASM can also take advantage of existing vendorsupplied fault tolerance mechanisms for increased guarantees to safe data storage.
Since ASM handles the mirroring of data, there is no need to purchase a third-party Logical
Volume Manager (LVM). Mirroring is applied on a file-by-file basis, rather than on a pervolume basis, so the same disk group may contain a combination of files protected by
mirroring (or perhaps not even mirrored at all, if mirroring is not required for some files).
ASM also supports Oracle Real Application Clusters (RAC), so there is no need for a separate
Cluster LVM or a Cluster File System.
I/O Load Balancing. ASM is responsible for providing equal distribution of I/O loads
across all available disk storage resources, so there is a measurable performance
improvement. For example, ASM will split a datafile into its component extents and then
spread those extents evenly across all defined disks that ASM is managing; those extents
are then tracked via an indexing technique. ASM also automatically manages data via
selection of desired reliability and performance characteristics instead of manually
manipulating data file storage characteristics, and therefore it tends to reduce (or even
eliminate) manual tuning and retuning of I/O.
A big advantage to this approach is that when ASM storage capacity changes, ASM doesn't
need to re-stripe all data - it just moves enough data in proportion to the amount of added
(or reduced!) storage, thus redistributing the datafile's extents evenly and keeping a
balanced data load across all disks. Moreover, since ASM can accomplish the rebalancing act
while the database is active, there is virtually no impact on database availability. I can also
instruct ASM to increase the speed of a space rebalancing operation if I know that sufficient

system resources are available, or I can tell ASM to reduce the speed of the rebalancing
operation to limit the impact on the ASM I/O subsystem.
Productivity Increases. Here is one final, intangible benefit of ASM: an increase in my
productivity as a DBA. Since I am freed up from physical and logical space management
worries, I can now concentrate my limited and valuable time on more critical database
tuning issues, like poorly-structured SQL statements and inefficient logical storage
structures that tend to be the real culprits behind database performance issues.
The ASM Instance
The ASM instance is at the heart of Automatic Storage Management. Rather than
"reengineer the wheel," Oracle decided to adopt the basic architecture of a normal Oracle
database instance. An ASM instance never actually opens a database; instead, it is
responsible for storing and processing the metadata that is required to make available the
files stored within the ASM storage system to non-ASM Oracle databases (henceforth
referred to as database instances).
In addition to the normal database background processes like CKPT, DBWR, LGWR, SMON,
and PMON, an ASM instance uses at least two additional background processes to manage
data storage operations. The Rebalancer process, RBAL, coordinates the rebalance activity
for ASM disk groups, and the Actual ReBalance processes, ARBn, handle the actual
rebalance of data extent movements. There are usually several ARB background processes
(ARB0, ARB1, and so forth). I will talk more about disk rebalancing operations in the final
article in this series.
Starting Up and Shutting Down an ASM Instance. The ASM instance can be can be
started in NOMOUNT mode, and ASM disk groups are mounted via the MOUNT command.
Similarly, disk groups can be taken offline with the SHUTDOWN command. When an ASM
instance is started and appropriate ASM disk groups are mounted, all ASM files contained on
those disk groups are made accessible to any Oracle database. Any database instance can
use the ASM disk groups as targets for creating new ASM-managed files.
Managing an ASM Instance. Managing access to the ASM instance is relatively
straightforward. The DBA can issue the ALTER SYSTEM ENABLE RESTRICTED SESSION;
command to prevent database instances from accessing ASM disk groups while maintenance
is being performed against the ASM instance or any ASM disk groups. Alternatively, issuing
the ALTER SYSTEM DISABLE RESTRICTED SESSION; command re-enables access to the
ASM instance.
The only way to connect to an ASM instance is via OS authentication (i.e. SYSDBA or
SYSOPER) because an ASM instance does not have a data dictionary per se. Connecting to
an ASM via a remote connection implies, of course, that a password file must be used.
Normally, the SYSDBA privilege is granted through the use of an operating system group
(on UNIX or Linux, typically the dba group). Since by default members of that group have
SYSDBA privilege on all instances on the node, including the ASM instance, any user that
connects to the ASM instance with the SYSDBA privilege has administrative access to all
ASM disk groups in the system.
The SYSOPER privilege is also supported in ASM instances and limits the set of allowable
SQL commands to the minimum required for basic operation of an already-configured
system. A user with SYSOPER permissions can start up or shut down an ASM instance, take

disk groups online or offline, issue a manual rebalance request, and verify a disk group.
However, more advanced command sets like those for creating new ASM disk groups,
resizing ASM disks, adding new ASM disks to existing ASM disk groups, and dropping ASM
disk groups are reserved to users with the SYSDBA privilege.
The ASM Storage Hierarchy
ASM provides a flexible storage hierarchy for managing access to its disk files, starting with
the smallest unit of storage, the Allocation Unit (AU). All ASM disk space is partitioned in
AUs of 1 MB each, and blocks will never be split across any allocation unit.
ASM Files. Next in the hierarchy are the actual ASM files themselves. With the exception of
trace files and operating system files, ASM can store every type of Oracle database file,
including control files, server parameter files (SPFILEs), datafiles, tempfiles, online redo
logs, archived redo logs, flashback logs, DataPump dump sets. In addition, ASM can store
all types of files managed by Recovery Manager (RMAN), including backup sets, archived
redo log image copies, datafile image copies, and autobackups.
ASM Disk Groups. The highest level of storage unit in an ASM instance is the ASM Disk
Group. An ASM disk group can support multiple files that belong to multiple Oracle database
instances. Each ASM disk group consists of one or more ASM Disks, and an ASM Disk
belongs to one and only one ASM Disk Group. All ASM files in the ASM Disk Group will be
spread across all the ASM disks in the ASM disk group; however, a single ASM File will never
span more than one ASM disk group.
ASM disk groups are accessible by either ASM instances or database instances, and
database instances can access the contents of ASM files directly, communicating with an
ASM instance only to get information about the layout of these files. An ASM instance
supports the addition of new ASM disks, deletion of existing ASM disks and disk groups, and
modifications to existing ASM disk groups (e.g. adding new ASM disks).
ASM File Naming Conventions and File Name Aliasing. ASM uses a four-layer file name
to identify an ASM file. The ASM file name consists of the ASM disk group name, the
database instance name, and the file type; the final file name component consists of three
tokens, a file type token (e.g. CF for control file) and two integer values. The combination of
these file name components insures that an ASM file name is always unique and can be
easily tied back to its owning ASM disk group and database instance. Since the ASM file
naming convention can be cumbersome, ASM also supports file name aliases for easier
referencing of the ASM file instead of using the fully-qualified ASM file name.
Implementing ASM Storage In Oracle Databases
Every database instance that uses ASM for file storage will also need two new processes.
The Rebalancer background process (RBAL) handles global opens of all ASM disks in the
ASM Disk Groups, while the ASM Bridge process (ASMB) connects as a foreground process
into the ASM instance when the regular database instance starts. ASMB facilitates
communication between the ASM instance and the regular database, including handling
physical file changes like data file creation and deletion.
ASMB exchanges messages between both servers for statistics update and instance health
validation. These two processes are automatically started by the database instance when a

new Oracle file type - for example, a tablespace's datafile -- is created on an ASM disk
group. When an ASM instance mounts a disk group, it registers the disk group and connect
string with Group Services. The database instance knows the name of the disk group, and
can therefore use it to locate connect information for the correct ASM instance.
ASM Instance Failure Scenarios. There are some implications for any database instance
that is using ASM files for storage: When an ASM instance is shut down, any database
instance that is using that ASM instance to store ASM files will lose contact with those ASMmanaged files. Oracle 10g overcomes this potential failure scenario by allowing multiple
ASM instances to share ASM disk groups, so if one ASM instance should fail, another ASM
instance can continue to manage the changes to data stored on those disk groups.
Next Steps
The next article in this series will focus on a simple implementation of Automated Storage
Management. It provides examples of how to create an example ASM instance in both the
Red Hat Enterprise Linux (RHEL) and Windows NT environments as well as a demonstration
of how to implement basic ASM storage for an existing Oracle database instance.
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

Oracle 10g Automatic Storage

Management (ASM), Part 2:
Sample Implementation
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 second in this series
-- provides a simple yet practical demonstration of setting up an ASM instance in both the
Linux and Windows NT environments for purposes of exploration and experimentation,
including how to migrate existing tablespaces to the ASM storage environment.

The previous article in this series presented a high-level overview of Oracle 10g's new
Automatic Storage Management (ASM) features and how ASM instances can be used in
concert with other Oracle database instances to provide a scalable, reliable architecture for
managing and monitoring large disk volumes via the ASM file system. Please note that this
article and the corresponding examples are meant to demonstrate how ASM can be
implemented on a small scale as a confidence-building exercise and to show how easy it is
to set up ASM in an extremely basic single-CPU server environment. It is most definitely not
intended as a starting point for a full-blown ASM implementation, which does (and should!)
involve significant effort.
I will demonstrate how to set up an ASM instance in both the Linux and Windows NT
operating systems, how to set up tablespaces in a database instance that uses ASM for data
storage, and how to reconfigure Oracle 10g Enterprise Manager (EM) to monitor and
manage the ASM instance. For my test bed servers I utilized Red Hat Enterprise Linux
Advanced Server 3.0, kernel 2.4.1.2, and Windows XP 2002 Professional Service Pack 2 for
these demonstrations; except where noted, all code listed as part of this article should work
within either operating system.
Fortunately, the preparations required prior to creating the ASM instance and its disk groups
are the most difficult part of this demonstration; once that's done, the rest is relatively
simple.
Preparing Disks for ASM: Windows NT
To simulate implementation of ASM in the Windows NT environment, I first created raw disk
partitions on some of my hard drives. Fortunately, I had extra space on three of the four
disks in my test server, so I created several primary disk partitions sized at 100MB on each
of those three drives using the Windows Disk Partitioning utility (DISKPART.EXE):
C:\>
C:\>
C:\>
C:\>
C:\>
C:\>
C:\>
C:\>
C:\>
C:\>
C:\>
C:\>
...

select disk 2
Disk 2 selected.
create partition primary
Partition created.
create partition primary
Partition created.
create partition primary
Partition created.
select disk 3
Disk 3 selected.
create partition primary
Partition created.

size=100
size=100
size=100

size=100

Figure 2.1.1 shows the results of the successful disk partitioning.

Once the partitions are completed, I used the ASMTOOLG.EXE utility to "stamp" each
partition with an ASM label so that Oracle can recognize these partitions as candidate disks
for the ASM instance. I executed the ASMTOOLG.EXE program from the /bin directory of the
Oracle home path for my Windows NT database. Figure 2.1.2 shows the initial screen that
this GUI tool presented, and Figure 2.1.3 shows the screen that confirmed the creation of
the ASM labels. Once the labels were assigned, I then re-invoked ASMTOOLG to confirm

them (see Figure 2.1.4). I will also use ASMTOOLG to remove the labels prior to removing
these partitions once my simulation is completed.
Preparing Disks for ASM: Linux
It is much simpler to simulate deployment of ASM in the Linux environment. From the root
login, I created two new folders on separate disk spindles. I then used the dd command to
create several empty files ready for use as ASM disks, and then set the appropriate
permissions for those disks. See Listing 2.1 for the Linux commands required to
accomplish this. (If you do not have separate spindles available, don't worry; just create the
two folders on the same disk.)
Creating an ASM Instance Using DBCA In Windows NT
Now that I have completed preparing all my disks, I used Oracle 10g's Database
Configuration Assistant (DBCA), the simplest method to create an ASM instance, since the
specification of all ASM instance parameters and creation of the instance's ASM Disk Groups
is quite intuitive. I invoked DBCA from a command prompt on my Windows NT server and
followed these steps:

First, I chose the Create a Database option (Figure 2.2.1) and clicked the Next
button.
I selected General Purpose as the Database Type (Figure 2.2.2) and clicked the
Next button.

Next, I supplied values for the Global Database Name (Figure 2.2.3) and clicked the
Next button.

I then accepted all default values for the Management Options (Figure 2.2.4) and
clicked the Next button.

I supplied the same password for all database management accounts (Figure 2.2.5)
and clicked on Next.

At this point, I must decide to create the ASM instance. I did this by selecting the
Automatic Storage Management (ASM) option (Figure 2.2.6), at which point I was
presented with a screen for specification of the ASM instance's additional password
(Figure 2.2.7). Note that I could also click on the ASM Parameters button to
specify exactly which directories Oracle should search for candidates for ASM disks,
but in this case, I decided to let Oracle find the disks on its own. I clicked on Next to
let Oracle create the ASM instance.

Once the ASM instance had been created successfully, the screen in Figure 2.2.8
was presented. After I clicked on the Create New button, Oracle displayed the screen
in Figure 2.2.9 to show all Windows NT partitions that were candidates for ASM disk
group creation. I then selected the partitions desired, supplied a name for the ASM
disk group (DGROUP1), and clicked the OK button to complete the ASM disk group
creation.

Once the ASM disk groups were created, Oracle presented one last screen (Figure
2.2.10) to confirm the disk group creation. At this point, even though it seems
counter-intuitive, I clicked the Cancel button to complete the creation of the ASM
instance, as there are no further steps required.

Creating an ASM Instance Using DBCA in Linux

I used this same methodology to create an ASM instance in Linux using DBCA. The only
significant difference was the contents of the Disk Selection window (Figure 2.2.9), which
instead showed the candidate disks I had previously created on that server for the Linux
environment. In either of these cases, the end result is the same: Once I clicked on the
Cancel button on the last screen, Oracle dismounted the ASM disk group I had created and
then shut down the ASM instance as well.
Creating an ASM Instance without Using DBCA
Of course, I don't have to use DBCA to create an ASM instance. Personally, I prefer to use
command scripts to create my database because it is easier to customize the scripts to
create other ASM instances in the future, and it also gives me complete control over what
Oracle is doing "behind the screen." In addition, an ASM instance is extremely easy to
create because no CREATE DATABASE script is required, just an initialization parameter file
like the one shown in Listing 2.2. Besides the usual initialization parameters for trace file
directories, there are only a few additional ones required to create an ASM instance:

ASM Initialization Parameters

Initialization
Description
Parameter
INSTANCE_TYPE
Defines the instance as an ASM instance. This is the only required
parameter to identify an ASM instance; the remainder can be left
at their defaults
DB_UNIQUE_NAME Defines the service provider name for which this ASM instance
manages disk groups. +ASM is the default value, and should not
be modified unless multiple ASM instances are on the same node
ASM_POWER_LIMIT Controls rebalance operation speed. Values range from 1 to 11,
with 11 being the fastest. If omitted, this value defaults to 1. The
number of slaves is derived from the parallelization level specified
in a manual rebalance command (POWER), or by the
ASM_POWER_LIMIT parameter
ASM_DISKSTRING An operating system dependent value; used by ASM to limit the
set of disks considered for discovery
ASM_DISK_GROUPS Describes the list of ASM disk group names to be mounted by an
ASM instance at startup, or whenever the ALTER DISKGROUP
ALL MOUNT command is used
LARGE_POOL_SIZE The LARGE POOL size. This must be set to a minimum of 8MB,
but Oracle recommends setting this to 16MB
To create the ASM instance without using DBCA, I first made sure that I had created the
directories I specified for BACKGROUND_DUMP_DEST, CORE_DUMP_DEST, and
USER_DUMP_DEST. I also created a password file for the instance using the ORAPWD utility.
(This is important, because when you attempt to connect to the ASM instance from
Enterprise Manager, it will expect the instance to have the REMOTE_LOGIN_PASSWORDFILE
initialization parameter set to EXCLUSIVE so that the instance can be contacted remotely
and that means a password file will be required.)

ORAPWD file=c:\oracle\app\product\10.1.0\db_1\database\PWD+ASM.ora password=oracle

After I had made sure that the Oracle Cluster Services service was started in my Windows
NT environment - it is usually named OracleCSService in the list of Windows Services that I
can start - I then simply pointed my MS-DOS command window at the database instance by
setting the value for ORACLE_SID to +ASM, started a SQL*Plus session, created an SPFILE
from the parameter file, and then started the ASM instance in NOMOUNT mode:
C:\> set ORACLE_SID=+ASM
C:\> sqlplus "sys as sysdba"
SQL> Connected to an idle instance.
SQL> create spfile from pfile=c:\init+asm.ora;
SQL> File created.
SQL> startup nomount;
SQL> ASM instance started

Creating ASM Disk Groups without Using DBCA

If I am using DBCA to create my sample ASM instance, Oracle formats the commands
necessary to create the initial ASM disk group(s) for the instance during its creation.
However, I can also create the ASM disk groups separately after the necessary instance
creation scripts have run successfully using the code shown in Listing 2.3. I have provided
two different examples, one each for the Windows NT and Linux environments.
Starting and Stopping an ASM Instance
An ASM instance is managed in much the same way as a database instance, with a few
exceptions. The major difference is that an ASM instance is never opened like a regular
Oracle instance is opened, only mounted; therefore, I will either issue the STARTUP
NOMOUNT; command to start just the ASM instance's memory processes, and then finish
mounting the database with the ALTER DATABASE MOUNT; command. I can also open
the ASM instance immediately by issuing the STARTUP MOUNT; command.
Starting a Dormant ASM Instance. To start up a dormant ASM instance, I first have to
remember to set the ORACLE_SID environment variable appropriately. In addition, before I
can start the ASM instance in the Windows NT environment, I also need to remember to
first start the Oracle Cluster Service as well as the ASM instance's service. Of course, I do
not need to worry about this in the Linux environment the Cluster Service should have
already been set up as part of the standard Linux installation of Oracle 10g.
To start up the ASM instance, I then simply issue the STARTUP MOUNT command. Here is
how a successful ASM instance startup appears in the Linux environment:
$> export ORACLE_SID=+ASM
$> sqlplus "sys as sysdba"
SQL*Plus: Release 10.1.0.2.0 - Production on Tue Dec 13 16:58:17 2005

Copyright (c) 1982, 2004, Oracle. All rights reserved.

Enter password: ********
Connected to an idle instance.
SQL> startup mount;
ASM instance started
Total System Global Area 100663296 bytes
Fixed Size
787648 bytes
Variable Size
99875648 bytes
Database Buffers
0 bytes
Redo Buffers
0 bytes
ASM diskgroups mounted
Shutting Down an Active ASM Instance. To shut down this ASM instance, I once again
set the ORACLE_SID environment variable and then simply issue the SHUTDOWN
IMMEDIATE; command:
$> export ORACLE_SID=+ASM
$> sqlplus "sys as sysdba"
SQL> Connected.
SQL> shutdown immediate;
ASM diskgroups dismounted
ASM instance shutdown
SQL>
Implications of Shutting Down an Active ASM Instance. Now, a warning: When an
ASM instance is shut down, it is important to be aware of the implications for any regular
Oracle database instance that is using ASM files stored on that ASM instance. The ASM files
will not be accessible to those regular Oracle databases until the ASM instance is restarted.
Demonstrating ASM in a Sample Database
Now that I have explained how to create, start, and stop an ASM instance, I will next
demonstrate how to add a tablespace to an existing Oracle database instance that uses the
ASM instance's disk group instead of the database instance's disk storage to store the new
tablespace's datafile.
Creating an ASM-Managed Tablespace. What I really like about ASM is its simplicity. I
no longer need to be concerned if the tablespace's datafile will fit on the drive or spindle I
have targeted for storage; I simply inform ASM that it is responsible for storing the datafile
and how large the datafile is, and ASM handles the rest.
All I needed to do to create a new tablespace, TBS_ASM1, was to issue the following
CREATE TABLESPACE command from a SQL*Plus session running against the database
instance:
SQL> CREATE TABLESPACE tbs_asm1 DATAFILE '+DGROUP1' SIZE 32M;
Tablespace created.
Note that I did not have to specify the exact location of the datafile, since ASM determined
from the size of the tablespace exactly how it should be striped across the disks in the ASM
disk group. Moreover, since ASM uses Oracle Managed Files (OMF) for naming the datafile,

ASM automatically named the datafile using the appropriate OMF standard. (I will delve into
ASM file naming conventions in greater detail in the next article in this series.)
Even more interesting, I did not have to do anything special to inform the database instance
that it needed to start up the appropriate Rebalancing (RBAL) and ASM Bridge (ASM)
processes. As soon as this new tablespace was created, the database instance detected that
ASM storage was in use, and it automatically started these two background processes, as
this snippet from the database's alert log clearly shows:
...
Sun Dec 11 18:35:00 2005
CREATE TABLESPACE tbs_asm1 DATAFILE '+DGROUP1' SIZE 32M
Sun Dec 11 18:35:03 2005
Starting background process ASMB
ASMB started with pid=21, OS id=776
Starting background process RBAL
RBAL started with pid=22, OS id=3524
Sun Dec 11 18:35:09 2005
SUCCESS: diskgroup DGROUP1 was mounted
Completed: CREATE TABLESPACE tbs_asm1 DATAFILE '+DGROUP1' SIZ
...
Migrating an Existing Tablespace to ASM-Managed Storage. Another great thing
about ASM: I did not have to recreate an existing tablespace when I wanted to migrate it to
ASM storage. Instead, I used Recovery Manager (RMAN) to create an image copy of the
tablespace's datafile, and then I simply migrated that datafile to ASM. To demonstrate, I
created a new tablespace in the database instance. I then issued the appropriate RMAN
commands to take the tablespace offline, create the image copy of the tablespace, transfer
the tablespace to ASM, and then bring the tablespace back online. See Listing 2.4 for the
SQL statements and RMAN commands that I used to complete this task.
Setting Up Enterprise Manager (EM) for ASM Instance Management
Oracle 10g Enterprise Manager (EM) does provide a simple and elegant way to manage ASM
storage; however, I needed to reconfigure my database instance's EM configuration to take
advantage of these tools via the Enterprise Manager Configuration Assistant (EMCA). Once I
had created the ASM instance and had then created at least one ASM-managed file in my
database instance, I removed the original EM configuration for the database instance and
then replaced it with a new EM configuration that fully supports ASM. A sample set of EMCA
commands are shown in Listing 2.5.
After I restarted the EM Database Console service for my database, I was then able to view
details about the ASM instance as well by clicking on the ASM link on my database
instance's home page (see Figure 2.3 for an example of that screen). I will explore the
various diagnostic tools and maintenance operations available via EM in more detail in the
next article in this series.
Viewing ASM Instance Information Via SQL Queries
Finally, there are several dynamic and data dictionary views available to view an ASM
configuration from within the ASM instance itself:

ASM Dynamic Views: ASM Instance Information

View Name

Description

V$ASM_ALIAS

Shows every alias for every disk group mounted by the ASM
instance

V$ASM_CLIENT

Shows which database instance(s) are using any ASM disk groups
that are being mounted by this ASM instance

V$ASM_DISK

Lists each disk discovered by the ASM instance, including disks

that are not part of any ASM disk group

V$ASM_DISKGROUP Describes information about ASM disk groups mounted by the

ASM instance
V$ASM_FILE

Lists each ASM file in every ASM disk group mounted by the
ASM instance

V$ASM_OPERATION Like its counterpart, V$SESSION_LONGOPS, it shows each

long-running ASM operation in the ASM instance
V$ASM_TEMPLATE

Lists each template present in every ASM disk group mounted by

the ASM instance

I was also able to query the following dynamic views against my database instance to view
the related ASM storage components of that instance:

ASM Dynamic Views: Database Instance Information

View Name

Description

V$ASM_DISKGROUP Shows one row per each ASM disk group that's mounted by the
local ASM instance
V$ASM_DISK

Displays one row per each disk in each ASM disk group that are in
use by the database instance

V$ASM_CLIENT

Lists one row per each ASM instance for which the database
instance has any open ASM files

See Listing 2.6 for the SQL*Plus queries that I used to view information from the ASM and
database instances.

Next Steps
The next article in this series will concentrate on some of the more advanced features of
ASM, including how to add disks to and remove disks from an ASM disk group, how to
increase the survivability of ASM disk groups with additional striping and mirroring features,
and how to monitor and manage ASM storage through the Enterprise Manager (EM)
interface.
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:
B10130-02 Oracle Database Installation Guide 10g (10.1.0.2) For Windows,
Section 2.5.3
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