Oracle ASM Storage Explained: Disks, Failure Groups, Disk Groups, and Redundancy

Oracle Automatic Storage Management (ASM) is one of the most important technologies for Oracle DBAs working with enterprise databases, RAC, and high-availability environments.

Many DBAs know commands such as asmcmd, CREATE DISKGROUP, and v$asm_diskgroup, but the more important question is:

What actually happens to our data when an ASM disk fails?

To answer that properly, we need to understand four concepts:

ASM Disk → Failure Group → Disk Group → Redundancy

1. What is Oracle ASM?

Oracle ASM is Oracle’s storage management solution for database files.

Instead of manually managing individual filesystem files and worrying about where each datafile is placed, ASM manages storage through disk groups.

A simplified architecture is:

Physical Disks / LUNs

        │

        ▼

    ASM Disks

        │

        ▼

 Failure Groups

        │

        ▼

   ASM Disk Group

        │

        ▼

 Oracle Database Files

ASM can provide:

• Automatic file distribution
• Striping
• Mirroring
• Load balancing
• Online disk addition/removal
• Automatic rebalancing
• Storage redundancy

2. What is an ASM Disk?

An ASM disk is a storage device made available to ASM.

It could be backed by:

• SAN LUN
• Multipath device
• Cloud block storage
• Local storage
• Virtual disk
• Other supported storage infrastructure

For example:

/dev/mapper/asm_data01

/dev/mapper/asm_data02

/dev/mapper/asm_data03

/dev/mapper/asm_data04

These devices can be presented to ASM as ASM disks.

You can check them using:

SELECT

    group_number,

    disk_number,

    name,

    path,

    total_mb,

    free_mb,

    mount_status,

    header_status,

    state

FROM v$asm_disk

ORDER BY group_number, disk_number;

Or from asmcmd:

asmcmd lsdsk

3. What is an ASM Disk Group?

An ASM disk group is a collection of ASM disks managed together as a storage pool.

For example:

+DATA

 ├── DATA01

 ├── DATA02

 ├── DATA03

 └── DATA04

Oracle sees +DATA as one storage pool rather than four independent disks.

Database files can then be created in:

+DATA

without the DBA having to manually decide which physical disk should contain each datafile.

ASM handles the placement and distribution.

4. Typical ASM Disk Groups

A common Oracle environment might have:

+DATA

+REDO

+RECO

+DATA

Normally contains:

• Datafiles
• Tempfiles
• Sometimes control files
• Sometimes SPFILE

Example:

+DATA/PROD/DATAFILE/

+REDO

Often dedicated to:

• Online redo logs

Example:

+REDO/PROD/ONLINELOG/

+RECO

Normally used for recovery-related files, depending on the configuration:

• Archived redo logs
• RMAN backup sets
• Control file autobackups
• Flashback logs
• Other FRA-related files

Example:

+RECO/PROD/ARCHIVELOG/

+RECO/PROD/BACKUPSET/

+RECO/PROD/AUTOBACKUP/

Important: These are design conventions, not hard ASM rules. ASM does not inherently require a disk group to be named DATA, REDO, or RECO.

5. What is ASM Redundancy?

This is where ASM becomes particularly interesting.

ASM supports three major redundancy types:

Redundancy	ASM Mirroring	Typical protection
EXTERNAL	No	Storage subsystem provides redundancy
NORMAL	2-way	Can tolerate one failure group failure
HIGH	3-way	Can tolerate two failure group failures

Let’s understand them properly.

6. External Redundancy

With external redundancy:

CREATE DISKGROUP DATA

EXTERNAL REDUNDANCY

DISK

'/dev/asm_data01',

'/dev/asm_data02',

'/dev/asm_data03';

ASM does not mirror the data.

The underlying storage system is responsible for redundancy.

For example:

Oracle Database

       │

       ▼

      ASM

       │

       ▼

      SAN

       │

       ▼

     RAID

If the SAN/storage layer provides sufficient redundancy, ASM-level mirroring may not be necessary.

Advantage

You don’t consume additional ASM capacity for mirroring.

Disadvantage

Your availability depends heavily on the underlying storage infrastructure.

7. Normal Redundancy

Normal redundancy provides two-way mirroring.

Conceptually:

             +DATA

               │

        ┌──────┴──────┐

        │             │

       FG1           FG2

        │             │

     DATA01        DATA03

     DATA02        DATA04

        │             │

        └──── Mirror ─┘

ASM maintains two copies of data.

But here’s the important part:

The two copies should be placed in different failure groups.

That is why failure groups matter.

8. What is a Failure Group?

A failure group is a collection of ASM disks that ASM considers capable of failing together.

For example:

Failure Group 1

 ├── DATA01

 └── DATA02

Failure Group 2

 ├── DATA03

 └── DATA04

If these disks are connected to different physical storage paths or storage failure domains, ASM can protect mirrored copies against a failure of one domain.

For example:

             +DATA

               │

       ┌───────┴───────┐

       │               │

      FG1             FG2

       │               │

   Storage A        Storage B

ASM can place the primary extent in one failure group and its mirror in another.

9. Why Failure Groups Matter

This is one of the most misunderstood ASM concepts.

Suppose you have:

DATA01

DATA02

and you put both disks into the same failure group.

If both disks depend on the same underlying storage array and that array fails, you could lose both copies.

Simply having two disks does not automatically mean you have two independent failure domains.

The real question is:

Can these disks fail independently?

That’s what the failure-group design is intended to represent.

10. Creating a Normal Redundancy Disk Group

Example:

CREATE DISKGROUP DATA

NORMAL REDUNDANCY

FAILGROUP FG1

DISK

'/dev/asm_data01',

'/dev/asm_data02'

FAILGROUP FG2

DISK

'/dev/asm_data03',

'/dev/asm_data04';

The architecture is:

                    +DATA

                      │

             NORMAL REDUNDANCY

                      │

          ┌───────────┴───────────┐

          │                       │

         FG1                     FG2

          │                       │

      DATA01                   DATA03

      DATA02                   DATA04

          │                       │

          └────── 2-Way Mirror ──┘

If FG1 becomes unavailable, ASM can use the mirror copy in FG2, assuming the disk group remains operational.

11. High Redundancy

High redundancy provides three-way mirroring.

Conceptually:

                 +DATA

                   │

          ┌────────┼────────┐

          │        │        │

         FG1      FG2      FG3

          │        │        │

        Copy 1   Copy 2   Copy 3

Example:

CREATE DISKGROUP DATA

HIGH REDUNDANCY

FAILGROUP FG1 DISK '/dev/asm_data01'

FAILGROUP FG2 DISK '/dev/asm_data02'

FAILGROUP FG3 DISK '/dev/asm_data03';

ASM maintains three copies.

This provides stronger protection against failure-group failures, but the storage requirement is substantially higher.

12. Normal vs High Redundancy

Think of it like this:

Normal

Data

 ↓

Copy 1

Copy 2

Two copies.

High

Data

 ↓

Copy 1

Copy 2

Copy 3

Three copies.

Therefore:

NORMAL → 2-way mirroring

HIGH   → 3-way mirroring

The trade-off is straightforward:

More protection → more storage consumption.

13. ASM Striping

Redundancy isn’t the only thing ASM does.

ASM also distributes data across disks.

Imagine:

+DATA

DATA01

DATA02

DATA03

DATA04

Instead of putting all database I/O on one disk, ASM distributes allocation units/extents across available disks.

Conceptually:

Extent 1 → DATA01

Extent 2 → DATA02

Extent 3 → DATA03

Extent 4 → DATA04

Extent 5 → DATA01

...

This helps distribute I/O.

ASM therefore provides both:

Striping + Mirroring

depending on the configuration and file type.

14. What Happens When You Add a New Disk?

Suppose:

+DATA

DATA01

DATA02

DATA03

You add:

DATA04

ASM can rebalance the disk group.

Example:

ALTER DISKGROUP DATA

ADD DISK '/dev/asm_data04';

ASM begins redistributing storage across the disks.

You don’t manually move datafiles from DATA01 to DATA04.

That’s one of the major benefits of ASM.

15. ASM Rebalancing

You can monitor ASM operations using:

SELECT

    group_number,

    operation,

    state,

    power,

    sofar,

    est_work,

    est_minutes

FROM v$asm_operation;

If a rebalance is running, you might see:

GROUP_NUMBER  OPERATION  STATE

------------  ---------  -----

1             REBAL      RUN

Once complete, the operation disappears from v$asm_operation.

16. Checking Disk Group Capacity

Connect as:

sqlplus / as sysasm

Then:

SELECT

    name,

    type,

    total_mb,

    free_mb,

    usable_file_mb

FROM v$asm_diskgroup;

For a GB view:

SELECT

    name,

    type,

    ROUND(total_mb/1024,2) AS total_gb,

    ROUND(free_mb/1024,2) AS free_gb,

    ROUND(usable_file_mb/1024,2) AS usable_gb

FROM v$asm_diskgroup;

Important:

Don’t look only at FREE_MB.

With ASM redundancy, USABLE_FILE_MB is particularly important because it considers the redundancy requirements.

17. Checking ASM Disk Health

Use:

SELECT

    group_number,

    disk_number,

    name,

    path,

    total_mb,

    free_mb,

    mount_status,

    header_status,

    mode_status,

    state

FROM v$asm_disk

ORDER BY group_number, disk_number;

This gives you a good picture of:

• Which disk belongs to which group
• Disk path
• Disk size
• Disk state
• Mount status
• Header status

18. ASM Disk States You Should Know

Some commonly encountered states include:

NORMAL

Disk is operating normally.

CACHED

ASM has discovered the disk and is using cached information about it.

DROPPING

Disk is being removed from the disk group.

FORCING

Disk is being force-dropped or added with force-related operations.

The exact interpretation should always be considered alongside the disk group’s overall state and ASM alert log.

19. The Most Important Design Question

Don’t design ASM like this:

“I have four disks, so I’m protected.”

Instead ask:

How many disks?

        ↓

How many failure groups?

        ↓

Where are those failure groups physically located?

        ↓

What redundancy level?

        ↓

What failures can the design actually survive?

For example:

                 ASM

                  │

             +DATA NORMAL

                  │

          ┌───────┴───────┐

          │               │

         FG1             FG2

          │               │

       Storage A       Storage B

This is much more meaningful than simply saying:

“I have two disks.”

20. ASM Redundancy Is Not a Backup

This distinction is extremely important.

ASM redundancy protects against certain storage failures.

RMAN protects you against data loss and recovery scenarios.

For example:

ASM redundancy

      ↓

Storage availability

while:

RMAN backup

      ↓

Database recovery

And:

Data Guard

      ↓

Database-level disaster recovery

These solve different problems.

21. Example Enterprise Architecture

A practical architecture could look like:

                 Oracle Database

                       │

             ┌─────────┼─────────┐

             │         │         │

           +DATA     +REDO     +RECO

             │         │         │

             ▼         ▼         ▼

          Datafiles  Redo     Recovery

                               Files

And separately:

                 RMAN

                  │

                  ▼

          Backup Repository

                  │

          ┌───────┴────────┐

          │                │

       Local/NFS      Object Storage

This is much safer than keeping the only RMAN backup on the same storage that hosts the database.

22. ASM + RMAN During a Database Rebuild

This is particularly relevant when rebuilding a VM.

Suppose the original environment has:

+DATA

+REDO

+RECO

and you take an RMAN backup to an external filesystem:

/u01/refresh_backup/

Then you rebuild:

New VM

   ↓

New Grid Infrastructure

   ↓

New ASM

   ↓

New +DATA

New +REDO

New +RECO

   ↓

Copy RMAN backup

   ↓

Restore Controlfile

   ↓

Restore Database

   ↓

Recover Database

   ↓

OPEN RESETLOGS

The important architectural advantage is that the RMAN backup is outside the ASM storage being rebuilt.

That makes the refresh/rebuild process considerably cleaner.

23. Key ASM Commands Cheat Sheet

Show disk groups

SELECT name,

       type,

       total_mb,

       free_mb,

       usable_file_mb

FROM v$asm_diskgroup;

Show ASM disks

SELECT group_number,

       disk_number,

       name,

       path,

       total_mb,

       free_mb,

       state

FROM v$asm_disk;

Check ASM operations

SELECT group_number,

       operation,

       state,

       power,

       sofar,

       est_work,

       est_minutes

FROM v$asm_operation;

ASM command line

asmcmd lsdg

asmcmd lsdsk

asmcmd ls +DATA

asmcmd ls +RECO

Final Takeaway

The easiest way to remember Oracle ASM is:

ASM DISK

   ↓

Physical storage presented to ASM

FAILURE GROUP

   ↓

Disks that may fail together

DISK GROUP

   ↓

Storage pool managed by ASM

REDUNDANCY

   ↓

How ASM protects/mirrors data

And the three redundancy options:

EXTERNAL

   ASM does not mirror

   Storage provides protection

NORMAL

   2-way mirroring

   Protection against one failure group failure

HIGH

   3-way mirroring

   Stronger protection against failure-group failures

The real skill isn’t memorizing CREATE DISKGROUP syntax. It’s understanding the physical storage topology behind the ASM configuration.

If FG1 and FG2 ultimately depend on the same physical storage array, you’ve created two ASM failure groups but potentially only one real failure domain. That’s the kind of detail an Oracle DBA needs to understand before calling an ASM design highly available.