Oracle RAC 19c Masterclass – Part 4

By | | ,

Oracle Automatic Storage Management (ASM): Architecture, Internals, and Best Practices

If Oracle Clusterware is the brain of an Oracle RAC cluster, then Oracle Automatic Storage Management (ASM) is its storage engine.

Before ASM, DBAs spent a significant amount of time managing file systems, raw devices, LUN layouts, and datafile placement. Oracle introduced ASM to simplify storage administration while improving performance and availability.

Today, ASM is the recommended storage solution for Oracle RAC because it provides a single, integrated layer for managing database files across all nodes in the cluster.

In this article, we’ll explore how ASM works internally, how it organizes storage, and why it has become the standard choice for Oracle RAC deployments.

What is Oracle ASM?

Oracle ASM is Oracle’s volume manager and file system designed specifically for Oracle databases.

Instead of managing files manually, DBAs manage disk groups, and ASM automatically places database files across the available disks.

Think of ASM as an intelligent storage layer between the database and the operating system.

                Oracle Database
                       |
                 Oracle ASM
                       |
        +-----------------------------+
        |      Disk Groups            |
        +-----------------------------+
               |      |      |
            Disk1  Disk2  Disk3

The database never accesses the disks directly. Every read and write operation passes through ASM.

Why Use ASM?

ASM was designed to solve common storage administration challenges.

Without ASM, DBAs typically had to:

  • Create file systems.
  • Decide where each datafile should be stored.
  • Balance I/O manually.
  • Expand storage manually.
  • Manage raw devices.

ASM automates much of this work.

Benefits include:

  • Automatic file placement.
  • Online storage expansion.
  • Automatic load balancing.
  • Integrated redundancy options.
  • Simplified administration.

ASM Architecture

An ASM environment consists of:

              +--------------------+
              | ASM Instance       |
              +--------------------+
                       |
                ASM Disk Groups
                       |
         +------+------+------+
         |             |       |
      Disk 1       Disk 2   Disk 3

Unlike a database instance, an ASM instance does not store application data.

Its purpose is to manage storage metadata and coordinate access to the disks.

ASM Instance

Each RAC node runs its own ASM instance.

Example:

Node1

+ASM1

Node2

+ASM2

The ASM instances communicate with each other to manage shared storage.

Unlike database instances, ASM uses relatively little memory because it stores only metadata about disk groups and files.

ASM Disk Groups

The basic storage unit in ASM is the disk group.

A disk group is a logical collection of one or more disks.

Typical RAC configuration:

Disk GroupPurpose
+OCROCR and Voting Files
+DATADatabase files
+FRARecovery Area

Example:

+DATA
   |
   +-- Datafiles
   +-- Tempfiles
   +-- Redo Logs
   +-- Control Files

+FRA
   |
   +-- Archive Logs
   +-- RMAN Backups
   +-- Flashback Logs

Separating database files from recovery files improves manageability and simplifies capacity planning.

ASM Files

ASM stores many Oracle file types, including:

  • Datafiles
  • Control files
  • Online redo logs
  • Tempfiles
  • SPFILE
  • Password files
  • Archive logs
  • RMAN backup pieces

For example:

+DATA/ORCL/DATAFILE/system.257.1112345678

The file name is generated automatically. In most environments, DBAs do not need to manage file names manually.

Allocation Units (AU)

ASM divides each disk into Allocation Units (AUs).

An AU is the smallest unit of storage managed by ASM.

Disk

+--------------------------------+
| AU | AU | AU | AU | AU | AU |
+--------------------------------+

Oracle recommends choosing an AU size that matches your workload and storage design. The default value is suitable for most environments.

Striping

ASM distributes data evenly across all disks in a disk group.

Disk1     Block1
Disk2     Block2
Disk3     Block3
Disk1     Block4
Disk2     Block5
Disk3     Block6

This technique, known as striping, offers two key advantages:

  • Improved performance by spreading I/O across multiple disks.
  • Better utilization of available storage resources.

Unlike traditional file systems, DBAs do not need to decide where each datafile should reside.

ASM Redundancy Levels

ASM supports three redundancy options.

RedundancyDescription
ExternalProtection provided by the storage array
NormalTwo-way mirroring
HighThree-way mirroring

External Redundancy

Use when the storage system already provides RAID protection.

ASM

|

Storage RAID

This avoids unnecessary duplication.

Normal Redundancy

Each extent is stored twice.

Disk1

Copy A

Disk2

Copy B

