Automatic Storage Management Concepts: Disk Groups, Failure Groups, Striping, and Mirroring

Learning outcomes

ServiceHub is being designed for a larger deployment. One diagram says “put DATA on ASM” as though ASM were a directory. Another says “ASM mirrors every file twice.” Both are incomplete. Oracle Automatic Storage Management (ASM) is a storage-management layer provided through Oracle Grid Infrastructure: it manages disks in disk groups, allocates Oracle files in allocation units, stripes work across disks, places mirrored extents across failure groups according to redundancy policy, and rebalances when membership changes.

1. ASM is below the database-file layer

A database still has datafiles, control files, online redo logs, archived redo, tempfiles, and recovery files when ASM is used. Their names can be Oracle Managed Files such as +DATA/... rather than host filesystem paths. The database instance is an ASM client; an ASM instance manages disk groups and file placement. ASM does not contain relational tables or execute application SQL.

A disk group is ASM’s principal storage pool. It contains ASM disks and metadata. An ASM file is entirely contained in one disk group, while a database can place different files in different disk groups—for example DATA and recovery/FRA groups.

2. Allocation units and striping spread file extents across disks

Every ASM disk is divided into allocation units (AUs). An ASM file extent consists of one or more AUs. ASM distributes file extents across disks to balance space and I/O. AU size is a disk-group attribute, with supported sizes dependent on compatibility; current documentation describes values from 1 MB through 64 MB, with defaults varying by disk-group type and engineered-system context.

Striping and mirroring are separate ideas. Striping distributes extents across disks. Mirroring stores additional copies according to redundancy policy. More disks do not automatically mean more failure tolerance unless mirrored copies are placed across independent failure domains.

3. Failure groups encode correlated failure boundaries

A failure group groups disks expected to fail together—for example disks behind the same controller or enclosure. When ASM mirrors a file, it places primary and mirror extents in different failure groups so losing one failure group should not remove every copy. If you omit custom failure groups, ASM commonly treats each disk as its own failure group, except in certain engineered-system contexts.

The design question is not “how many disks?” but “which components can fail together?” Two disks on one shared controller may not represent two independent failure domains. The storage team must map physical topology into ASM failure groups deliberately.

4. Redundancy levels describe where protection comes from

Do not turn this into “NORMAL survives one disk, HIGH survives two” without topology qualifications. The unit that matters is failure groups and the redundancy of each file. Capacity planning should use USABLE_FILE_MB and REQUIRED_MIRROR_FREE_MB, not only raw free megabytes.

5. Rebalancing changes placement after storage membership changes

When disks are added, removed, or taken offline, ASM can rebalance extents across the disk group. Rebalancing restores balanced placement and, where applicable, redundancy. It consumes I/O and has an operational power/priority dimension, so storage changes should be planned with workload and recovery objectives. “Add a disk” is not the end of the change; verify the rebalance state and usable capacity.

ASM is not a backup. Mirroring protects against some storage failures, but it does not protect against logical corruption, accidental deletion, application errors, or every site disaster. RMAN and DR mechanisms remain required according to RPO/RTO.

6. Optional real-ASM evidence path

If you have a properly licensed/supported Grid Infrastructure lab with ASM, run these from an appropriate ASM/database administrative context. Do not run them against arbitrary production storage for this course.

SELECT name, type, state,       ROUND(total_mb/1024,1) AS total_gb,       ROUND(free_mb/1024,1) AS raw_free_gb,       ROUND(required_mirror_free_mb/1024,1) AS mirror_reserve_gb,       ROUND(usable_file_mb/1024,1) AS usable_file_gb,       allocation_unit_size,       offline_disksFROM   v$asm_diskgroup_statORDER  BY name;

Oracle documents V$ASM_DISKGROUP as performing disk discovery each time it is queried and recommends the less expensive V$ASM_DISKGROUP_STAT for monitoring scripts. This is a good example of “a view exists” not meaning “poll it constantly.”

SELECT group_number, disk_number, name,       failgroup, mount_status, mode_status, state,       path, total_mb, free_mbFROM   v$asm_disk_statORDER  BY group_number, failgroup, disk_number;

7. Mandatory Free lab: recognize that this is not ASM

In the standard Oracle AI Database Free container/local installation, inspect the actual file names. If they are normal filesystem paths, the correct conclusion is “this lab is using filesystem/OMF storage,” not “ASM is broken.” A PDB query of many ASM views can also return no rows because ASM is not present or because of container scope.

SHOW CON_NAMESELECT name AS datafile_nameFROM   v$datafileORDER  BY file#;SELECT member AS redo_memberFROM   v$logfileORDER  BY group#, member;

Names beginning with + are characteristic ASM aliases/fully qualified ASM file names. Filesystem paths such as /opt/oracle/oradata/... are not ASM. Record what you observe rather than forcing the lab to match an enterprise architecture diagram.

8. Deliberately wrong design: mirror copies in the same failure domain

Suppose ServiceHub has four disks, all behind one enclosure/controller, and the design labels each disk as an independent failure group simply because there are four device names. ASM can place mirrored extents on different disks yet still lose both copies when the shared controller/enclosure fails. The metadata representation failed to model the physical failure boundary.

The repair is architectural: identify correlated components, define failure groups that reflect them, choose redundancy only after understanding lower-layer RAID/mirroring, and verify capacity after mirror reserve. A SQL command cannot compensate for a false topology model.

9. Hands-on design exercise: build an ASM decision record

Create a design record for a hypothetical supported ServiceHub deployment with two storage tiers: database files and recovery files. Do not create disks. Document:

• whether storage hardware already mirrors data;
• candidate DATA and RECO disk groups and why separation helps recovery/failure isolation;
• disk/failure-group mapping and correlated failure boundaries;
• selected redundancy policy and effective usable-capacity reasoning;
• expected AU setting only if justified by platform/workload documentation—do not tune it by folklore;
• rebalance monitoring/maintenance window;
• RMAN/DR strategy proving ASM redundancy is not treated as backup;
• Grid Infrastructure ownership, privileges, patching, and compatibility assumptions.

10. Production judgment and bridge

ASM is valuable when Oracle-aware storage pooling, balanced placement, and failure-group-based protection match the deployment. It also introduces Grid Infrastructure lifecycle, storage discovery, compatibility attributes, operating-system ownership, monitoring, and recovery dependencies. Treat it as a platform decision, not a checkbox added after database creation.

Lesson 5 now brings the layers together into a workload-driven storage plan: application data, indexes where separation is justified, TEMP, undo, redo, archived/recovery files, growth, autoextend ceilings, monitoring, and backup/recovery behavior.

Authoritative references

• Oracle Automatic Storage Management Administrator’s Guide — Introduction — disk groups, disks, allocation units, striping, mirroring, and failure groups
• Oracle ASM Mirroring and Disk Group Redundancy — EXTERNAL/NORMAL/HIGH/FLEX/EXTENDED redundancy and failure-group rules
• Oracle AI Database Reference — V$ASM_DISKGROUP — disk-group capacity columns and disk-discovery monitoring warning
• Oracle AI Database Reference — V$ASM_DISK_STAT — lower-cost ASM disk/failure-group statistics
• Oracle Grid Infrastructure Installation Guide — ASM Storage Requirements — disk-count/capacity/AU planning for real ASM deployments