ASM - Oracle 10g New Feature

ASM - Automatic Storage Management

ASM is One of the most valuble feature in Oracle 10g which helps DBA's in managing thousands of datafiles easily. Main features of ASM is to create Disk Groups, composed of disk devices and the files that resides on the disk devices managed as logical unit.

ASM is a combination of OMF and combines with mirroring and stripping features to provide a robust file system and logical volume manager which can also supported with RAC. There is no need of third part Logical Volume Manager now. ASM stripes files and not the logical volumes, which enhances performance by automatically spreading database objects over multiple devices to increase availability by allowing new disk added to the database without shutting down the database. It automatically rebalances the distribution of files with minimal intervention.

Lets see how it works:-

ASM Architecture

As we know the database objects are stored in extents, ASM divides these extents across the disks in the disk groups to enhance the performance and reliability. Also ASM mirrors the datbase objects instead of mirroring the entire disk volumes to provide the flexibility to mirror or stripe the database objects differently depending on their type. Optionally if the underlying hardware is already RAID enabled.

Automatic Rebalancing is yet another feature of ASM. When it is required to increase the disk space it can be added to the disk group and ASM moves a proportional number of files from one or more existing disk to the new disks to maintain the overall I/O balances accross all disks. This all happens when the disk files are online and available to the users.

ASM requires a special type of instance to provide the interface between a traditional Instance and the file system. It can be choosen while istalling the database while choosing the storage type. Choosing ASM does not mean that we can not use the traditional way of storage e.g. raw devices or any file system files. However it gives the ease to convert the existing filesystem to ASM disk groups.

There are three new background processes which supports the ASM Instances: RBAL and ORBn.

RBAL:- RBAL coordinates the disk activity for disk groups. It also serves as open and close of the disks in the disk group on behalf of the database.

OSMB:- It performs the communication between the database and the ASM Instance

ORBn:- Performs actual extent movement between disks in the disk groups. Where n can be from 0 to 9.

Creation of the ASM Instance can be checked with the database installation guidlines provided with the installation guide. We are not discussing the same here. Lets see how to access, start, stop and Disk group related features.

Accessing an ASM Instance:-

Since ASM instance does not have a data dictionary therefore the access to the ASM instance is restricted to users who can authenticate with the operating system conecting as SYSDBA or SYSOPER users that is in dba group.

SYSDBA has all the privileges as usual however the SYSOPER have much more limited set of commands available in an ASM instance. Following is the list of operations available to SYSOPER:-
i) Starting and Shutting down an Instance.
ii) Mounting or dismounting a disk group
iii) Rebalancing a disk group
iv) Altering a disk group’s disk status to ONLINE or OFFLINE
v) Performing an integrity check of a disk group
vi) Accessing V$ASM_* dynamic performance Views.

ASM Initialization Parameters:-
A number of initialization parameters specific to ASM instance. A spfile is recommended over initialization parameter file for an ASM Instance. e.g. ASM_DISKGROUP will automatically be maintained when a disk group is added or dropped, it will free a dba to manually change the values.
Following are the Initialization parameters:-
INSTANCE_TYPE :- INSTANCE_TYPE has a value of ASM for ASM Instance. The default for the traditional instances it is RDBMS.
DB_UNIQUE_NAME:- The default value for the ASM instance is +ASM and it is unique for the group of ASM Instances within a cluster or on a single node. The default value has to be changed only when more than one ASM Instances are running on single node.
ASM_POWER_LIMIT:- ASM_POWER_LIMIT parameter controls how fast rebalance operations occur. The values ranges from 1 to 11, with 11 being the highest possible value however the 1 is the default value. Since this is a dynamic parameter one can set 1 in the day time when the usage are high for the database and set it higher overnight whenever a disk rebalancing operation must occur.
ASM_DISKSTRING:- ASM_DISKSTRING parameter specifies one or more strings, which are OS dependent, to limit the disk devices that can be used to create disk groups. If the value is NULL, all the disk visible to ASM instance are potential candidate for creating disk groups.

SQL> Show parameter asm_diskstring

ASM_DISKGROUPS:- The ASM_DISKGROUP specifies a list containing the names fo the disk groups to be automatically mounted by the ASM instance at startup or by the ALTER DSIKGROUP ALL MOUNT command.
LARGE_POOL_SIZE:- All internal packages are executed from this pool, so the parameter should be set to at least 8MB. This parameter is used in both kind of instances, however this is used differently for ASM instances.
ASM Instance STARTUP and SHUTDOWN:-
An ASM instance while startup has been only MOUNTED and not OPEN. Since there is no control file, database or data dictionary to mount ASM Diskgroups are mounted instead of database. STARTUP NOMOUNT starts up the instance but does not mount the ASM disks. Also we can use the STARTUP RESTRICT to temporarily prevent database instances from connecting to the ASM instance to mount diskgroups.
Performing a SHUTDOWN command on an ASM Instance performs the same SHUTDOWN, before it finishes the SHUTDOWN operation it waits for all dependent databases to shutdown. The only exception is SHUTDOWN ABORT.
For multiple ASM instances sharing disk groups, such as in RAC environment, the failure of an ASM instance does not cause the database instances to fail. Instead another ASM Instance performs a recovery operation for the failed instance.
ASM Dynamic Performance Views:-

ASM Filenames
All ASM files are OMF, so the details of the actual filename with in the disk group is not needed for most administrative functions, When an object in an ASM disk group is dropped, the file is automatically deleted. V$DATAFILE shows the actual filenames within each disk groups.

SQL > Select file#, name, blocks from v$datafile;

File# NAME BLOCKS
--------- ----------------------------- --------------------
1 +DATA1/rac0/datafile/system.256.1 57600
2 +DATA1/rac0/datafile/sysaux.257.1 44800

ASM filenames can be one of six different formats such as
Fully qualified names (+group/dbname/file type/tag.file.incarnation)
Numeric names (+DATA2.256.1)
Alias with Template names- we can also use an alias with a template only when creating a new ASM file.

SQL> create tablespace users4 datafile ‘+data2/uspare(datafile);

Incomplete names – we can use incomplete file name format either for single file or multiple file creation operation.

SQL> create tablespace users5 datafile ‘+data1’;

ASM File types and Templates:-ASM supports all types of files used by the database except for files such as operating system executables.
CONTROLFILE, DATAFILE, ONLINELOG, ARCHIVELOG, TEMPFILE, BACKUPSET, PARAMETERFILE, DATAGUARDCONFIG, FLASHBACK, CHANGETRACKING, AUTOBACKUP, DUMPSET AND XTRANSPORT(Cross platform datafiles)

Administering ASM Disk Groups
As mentioned earlier disk groups benefits in number of ways: I/O performance improved, availability is increased and the ease with which one can add a disk to a disk group or add an entirely new disk group enables you to manage amny more databases in the same amount of time.

Disk Group Architecture:-

Disk Group is collection of physical disks managed as a unit. Every ASM disk, as part of a disk group has an ASM disk name that is either assigned by the DBA or automatically assigned when it is assigned to the disk group.

Files in the disk group are striped on the disks using either coarse striping or fine striping. Coarse striping spreads files in units of 1MB each across all disks. Coarse striping is appropriate for a system with a high degree of concurrent small I/O requests, such as an OLTP env. Alternatively fine striping spreads files in units of 128KB and is appropriate for traditional data warehouse environments or OLTP systems with low concurrency and maximizes response time for individual I/O requests.

Failure Groups and Disk Group Mirroring:-

Before defining the type of mirroring with in a disk group, one must group disks into failure groups. A failure group is one or more disks within a disk group that share a common resource, such as a disk controller, whose failure would cause the entire set of disks to be unavailable to the group. In most cases, an ASM instance does not know the hardware and software dependencies for a given disk. Therefore, unless you specifically assign a disk to a failure group, each disk in a disk group is assigned to its own failure group.
Type of mirroring depends on the number of failure groups available with in the disk group. There are three types of mirroring is available:

External Redundancy: External redundancy requires only one failure group and assumes that the disk is not critical to the ongoing operation of the database or that the disk is managed externally with high availability hardware such as a RAID controller.
Normal Redundancy: Normal redundancy provides two way mirroring and requires at least two failure groups within a disk group. The failure of one of the disks in a failure group does not cause any downtime for the disk group or any data loss other than a slight performance hit for queries against objects in the disk group.
High Redundancy: High redundancy provides three way mirroring and requires at least three failure groups within a disk group. The failure of disks in two out of the three failure groups is for the most part transparent to the database users as in normal redundancy mirroring.

Mirroring is managed at a very low level: extents, not disks are mirrored, each disk will have a mixture of both primary and mirrored (secondary and tertiary) extents on each disk. While there is a slight overhead incurred for managing mirroring at the extent level, it provides the advantage of spreading the load from the failed disk to all other disks instead of a single disk.

More to come in next post......