If one disk fails, the mirrored copy remains available.

High Redundancy

Each extent has three copies.

Disk1

Copy A

Disk2

Copy B

Disk3

Copy C

This option provides greater fault tolerance but requires additional storage.

Failure Groups

A failure group defines disks that are likely to fail together.

Examples:

  • A storage controller.
  • A disk shelf.
  • A storage enclosure.

ASM places mirrored copies in different failure groups.

Failure Group A

Disk1
Disk2

Failure Group B

Disk3
Disk4

This reduces the risk of losing multiple mirrored copies during a single hardware failure.

ASM Rebalancing

One of ASM’s most valuable features is automatic rebalancing.

When a disk is added:

Before

Disk1 70%

Disk2 70%

After Adding Disk3

Disk1 45%

Disk2 45%

Disk3 45%

ASM redistributes data online while the database remains available.

The same process occurs when a disk is removed.

Viewing Disk Groups

Display disk groups:

SELECT name,
       state,
       type,
       total_mb,
       free_mb
FROM   v$asm_diskgroup;

Example:

NAME    STATE    TYPE

DATA    MOUNTED  EXTERN
FRA     MOUNTED  EXTERN
OCR     MOUNTED  NORMAL

Viewing ASM Disks

SELECT group_number,
       disk_number,
       name,
       path,
       state
FROM   v$asm_disk;

This view helps verify:

  • Disk status.
  • Disk paths.
  • Membership.
  • Disk availability.

ASM Command-Line Utility

The asmcmd utility simplifies ASM administration.

Display disk groups:

asmcmd lsdg

List ASM files:

asmcmd ls +DATA

Display disk information:

asmcmd lsdsk

These commands are part of a DBA’s daily toolkit.

Monitoring Rebalance Operations

During a rebalance, monitor progress:

SELECT operation,
       state,
       power,
       sofar,
       est_work
FROM   v$asm_operation;

A long-running rebalance is not necessarily a problem; its duration depends on disk size, workload, and rebalance power.

ASM and Oracle RAC

Every RAC node accesses the same ASM disk groups.

             +ASM1
               |
      +----------------+
      |     +DATA      |
      +----------------+
               |
             +ASM2

Because the storage is shared, all RAC instances see the same database files.

This shared access is fundamental to Oracle RAC.

Common ASM Issues

Disk Discovery Failure

Symptoms:

  • Disk group cannot be mounted.
  • ASM reports missing disks.

Verify:

asmcmd lsdsk

Check operating system permissions and ASM disk discovery settings.

Insufficient Space

Symptoms:

  • ORA-15041
  • Database cannot add files.

Verify:

SELECT name,
       free_mb
FROM   v$asm_diskgroup;

Plan capacity before space becomes critical.

Long Rebalance Operations

Possible causes:

  • Large disk groups.
  • Low rebalance power.
  • Heavy database activity.

Monitor progress rather than assuming the operation is stalled.

Disk Offline

Check disk status:

SELECT name,
       state,
       mode_status
FROM   v$asm_disk;

Investigate storage connectivity before attempting to drop or replace the disk.

Best Practices

  • Use separate disk groups for DATA and FRA.
  • Choose the redundancy level based on your storage architecture.
  • Define proper failure groups when using ASM redundancy.
  • Monitor free space regularly.
  • Schedule large rebalance operations during periods of lower activity when possible.
  • Use consistent disk naming conventions.
  • Protect OCR and Voting Files with appropriate redundancy.

DBA Tip

One of the most common misconceptions is that ASM replaces the storage array. It doesn’t.

ASM complements your storage by providing Oracle-aware file management, striping, and redundancy. When using enterprise SAN storage with RAID, External Redundancy is often the right choice because the storage system already provides protection. In environments without hardware redundancy, Normal or High Redundancy may be more appropriate.

The key is to understand where redundancy is already provided. Duplicating it unnecessarily can increase storage consumption without adding meaningful resilience.

Good ASM design starts with understanding your storage architecture—not just selecting a redundancy option.

Conclusion

Oracle ASM simplifies storage management by replacing manual file placement with intelligent, automated storage administration. Through disk groups, striping, online rebalancing, and integrated redundancy, ASM provides the flexibility and performance needed for Oracle RAC.

Understanding how ASM organizes storage is essential before learning advanced topics such as Flex ASM, disk group maintenance, OCR and Voting Disk management, and RAC performance tuning.

Bookmark the permalink.
Loading Facebook Comments ...

Leave a Reply