Oracle ASM


An Oracle database will typically consist of hundreds of files, and managing these files can be a problem, especially for multiple databases or very large databases. Sometimes files need to be placed to ensure adequate performance or ensure a service will survive a disk failure, and this requires detailed knowledge of the underlying disk system to ensure the files are placed correctly.

ASM (Automatic Storage Management) is designed to simplify this management by combining disks into groups, so the administrator manages a small number of disk groups, rather than managing individual disks or files. ASM also looks after I/O balancing by evenly distributed files to eliminate hot spots and so to optimise the database performance. Oracle claims that ASM performance is comparable to the performance of raw devices.
Templates are used to allocate new disks, different templates select different striping and mirroring options, and ASM does the rest.

Oracle uses ASM metadata to control the disk groups and stores that metadata resides within the disk group. This ASM metadata includes the following:

Oracle ASM is essentially a volume manager and file system designed for Oracle Database files. It supports both single-instance Oracle Database and Oracle RAC clusters. Oracle stores the files it needs to operate in ASM disk groups, including those listed on the Oracle files page. Each Oracle ASM file is contained within a single Oracle ASM disk group.

ASM runs as a separate instance and it must be started before the database instance, otherwise the database will not be able to find its files. RMAN is the only way to backup ASM disks.

ASM uses a kernel module called Oracle ASM Filter Driver or Oracle ASMFD, which intercepts all I/O that is directed to Oracle ASM disks. Oracle ASM uses the filter driver to validate write I/O requests to Oracle ASM disks. If any of these I/Os are invalid, for example if they come from outside of Oracle, then ASMFD will reject them. This prevents external writes from corrupting your databases. ASMFD also simplifies the configuration and management of disk devices by eliminating the need to rebind disk devices used with Oracle ASM each time the system is restarted.

Oracle 11g introduced the ASM Cluster File System (ACFS), which is touted as a 'multi-platform, scalable file system, and storage management technology that extends Oracle ASM functionality to support customer files maintained outside of Oracle Database'. It supports all those non-database files that an Oracle database needs to operate, such as logs, trace files, executables and configuration files. It also supports general-purpose application files. This non-database data can be accessed by using native operating system file system APIs and command-line interface tools.

The advantage of doing this is that Oracle ACFS uses 64-bit file and file system data structure sizes which means that it could support exabyte size files and file systems on 64 bit platforms. Other advantages are built in performance tuning, metadata checksums for data intergrity and journaling for fast recovery.

Disk Groups

Disk groups are the ASM unit of management and basically consist of groups of disks that are lumped together and managed as a single entity. Data is striped within a disk group and should be mirrored between disk groups.

Failure Groups

Failure groups are groups of disks that can potentially all fail at the same time, for example, because they share the same SCSI controller. If your ASM redundancy policy is for 2-way mirroring, then the data on each side of the mirror must be on different failure groups. Then if any component fails in one failure group, the data on the other failure group is not affected. Triple redundancy requires three failure groups, and ASM can then tolerate concurrent failures in any two groups.

Flex Disk Groups were introduced in Oracle 12. In previous versions, redundancy options like striping and mirroring applied to the whole disk group. For an example, the disk group could be 2-way mirrored. Once the was defined, it could not be changed, so if you needed 3-way mirroring for a special database you had to define a new disk group.
With a flex disk group, you can apply different redundancy levels by file type or database, all in the same group. Also, if you change your mind, you can alter the redundancy level after creation.

ASM with Flex Disk Groups has the ability to create instantaneous clones of databases without needing any storage subsystem snapshot technology. If a storage administrator had to do this using snapshots, they would need to work out exactly what files were required, where they were located, then snap all the bits and pieces. ASM can do all the work itself. It does this by using the ASM redundancy components that ASM used to protect a database from data loss due to hardware errors. As Flex Disk Groups can have up to five redundant copies, ASM is able to split one of these redundant copies off, and so create an independent copy of the database. The process sounds very similar to the EMC approach for creating a BCV, where the BCV needs to be created first, before it can be split off as an independent copy.

From Oracle Database 12c, ASM added a new feature called Extended Disk Groups. Previously, an extended Oracle RAC system could have up to two Failure Groups, though they could be in different datacenters. Extended Disk Groups are an extension of Flex Disk Groups, and now you can have multiple Failure Groups, such as mirroring within your primary datacenter, combined with mirroring to a remote datacenters. You could also mirror between three datacenters.

Oracle Database 19c added parity protection as extra option for write-once files such as archive logs and backup sets. Previously, these files could be either unprotected or mirrored. Parity protection gives the option of protecting these files without incurring the full expense of mirroring. Parity protection is not available for databases or other read-write files.
How much saving you get depends on how many failure groups you have. You must have at least three failure groups, and three or four failure groups will save 50% capacity over mirroring, while five or more failure groups have four data extents and so save 75% capacity.
If you modify a file group from mirroring to parity, existing files are not reallocated, so there will be no space saving on them, but new files will be added in the new configuration.


Templates are used to simplify creating files and mapping them to the correct disk group. Templates consist of attributes that a file can have, for example, UNPROTECTED or MIRROR, which are used to describe no redundancy or a 2 way mirror. COARSE and FINE are a little less obvious, they describe the granularity used for striping. Fine-grained striping is appropriate for log files as they require low latency. This allows larger I/Os to be split and processed in parallel by multiple disks and so speeding up response times.

ASM provides a set of default templates, for example ONLINELOG provides file redundancy and striping for redo log files. It is also possible to write your own templates for your own site needs

Redundancy and Striping

ASM stripes its files across all the disks that belong to a disk group using a version of RAID 3, RAID3 is used because it is much easier to add or remove disk from a RAID3 system than RAID5 or RAID6. Ideally, all the disks in a disk group should be the same size.

However, don't confuse this striping with redundancy. The striping is for performance reasons, redundancy involves mirroring data between disk groups. Disk groups can have no external redundancy, two-way mirroring or three-way mirroring. These last two are often called normal and high mirrors. If possible, the disk groups should run under different controllers to provide failover for controller errors.

ASM automatically handles changes to the disk count within a group, whether this is down to a disk failure, or disks being added or removed, and does this while the database is operating. The rebalancing process happens in the background with minimal impact on database performance.
If you add a disk, ASM will automatically redistribute the data so that it is evenly spread across all disks in the disk group, including the new disk. When you request to remove a disk, ASM will first relocate all the file extents from the disk being removed to the other disks in the disk group. The data is spread evenly to conserve the I/O balance.


ASM gives DBAs the ability to refer to ASM files with user-friendly names, rather than the fully qualified ASM filenames. This is bad news for a storage person as if they get problems you then have to translate between what they call the file, and the real file name. If you get problems locating a file, ask your DBA to check if he is using an alias or not.

Oracle Storage

Lascon latest major updates