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:\> select disk 2
C:\> Disk 2 selected.
C:\> create partition primary size=100
C:\> Partition created.
C:\> create partition primary size=100
C:\> Partition created.
C:\> create partition primary size=100
C:\> Partition created.
C:\> select disk 3
C:\> Disk 3 selected.
C:\> create partition primary size=100
C:\> Partition created.
...
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 Parameter
Description
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
No comments:
Post a Comment