Professional Documents
Culture Documents
By Sean Hull
There's a lot of talk about ASM, but what the heck is it really? ASM is effectively
an abstraction layer, allowing your Oracle database to work with abstract space
called diskgroups, instead of datafiles directly. This provides lots of benefits, but
also requires learning some new concepts, commands, utilities, and
administration tasks. So take a look at what it solves, and what it takes to
manage and weigh the pros and cons before diving in with your production
systems.
1. for arch logs & backups, OS vendors don't provide shared disk filesystem
2. logical volume managers hide the location of files making it difficult to manage
disk I/O and provide good stats
4. OS's and Oracle don't handle databases well that have 1000's of datafiles
7. users at the OS level can touch Oracle files with standard utilities, without
Oracle knowing
So, he set out to solve these problems by building Oracle's own filesystem. His
intention was to provide these features:
1. tightly integrated with Oracle, and work with clusters (then parallel server)
2. If you want to squeeze out more performance from your existing disk
subsystem, and get better statistics for forcasting disk I/O.
Getting Started
ASM is managed by an instance, much like an Oracle database. However the
initialization parameters are much more limited and the startup process is
simpler.
b. Edit init.ora
$ sqlplus / as sysdba
SQL> startup
d. create diskgroups
As you might guess, creating a tablespace will change slightly. The default
method looks like this:
However, consider this great feature. If in your database init.ora file you set the
parameter
db_create_file_dest=+SEAN
Then let Oracle do the rest. In both cases, you'll find that the paths of files listed
in v$datafile will be relative to the abstract +SEAN diskgroup, not a real OS
datafile.
Of course simplifying filenames and tablespace creation is really only the tip of
the iceberg for what ASM can do for you. It can also provide a level of
redundancy as well.
However, if you don't already have this redundancy, ASM can provide it. You can
specify redundancy, failure groups, and a whole host of other options to protect
against loss of one or more disks, controllers, or even whole SAN failures. ASM
also provides evenly distributed I/O across a diskgroup. Since ASM has a better
picture of what's happening under the hood, Oracle can automatically provide a
better balance of I/O to disk for you.
In the end, it should be the business need that pushes this adoption. Also be
aware that ASM is still in the enterprise computing sense, relatively new. There
are a number of vendors whose core business has been in the logical volume
manager/filesystem space for years. Quite often, maturity matters a lot when it
comes to software systems, and reliability.
Conclusion
ASM is powerful stuff, providing solutions for the growing very large database
systems being deployed currently. It may also provide solutions for smaller
database installations, or those using clustering. As with any new technology,
evaluate, test, and then test some more.
Oracle 10g Automatic Storage Management:
Overview
By Jim Czuprynski
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 three-week 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.
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 vendor-supplied 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 per-volume 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.
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.
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.
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 ASM-managed 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.
Oracle 10g Automatic Storage Management (ASM):
Sample Implementation
By Jim Czuprynski
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.
Figure 2.1.1 Listing Volumes Created via DISKPART.EXE commands (NT environment).
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.
Figure 2.1.2 Using ASMTOOLG.EXE to label partitions created via DISKPART.EXE (NT
environment).
Figure 2.1.3 Confirming the labels chosen before attaching them to their respective
volumes.
Figure 2.1.4 Using ASMTOOLG.EXE to confirm assigned labels (NT environment).
• 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 Oracle 10g DBCA
-----
-- Listing 2.2: Initialization parameter file (PFILE) for creating
-- the example ASM instance. This file can be translated
-- into an SPFILE via the CREATE SPFILE AS PFILE;
command
-----
# Background, core, and user trace file directories. These will need
# to exist before starting the instance and configured for the
server's
# operating system as appropriate
*.background_dump_dest = '/u01/app/oracle/admin/+ASM/bdump'
*.core_dump_dest = '/u01/app/oracle/admin/+ASM/cdump'
*.user_dump_dest = '/u01/app/oracle/admin/+ASM/udump'
# ASM candidate disk search string. It's not required, but it does
help
# Oracle find the candidate disks more easily
*.asm_diskstring = '\\.\ORCLDISK*' # For Windows environment
*.asm_diskstring = '/u03/asmdisks/*', '/u04/asmdisks/*',# For Red Hat
Linux environment
# ASM Mountable Disk Group(s). These can be activated after the ASM
# Instance has been created.
#asm_disk_groups='DGROUP1'
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:
-----
-- Listing 2.3: Issuing CREATE DISK GROUP statements to create the
-- initial ASM Disk Group for the example ASM instance
-----
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:
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
...
-----
-- Listing 2.4: Migrating an existing tablespace to ASM storage
-----
-----
-- Create a new tablespace managed by the regular database instance
-----
SQL> CREATE TABLESPACE tbs_regular
2 DATAFILE 'f:\oradata\orcl\orcl\tbs_regular01.dbf'
3 SIZE 32M;
Tablespace created.
-----
-- Migrate the new tablespace to ASM storage
-----
C:\>rman nocatalog target /
RMAN> exit
14 rows selected.
-----
-- Listing 2.5: Reconfiguring Enterprise Manager (EM) for use with
ASM:
-- 1.) Shut down Database Console service
-- 2.) Remove current EM configuration
-- 3.) Recreate new EM configuration
-- 4.) Restart Database Console service
-----
-----
-- Step 1. Stop the Database console
-----
-----
-- Step 2. Remove the EM configuration for the ORCL database
-----
C:\>set oracle_sid=orcl
C:\>emca -x orcl
-----
-- Step 3. Recreate the EM configuration for the ORCL database,
-- but this time include the ASM instance information
-- as well (-a). The -r directive tells EMCA not to
-- recreate the existing EM repository on the ORCL database.
-- Note that except where indicated, simply accept the
default
-- settings for best results
-----
C:\>emca -r -a
-----------------------------------------------------------------
-----------------------------------------------------------------
Do you wish to continue? [yes/no]: yes
Dec 14, 2005 7:58:33 AM oracle.sysman.emcp.EMConfig updateReposVars
INFO: Updating file
C:\oracle\product\10.1.0\db_1\sysman\emdrep\config\repository.variabl
es …
Dec 14, 2005 7:58:33 AM oracle.sysman.emcp.util.PortQuery
findUsedPorts
INFO: Searching services file for used port
Dec 14, 2005 7:58:34 AM oracle.sysman.emcp.EMConfig addPortEntries
INFO: Updating file
C:\oracle\product\10.1.0\db_1\install\portlist.ini …
Dec 14, 2005 7:58:34 AM oracle.sysman.emcp.EMConfig updateEmdProps
INFO: Updating file
C:\oracle\product\10.1.0\db_1\sysman\config\emd.properties…
Dec 14, 2005 7:58:34 AM oracle.sysman.emcp.EMConfig updateConfigFiles
INFO: targets.xml file is updated successfully
Dec 14, 2005 7:58:34 AM oracle.sysman.emcp.EMConfig updateEmomsProps
INFO: Updating file
C:\oracle\product\10.1.0\db_1\sysman\config\emoms.properties ...
Dec 14, 2005 7:58:34 AM oracle.sysman.emcp.EMConfig updateConfigFiles
INFO: emoms.properties file is updated successfully
Dec 14, 2005 7:58:36 AM oracle.sysman.emcp.EMConfig startOMS
INFO: Starting the DBConsole ...
Dec 14, 2005 8:00:16 AM oracle.sysman.emcp.EMConfig perform
INFO: DBConsole is started successfully
Dec 14, 2005 8:00:16 AM oracle.sysman.emcp.EMConfig perform
INFO: >>>>>>>>>>> The Enterprise Manager URL is http://zdc-
dbsrvr:5500/em <<<<<<<<<<<
Enterprise Manager configuration is completed successfully
FINISHED EMCA at Wed Dec 14 08:00:16 CST 2005
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.
Figure 2.3 Enterprise Manager (EM) reconfigured to permit ASM storage management.
I was also able to query the following dynamic views against my database
instance to view the related ASM storage components of that instance:
See Listing 2.6 for the SQL*Plus queries that I used to view information from
the ASM and database instances.
-----
-- Listing 2.6: Queries Against ASM Dynamic Views
-----
-----
-- V$ASM_ALIAS
-- Shows every alias for every disk group mounted by the ASM instance
-----
TTITLE 'ASM Disk Group Aliases (From V$ASM_ALIAS)'
COL name FORMAT A48 HEADING 'Disk Group
Alias'
COL group_number FORMAT 99999 HEADING 'ASM|File #'
COL file_number FORMAT 99999 HEADING 'File #'
COL file_incarnation FORMAT 99999 HEADING 'ASM|File|
Inc#'
COL alias_index FORMAT 99999 HEADING 'Alias|Index'
COL alias_incarnation FORMAT 99999 HEADING 'Alias|Incn#'
COL parent_index FORMAT 99999 HEADING 'Parent|
Index'
COL reference_index FORMAT 99999 HEADING 'Ref|Idx'
COL alias_directory FORMAT A4 HEADING 'Ali|Dir?'
COL system_created FORMAT A4 HEADING 'Sys|Crt?'
SELECT
name
,group_number
,file_number
,file_incarnation
,alias_index
,alias_incarnation
,parent_index
,reference_index
,alias_directory
,system_created
FROM v$asm_alias
;
-----
-- V$ASM_CLIENT
-- Shows which database instance(s) are using any ASM disk groups
-- that are being mounted by this ASM instance
-----
TTITLE 'ASM Client Database Instances (From V$ASM_CLIENT)'
COL group_number FORMAT 99999 HEADING 'ASM|File #'
COL instance_name FORMAT A32 HEADING 'Serviced Database
Client' WRAP
COL db_name FORMAT A08 HEADING 'Database|Name'
COL status FORMAT A12 HEADING 'Status'
SELECT
group_number
,instance_name
,db_name
,status
FROM v$asm_client
;
-----
-- V$ASM_DISK
-- Lists each disk discovered by the ASM instance, including disks
-- that are not part of any ASM disk group
-----
TTITLE 'ASM Disks - General Information (From V$ASM_DISK)'
COL group_number FORMAT 99999 HEADING 'ASM|Disk|Grp #'
COL disk_number FORMAT 99999 HEADING 'ASM|Disk|#'
COL name FORMAT A32 HEADING 'ASM Disk Name' WRAP
COL total_mb FORMAT 99999999 HEADING 'Total|Disk|
Space(MB)'
COL compound_index FORMAT 999 HEADING 'Cmp|Idx|#'
COL incarnation FORMAT 999 HEADING 'In#'
COL mount_status FORMAT A07 HEADING 'Mount|Status'
COL header_status FORMAT A12 HEADING 'Header|Status'
COL mode_status FORMAT A08 HEADING 'Mode|Status'
COL state FORMAT A07 HEADING 'Disk|State'
COL redundancy FORMAT A07 HEADING 'Redun-|dancy'
COL path FORMAT A32 HEADING 'OS Disk Path Name'
WRAP
SELECT
group_number
,disk_number
,name
,total_mb
,compound_index
,incarnation
,mount_status
,header_status
,mode_status
,state
,redundancy
,path
FROM v$asm_disk
;
TTITLE 'ASM Disks - I/O Status (From V$ASM_DISK)'
COL group_number FORMAT 99999 HEADING 'ASM|Disk|Grp #'
COL disk_number FORMAT 99999 HEADING 'ASM|Disk|#'
COL mount_status FORMAT A07 HEADING 'Mount|Status'
COL total_mb FORMAT 999999 HEADING 'Total|Disk|
Space(MB)'
COL free_mb FORMAT 999999 HEADING 'Free|Disk|Space(MB)'
COL reads FORMAT 999999 HEADING 'Disk|Reads'
COL mb_read FORMAT 999999 HEADING 'Reads|(MB)'
COL read_time FORMAT 999999 HEADING 'Read|Time'
COL read_errs FORMAT 999999 HEADING 'Read|Errors'
COL writes FORMAT 999999 HEADING 'Disk|Writes'
COL write_errs FORMAT 999999 HEADING 'Write|Errors'
COL write_time FORMAT 999999 HEADING 'Write|Time'
SELECT
group_number
,disk_number
,mount_status
,total_mb
,free_mb
,reads
,(bytes_read / (1024*1024)) mb_read
,read_errs
,read_time
,writes
,write_errs
,write_time
FROM v$asm_disk
;
-----
-- V$ASM_DISKGROUP
-- Describes information about ASM disk groups mounted by the ASM
instance
-----
TTITLE 'ASM Disk Groups (From V$ASM_DISKGROUP)'
COL group_number FORMAT 99999 HEADING 'ASM|Disk|Grp #'
COL name FORMAT A12 HEADING 'ASM Disk|Group Name'
WRAP
COL sector_size FORMAT 99999999 HEADING 'Sector|Size'
COL block_size FORMAT 999999 HEADING 'Block|Size'
COL au_size FORMAT 99999999 HEADING 'Alloc|Unit|Size'
COL state FORMAT A11 HEADING 'Disk|Group|State'
COL type FORMAT A06 HEADING 'Disk|Group|Type'
COL total_mb FORMAT 999999 HEADING 'Total|Space(MB)'
COL free_mb FORMAT 999999 HEADING 'Free|Space(MB)'
SELECT
group_number
,name
,sector_size
,block_size
,allocation_unit_size au_size
,state
,type
,total_mb
,free_mb
FROM v$asm_diskgroup
;
-----
-- V$ASM_FILE
-- Lists each ASM file in every ASM disk group mounted by the ASM
instance
-----
TTITLE 'ASM Files (From V$ASM_FILE)'
COL group_number FORMAT 99999 HEADING 'ASM|File #'
COL file_number FORMAT 99999 HEADING 'File #'
COL compound_index FORMAT 999 HEADING 'Cmp|Idx|#'
COL incarnation FORMAT 999 HEADING 'In#'
COL block_size FORMAT 999999 HEADING 'Block|Size'
COL blocks FORMAT 999999 HEADING 'Blocks'
COL bytes_mb FORMAT 999999 HEADING 'Size|(MB)'
COL space_alloc_mb FORMAT 999999 HEADING 'Space|Alloc|(MB)'
COL type FORMAT A32 HEADING 'ASM File Type' WRAP
COL redundancy FORMAT A06 HEADING 'Redun-|dancy'
COL striped FORMAT A07 HEADING 'Striped'
COL creation_date FORMAT A12 HEADING 'Created On'
COL modification_date FORMAT A12 HEADING 'Last|Modified'
SELECT
group_number
,file_number
,compound_index
,incarnation
,block_size
,blocks
,(bytes / (1024*1024)) bytes_mb
,(space / (1024*1024)) space_alloc_mb
,type
,redundancy
,striped
,creation_date
,modification_date
FROM v$asm_file
;
-----
-- V$ASM_OPERATION
-- Like its counterpart, V$SESSION_LONGOPS, it shows each long-
running
-- ASM operation in the ASM instance
-----
TTITLE 'Long-Running ASM Operations (From V$ASM_OPERATIONS)'
COL group_number FORMAT 99999 HEADING 'ASM|Disk|Grp #'
COL operation FORMAT A08 HEADING 'ASM|Oper-|ation'
COL state FORMAT A08 HEADING 'ASM|State'
COL power FORMAT 999999 HEADING 'ASM|Power|Rqstd'
COL actual FORMAT 999999 HEADING 'ASM|Power|Alloc'
COL est_work FORMAT 999999 HEADING 'AUs|To Be|Moved'
COL sofar FORMAT 999999 HEADING 'AUs|Moved|So Far'
COL est_rate FORMAT 999999 HEADING 'AUs|Moved|PerMI'
COL est_minutes FORMAT 999999 HEADING 'Est|Time|Until|Done|
(MM)'
SELECT
group_number
,operation
,state
,power
,actual
,est_work
,sofar
,est_rate
,est_minutes
FROM v$asm_operation
;
-----
-- V$ASM_TEMPLATE
-- Lists each template present in every ASM disk group mounted
-- by the ASM instance
-----
TTITLE 'ASM Templates (From V$ASM_TEMPLATE)'
COL group_number FORMAT 99999 HEADING 'ASM|Disk|Grp #'
COL entry_number FORMAT 99999 HEADING 'ASM|Entry|#'
COL redundancy FORMAT A06 HEADING 'Redun-|dancy'
COL stripe FORMAT A06 HEADING 'Stripe'
COL system FORMAT A03 HEADING 'Sys|?'
COL name FORMAT A30 HEADING 'ASM Template Name'
WRAP
SELECT
group_number
,entry_number
,redundancy
,stripe
,system
,name
FROM v$asm_template
;
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.
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.
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.
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.
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:
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 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:
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:
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.
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.
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.
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
<disk_group> RESIZE <disk|failure_group|ALL> <size>; command. ASM
offers me the choice to resize all disks in the specified disk group, all disks in the
specified failure group, or just the specified disk. Listing 3.5 shows examples of
these three options.
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.
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.
• 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 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.
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.
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: