Automatic Storage Management (ASM) is a new type of file system. ASM provided a foundation for highly efficient storage management with kernelized asynchronous I/O, direct I/O, redundancy, striping, and an easy way to manage storage. ASM is recommended file system for RAC and single instance ASM for storing database files. This provides direct I/O to the file and performance is comparable with that provided by raw devices. Oracle creates a separate instance for this purpose.

ASM includes volume management functionality similar to that of a generic logical volume manager. Automatic Storage Management (ASM) will take physical disk partitions and manages their contents in a way that efficiently supports the files needed to create an Oracle database.

Automatic Storage Management (ASM) simplifies administration of Oracle related files by allowing the administrator to reference diskgroups rather than hundreds of individual disks and files, which are managed by ASM. The ASM functionality is an extension of the Oracle Managed Files (OMF) functionality that also includes striping and mirroring to provide balanced and secure storage. The ASM functionality can be used in combination with existing raw and cooked file systems, along with OMF and manually managed files.

Before ASM, there were only two choices: file system storage and raw disk storage. File system storage is flexible, allowing the DBA to see the individual files and to move them, copy them, and back them up easily, but it also incurs overhead. Raw disk storage has no file directories on it, and Oracle manages its blocks directly, which makes it more efficient. Raw disk storage is such a manageability nightmare that few DBAs use it.

ASM is the middle ground. It's raw disk storage managed by Oracle, and it is very efficient. Oracle uses a scaled down Oracle instance to simulate a file structure on it where none exists, by recording all the metadata. The metadata enables the Recovery Manager (RMAN) to backup and restore Oracle files easily within it.

Setting up storage takes a significant amount of time during most database installations. Zeroing on a specific disk configuration from among the multiple possibilities requires careful planning and analysis, and most important, intimate knowledge of storage technology, volume managers, and file systems. The design tasks at this stage can be loosely described as follows:

Confirm that storage is recognized at the OS level and determine the level of redundancy protection that might already be provided (hardware RAID, called external redundancy in ASM).

Assemble and build logical volume groups and determine if striping or mirroring is also necessary.

Build a file system on the logical volumes created by the logical volume manager.

Set the ownership and privileges so that the Oracle process can open, read, and write to the devices.

All above tasks, striping, mirroring, logical file system building, are done to serve Oracle database. Oracle database offers some techniques of its own to simplify or enhance the process. Lets DBAs execute many of the above tasks completely within the Oracle framework. Using ASM you can transform a bunch of disks to a highly scalable and performance file system/volume manager using nothing more than what comes with Oracle database software at no extra cost and you don't need to be an expert in disk, volume managers, or file system management.

ASMB - This ASMB process is used to provide information to and from cluster synchronization services used by ASM to manage the disk resources. It's also used to update statistics and provide a heart beat mechanism.

The ASM functionality is controlled by an ASM instance. This is a special instance, not a database where users can create objects, just the memory structures and as such is very small and lightweight.

With ASM, you don't have to create anything on the OS side; the feature will group a set of physical disks to a logical entity known as a diskgroup. A diskgroup is analogous to a striped and optionally mirrored, file system, with important differences: it's not a general-purpose file system for storing user files and it's not buffered. Diskgroup offers the advantage of direct access to this space as a raw device, yet provides the convenience and flexibility of a file system. All the metadata about the disks are stored in the diskgroups themselves, making them as self-describing as possible.

This special ASM instance is similar to other file systems in that it must be running for ASM to work and can't be modified by the user. One ASM instance can serve number of Oracle databases. ASM instance and database instances have to be present on same server. Otherwise it will not work.

Logical volume managers typically use a function, such as hashing, to map the logical address of the blocks to the physical blocks. This computation uses CPU cycles. When a new disk is added, this typical striping function requires each bit of the entire data set to be relocated. In contrast, ASM uses this special instance to address the mapping of the file extents to the physical disk blocks. This design, in addition to being fast in locating the file extents, helps while adding or removing disks because the locations of file extents need not be coordinated.

You should start the instance up when the server is booted i.e. it should be started before the database instances, and it should be one of the last things stopped when the server is shutdown. From 11.2.0, we can use ASMCMD to start and stop the ASM instances.

The initialization parameters that are specific to an ASM instance are:

INSTANCE_TYPE - Set to ASM. The default is RDBMS.

ASM_DISKGROUPS - The list of diskgroups that should be mounted by an ASM instance during instance startup, or by the ALTER DISKGROUP ALL MOUNT statement. ASM configuration changes are automatically reflected in this parameter.

ASM_DISKSTRING - Specifies a value that can be used to limit the disks considered for discovery. The default value is NULL allowing all suitable disks to be considered. Altering the default value may improve the speed of diskgroup mount time and the speed of adding a disk to a diskgroup. Changing the parameter to a value which prevents the discovery of already mounted disks results in an error.

ASM_POWER_LIMIT -The maximum power for a rebalancing operation on an ASM instance. The valid values range from 1 (default) to 11. The higher the limit the more resources are allocated resulting in faster rebalancing operations. This value is also used as the default when the POWER clause is omitted from a rebalance operation. A value of 0 disables rebalancing.

ASM_PREFERRED_READ_FAILURE_GROUPS - This initialization parameter value (default is NULL) is a comma-delimited list of strings that specifies the failure groups that should be preferentially read by the given instance. This parameter is generally used only for clustered ASM instances and its value can be different on different nodes. This is from Oracle 11g.

DB_UNIQUE_NAME - Specifies a globally unique name for the database. This defaults to +ASM but must be altered if you intend to run multiple ASM instances.

To create an ASM instance first create pfile, init+ASM.ora, in the /tmp directory, containing the following parameter.

INSTANCE_TYPE = ASM

Next, connect to the ideal instance.

$ export ORACLE_SID=+ASM

SQL> sqlplus "/as sysdba"

Create a spfile using the contents of the init+ASM.ora file.

SQL> CREATE SPFILE FROM PFILE='/tmp/init+ASM.ora';

SQL> startup nomount

ASM instance started

Total System Global Area 130023424 bytes

Fixed Size 2028368 bytes

Variable Size 102829232 bytes

ASM Cache 25165824 bytes

The ASM instance is now ready to use for creating and mounting diskgroups.

Once an ASM instance is present, diskgroups can be used for the following parameters in database instances (INSTANCE_TYPE=RDBMS) to allow ASM file creation:

The main components of ASM are diskgroups, each of which comprise of several physical disks that are controlled as a single unit. The physical disks are known as ASM disks, while the files that reside on the disks are known as ASM files. The locations and names for the files are controlled by ASM, but user-friendly aliases and directory structures can be defined for ease of reference.

Diskgroup is a terminology used for logical structure which holds the database files. Each diskgroup consists of disks/raw devices where the files are actually stored. Any ASM file (and it's redundant copy) is completely contained within a single diskgroup. A diskgroup might contain files belonging to several databases and a single database can use files from multiple diskgroups.

In the initial release of Oracle 10g, ASM diskgroups were a black box. We had to manipulate ASM diskgroups with SQL statements while logged in to the special ASM instance that manages the diskgroups.

In Oracle 10g Release 2, Oracle introduced a new command line tool called ASMCMD that lets you look inside ASM volumes (which are called diskgroups). Now you can do many tasks from the command line.

While creating a diskgroup, we have to specify an ASM diskgroup type based on one of the following three redundancy levels:

Normal redundancy - for 2-way mirroring, requiring two failure groups, when ASM allocates an extent for a normal redundancy file, ASM allocates a primary copy and a secondary copy. ASM chooses the disk on which to store the secondary copy in a different failure group other than the primary copy.

High redundancy - for 3-way mirroring, requiring three failure groups, in this case the extent is mirrored across 3 disks.

External redundancy - to not use ASM mirroring. This is used if you are using hardware mirroring or third party redundancy mechanism like RAID, Storage arrays.

ASM is supposed to stripe the data and also mirror the data (if using Normal, High redundancy). So this can be used as an alternative for RAID (Redundant Array of Inexpensive Disks) 0+1 solutions.

No, we cannot modify the redundancy for diskgroup once it has been created. To alter it we will be required to create a new diskgroup and move the files to it. This can also be done by restoring full backup on the new diskgroup.

Failure groups are defined within a diskgroup to support the required level of redundancy, using normal/high redundancy. They contain the mirrored ASM extents and must be containing different disks and preferably on separate disk controller.

In addition failure groups and preferred names for disks can be defined in CREATE DISKGROUP statement. If the NAME clause is omitted the disks are given a system generated name like "disk_group_1_0001". The FORCE option can be used to move a disk from another diskgroup into this one.

Creating diskgroups

SQL> CREATE DISKGROUP dg_asm_data NORMAL REDUNDANCY

FAILGROUP failure_group_1 DISK

'/devices/diska1' NAME diska1, '/devices/diska2' NAME diska2,

FAILGROUP failure_group_2 DISK

'/devices/diskb1' NAME diskb1, '/devices/diskb2' NAME diskb2;

For two-way mirroring we would expect a diskgroup to contain two failure groups, so individual files are written to two locations.

SQL> CREATE DISKGROUP dg_asm_fra HIGH REDUNDANCY

FAILGROUP failure_group_1 DISK

'/devices/diska1' NAME diska1, '/devices/diska2' NAME diska2,

FAILGROUP failure_group_2 DISK

'/devices/diskb1' NAME diskb1, '/devices/diskb2' NAME diskb2,

FAILGROUP failure_group_3 DISK

'/devices/diskc1' NAME diskc1, '/devices/diskc2' NAME diskc2;

For three-way mirroring we would expect a diskgroup to contain three failure groups, so individual files are written to three locations.

SQL> CREATE DISKGROUP dg_grp1 EXTERNAL REDUNDANCY

DISK '/dev/d1','/dev/d2','/dev/d3','/dev/d4' ... ...;

In the above command, database will create a diskgroup named dg_grp1 with the physical disks named /dev/d1, /dev/d2, and so on. Instead of giving disks separately, we can also specify disk names in wildcards in the DISK clause as DISK '/dev/d*'.

We have also specified a clause EXTERNAL REDUNDANCY, which indicates that the failure of a disk will bring down the diskgroup. This is usually the case when the redundancy is provided by the hardware, such as mirroring. If there is no hardware based redundancy, the ASM can be set up to create a special set of disks called failgroup in the diskgroup to provide that redundancy.

SQL> CREATE DISKGROUP dskgrp1 NORMAL REDUNDANCY

FAILGROUP failgrp1 DISK '/dev/d1','/dev/d2',

FAILGROUP failgrp2 DISK '/dev/d3','/dev/d4';

Although it may appear as such, d3 and d4 are not mirrors of d1 and d2. Rather, ASM uses all the disks to create a fault-tolerant system. For example, a file on the diskgroup might be created in d1 with a copy maintained on d4. A second file may be created on d3 with copy on d2, and so on. That is, primary copy will be on one failure group and secondary copy will be another (third copy will be another, for high redundancy).

Failure of a specific disk allows a copy on another disk so that the operation can continue. For example, you could lose the controller for both disks d1 and d2 and ASM would mirror copies of the extents across the failure group to maintain data integrity.

Disks can be added or removed from diskgroups using the ALTER DISKGROUP statement. Remember that the wildcard "*" can be used to reference disks so long as the resulting string does not match a disk already used by an existing diskgroup.

Adding disks

We may have to add additional disks into the diskgroup to accommodate growing demand.

Disks can be resized using the RESIZE clause of the ALTER DISKGROUP statement. The statement can be used to resize individual disks, all disks in a failure group or all disks in the diskgroup. If the SIZE clause is omitted the disks are resized to the size of the disk returned by the OS.

The UNDROP DISKS clause of the ALTER DISKGROUP statement allows pending disk drops to be undone. It will not revert drops that have completed, or disk drops associated with the dropping of a diskgroup.

Diskgroups can be rebalanced manually using the REBALANCE clause of the ALTER DISKGROUP statement. If the POWER clause is omitted the ASM_POWER_LIMIT parameter value is used. Rebalancing is only needed when the speed of the automatic rebalancing is not appropriate.

SQL> ALTER DISKGROUP disk_group_1 REBALANCE POWER 6;ASMCMD equivalent for this command is rebal(11gR2 command).IO statistics of a diskgroupSQL> SELECT * FROM V$ASM_DISK_IOSTAT;

Until 11.1.0, all the above commands can not be performed with ASMCMD. From 11.2.0, we can.

Directories

As in other file systems, an ASM directory is a container for files, and an ASM directory can be part of a tree structure of other directories. The fully qualified filename represents a hierarchy of directories in which the plus sign (+) represent the root directory. In each diskgroup, ASM automatically creates a directory hierarchy that corresponds to the structure of the fully qualified filenames in the diskgroup. The directories in this hierarchy are known as system-generated directories.

An absolute path refers to the full path of a file or directory. An absolute path begins with a plus sign (+) followed by a diskgroup name, followed by subsequent directories in the directory tree. The absolute path includes directories until the file or directory is reached. A fully qualified filename is an example of an absolute path to a file. A relative path includes only the part of the filename or directory name that is not part of the current directory. That is, the path to the file or directory is relative to the current directory.

A directory hierarchy can be defined using the ALTER DISKGROUP statement to support ASM file aliasing.

There are several ways to reference ASM files. Some forms are used during creation and some for referencing ASM files. Every file created in ASM gets a system-generated filename, known as fully qualified filename, this is same as complete path name in a local file system.

ASM does not place system-generated files into user-created directories; it places them only in system-generated directories. We can add aliases or other directories to a user-created directory.

Dropping FilesFiles are not deleted automatically if they are created using aliases, as they are not Oracle Managed Files (OMF), or if a recovery is done to a point-in-time before the file was created. For these circumstances it is necessary to manually delete the files, as shown below.

Templates are named groups of attributes that can be applied to the files within a diskgroup. The level of redundancy and the granularity of the striping can be controlled using templates. Default templates are provided for each file type stored by ASM, but additional templates can be defined as needed.

Available attributes are:

UNPROTECTED - No mirroring or striping regardless of the redundancy setting.

MIRROR - Two-way mirroring for normal redundancy and three-way mirroring for high redundancy.

COARSE - Specifies lower granularity for striping.

FINE - Specifies higher granularity for striping.

MIRROR, COARSE, FINE attributes are cannot be set for external redundancy.

Modifying permissions for a fileSQL> ALTER DISKGROUP data_dg SET PERMISSION OWNER=read write, GROUP=read only, OTHER=none FOR FILE '+data_dg/controlfile.f';ASMCMD equivalent for this command is chmod(11gR2 command).Modifying ownership of a fileSQL> ALTER DISKGROUP data_dg SET OWNERSHIP OWNER='oracle1', GROUP='grp1' FOR FILE '+data_dg/controlfile.f';ASMCMD equivalent for this command is chown(11gR2 command).Volume ManagementFrom 11g release 2, we can create Oracle ASM Dynamic Volume Manager (Oracle ADVM) volumes in a diskgroups. The volume device associated with the dynamic volume can then be used to host an (Oracle ACFS) file system.

Now create a tablespace in the main database using a datafile in the ASM-enabled storage.

SQL> CREATE TABLESPACE user_data DATAFILE '+dskgrp1/user_data_01'

SIZE 1024M;

ASM filenames can be used in place of conventional filenames for most Oracle file types, including controlfiles, datafiles, logfiles etc. For example, the following command creates a new tablespace with a datafile in the disk_group_1 diskgroup.

Note how the diskgroup is used as a virtual file system. This approach is useful not only in datafiles, but in other types of Oracle files as well. For instance, we can create online redo log files as

...

LOGFILE GROUP 1 (

'+dskgrp1/redo/group_1.258.659723485',

'+dskgrp2/redo/group_1.258.659723485'

) SIZE 50M,

...

Archived log destinations can also be set to a diskgroup. Everything related to Oracle database can be created in an ASM diskgroup. Backup is another great use of ASM. You can set up a bunch of inexpensive disks to create the recovery area of a database, which can be used by RMAN to create backup datafiles and archived log files.

ASM supports files created by and read by the Oracle database only; it is not a replacement for a general-purpose file system.

Until Oracle 11g release1, we cannot store binaries or flat files. We cannot use ASM for storing the voting disk and OCR. It is due to the fact that Clusterware starts before ASM instance and it should be able to access these files which are not possible if you are storing it on ASM. You will have to use raw devices or OCFS or any other shared storage. But from 11g release 2, we can store ALL files on ASM.

Can we see the files stored in the ASM instance using standard Unix commands?

No, you cannot see the files using standard Unix commands like ls. You need to use utility called asmcmd to do this. Oracle 10g release2 introduces asmcmd which makes administration very easy.

$ asmcmd

ASMCMD>

ASMLIB is the support library for the ASM. ASMLIB allows an Oracle database using ASM more efficient and capable access to diskgroups. The purpose of ASMLIB, is to provide an alternative interface to identify and access block devices. ASMLIB API enables storage and OS vendors to supply extended storage-related features.

The following method shows how a database can be migrated to ASM from a disk based backup:

1) Shutdown the database.

SQL> SHUTDOWN IMMEDIATE

2) Modify the parameter file of the database as follows:

Set DB_CREATE_FILE_DEST and DB_CREATE_ONLINE_LOG_DEST_n parameters to the relevant ASM diskgroups.

3) Remove CONTROL_FILES parameter from the spfile so the control files will be moved to the DB_CREATE_* destination and the spfile gets updated automatically. If you are using a pfile the CONTROL_FILES parameter must be set to the appropriate ASM files or aliases.

4) Start the database in nomount mode.

RMAN> STARTUP NOMOUNT

5) Restore the controlfile into the new location from the old location.

We can maintain version compatibilites at diskgroup level.SQL> alter diskgroup dg-name set attribute 'compatible.rdbms'='11.1';SQL> alter diskgroup dg-name set attribute 'compatible.asm'='11.1';

ASM drops disks and if they remain offline for more than 3.6 hours. The diskgroups default time limit is altered by changing the DISK_REPAIR_TIME parameter with a unit of minutes(M/m) or hours(H/h).SQL> alter diskgroup dg-name set attribute 'disk_repair_time'='4.5h';

ACFS Snapshots are read-only on-line, space efficient, point in time copy of an ACFS file system. ACFS snapshots can be used to recover from inadvertent modification or deletion of files from a file system.

We can execute OS commands at asmcmd by using !, in the same we do at SQL prompt.

ASM New features in Oracle Clusterware 12c1. Oracle Flex ASM - This feature of Oracle Clusterware 12c claims to reduce per-node overhead of using ASM instance. Now the instances can use remote node ASM for any planned/unplanned downtime. ASM metadata requests can be converted by non-local instance of ASM.2. ASM Disk Scrubbing - From RAC 12c, ASM comes with disk scrubbing feature so that logical corruptions can be discovered. Also Oracle 12c ASM can automatically correct this in normal or high redundancy diskgroups.3. Oracle ASM Disk Resync & Rebalance enhancements.ASM Views

The ASM configuration can be viewed using the V$ASM_% views, which contain information depending on whether they are queried from the ASM instance, or a dependant database instance.

View

In ASM instance

In DB instance

V$ASM_ALIAS

Displays a row for each alias present in every diskgroup mounted by the ASM instance.

Returns no rows.

V$ASM_ATTRIBUTE (11gR2)

Displays attributes of diskgroups.

Displays attributes of diskgroups.

V$ASM_CLIENT

Displays a row for each database instance using a diskgroup managed by the ASM instance.

Displays a row for the ASM instance if the database has open ASM files.

V$ASM_DISK or V$ASM_DISK_STAT

Displays a row for each disk discovered by the ASM instance, including disks which are not part of any diskgroup.

Displays a row for each disk in diskgroups in use by the database instance.