 |
|
Oracle Tips by Burleson |
Oracle10g ASM - Automated
Storage Management
Automated Storage
Management (ASM) was designed to simplify database administration. ASM
eliminates the need for the DBA to directly manage the thousands of
Oracle database files that could be present in a modern Oracle
instance. ASM does this by enabling ASM disk groups, which are logical
units comprised of disks and the files that reside on them. Using ASM,
the management of thousands of Oracle files is reduced to managing a
small number of disk groups.
The SQL statements used for
creating database structures, such as tablespaces, redo logs, archive
log files, and control files, must specify file location in terms of
ASM disk groups, in order to use ASM. ASM will then create and manage
the associated underlying files for you.
ASM is the logical
extension of the power of Oracle-managed files (OMF). In previous
releases of OMF, files were created and managed automatically for you,
but with ASM you reap the additional benefits of features such as ASM
disk group mirroring and striping.
ASM was designed to
preserve all existing database functionality. Your existing databases
will operate as they always have. Existing databases using file
systems or with storage on raw devices will operate as they always
have. However, even in existing databases, new files can be created as
ASM files while old ones are administered in the old way. This means
that databases can have a mixture of ASM files, Oracle-managed files,
and manually managed files all at the same time.
To turn on ASM you must
create a separate ASM instance before you start your database
instances. An ASM instance does not require that a DB instance be
running; as might be the case when you are initially configuring the
components managed by the ASM instance. But to use Automated Storage
Management for managing your Oracle database files, you must have both
a database instance and an ASM instance running. Automated Storage
Management is integrated into the database server; you do not need to
install it as a separate product.
Oracle 10g Automated Storage Management Configuration
The Database Configuration Assistant (DBCA) is used in Oracle
Database 10g to configure the Automated Storage Management (ASM)
features for conventional and Real Application Clusters (RAC)
environments. ASM is used to automate and simplify the optimal layout
of datafiles, control files, and log files. ASM automatically
distributes database files across all available disks, and whenever
the storage configuration changes, the database storage is rebalanced.
ASM can also be used to provide redundancy, through the mirroring of
database files.
ASM essentially eliminates the management overhead involved with
the use of a conventional file system. There is no need to manually
place data on disks when using ASM. Also, by allowing the
administrator to manage just a few disk groups, the administrator is
relieved from managing hundreds or thousands of files. Using ASM, the
DBA will use disk groups for setting up a database. After setup, the
DBA need only be concerned with disk groups when monitoring and
changing disk allocations within the disk groups.
ASM uses the process of breaking each file into multiple extents
and spreading the extents evenly across all of the disks in a disk
group. Once ASM disk groups are established, the Oracle database
automatically allocates storage space from these disk groups for
creating and deleting files.
Unneeded data files are automatically deleted with ASM, rather than
requiring a manually issued command, as in previous versions.
Automated Storage Management enhances database integrity for databases
operating on disks that are not extremely reliable.
ASM doesn't have to be installed in order to install an Oracle
database. However, to use ASM files, there must be at least one ASM
instance configured and started prior to starting a database instance
that uses ASM files.
Oracle 10g Automated Storage Management ASM Disk Groups
A disk group is basically one or more ASM disks that are managed as
a single logical unit. Any data-structure stored in an ASM disk group
is totally contained within that disk group, or self-contained. A
database using ASM disks doesn't have to be shutdown in order for a
disk to be added or dropped. ASM rebalances the spread of data to
ensure an even I/O load to all disks in a disk group when the disk
group configuration changes.
We mentioned that any single ASM file is self-contained in a single
ASM disk group. However, an ASM disk group can contain files belonging
to several databases, and a single database can use storage from
multiple ASM disk groups. One or more disk groups can be specified as
the default disk group for files created in a database.
Disk groups are created at database creation or when a new
application is developed. An ASM disk group can also change when its
database server configuration is altered.
Most installations will probably have two or more disk groups. The
reasons for having multiple different disk groups include the
following:
- To group disks of different manufacturers, different sizes or
performance characteristics.
- To group disks with different external redundancy together; for
example, JBOD (just a bunch of disks) would generally not be in the
same disk group with disks from a RAID 1+0 or RAID5 configuration,
but this is possible using ASM.
- To separate work and recovery areas for a given database.
In any installation, non-ASM managed operating system storage
repositories are required, and are used for swap files, execution
libraries, and user file systems. The Oracle database and ASM
executable files and libraries must reside on the server’s operating
system file system and cannot reside in an ASM disk.
Automated Storage Management ASM Instances
The Oracle Database 10g introduces the ASM instance, a special
Oracle instance that manages the disks in disk groups. The ASM
instance must be configured and running for the database instance
to access Automated Storage Management files.
ASM instances are not used to mount databases, they are simply
used to coordinate data layout for database instances. However,
the database instances do direct I/O to disks in disk groups. I/O
doesn't go through the ASM instance.
Multiple, separate database instances can share ASM disk groups
for their files. A single node typically requires only a single
ASM instance. The single ASM instance manages all disk groups. In
a Real Application Cluster (RAC) environment, there is typically
one ASM instance on each node in the RAC cluster, managing all
disk groups for its node in a coordinated manner with the rest of
the cluster.
All ASM management commands are directed through the ASM
instance, no ASM commands are issued to any regular Oracle
database instance using the ASM files.
Oracle 10g Automated Storage Management ASM Instance
Background Processes
There are at least two new background processes added for an
ASM instance:
- RBAL - coordinates rebalance activity for disk groups
- ORB0, ORB1… - These perform the actual rebalance data extent
movements. There can be many of these at a time
Database Instance ASM Background Processes
Any database instance that is using an ASM disk group will
contain a background process called OSMB. The OSMB process is
responsible for communicating with the ASM instance. A second
additional background process, called RBAL (just like in the ASM
Instance) performs a global open on ASM disks. A global open means
that more than one database instance can be accessing the ASM
disks at a time.
 |
For more details and scripts, see my new book "
Oracle
Tuning: The Definitive Reference", over 900 pages
of BC's favorite tuning tips & scripts.
You can buy it direct from the publisher for 30%-off and get
instant access to the code depot. |
|
