How to Create an ASM Diskgroup and Add Disks in Oracle ASM – Step-by-Step Guide

Introduction

Oracle Automatic Storage Management (ASM) simplifies database storage administration by providing integrated cluster volume management and file system virtualization. Two routine operations every Oracle DBA must master are provisioning a new diskgroup and dynamically adding storage to an existing diskgroup without downtime.

Prerequisites: Identifying Candidate Disks

Before issuing any CREATE or ALTER diskgroup statements, ensure that the storage disks are visible to the operating system, have correct ownership/permissions, and show a valid ASM header status.

Step 1. Check OS Disk Discovery & Permissions

Ensure disk permissions belong to your Grid infrastructure owner (typically grid or oracle) and ASM administration group (e.g., asmadmin):

ls -l /dev/oracleasm/disks/
# OR for udev/multipath devices:
ls -l /dev/mapper/asm_disk*

Step 2. Check Disk Header Status in ASM

Connect to the ASM instance as SYSASM:

export ORACLE_SID=+ASM1  # (or +ASM in single-instance)
export ORACLE_HOME=/u01/app/19.0.0/grid
sqlplus / as sysasm

Run the following SQL check:

SELECT path, name, header_status, mode_status, state, total_mb FROM v$asm_disk ORDER BY path;

Understanding HEADER_STATUS Values:

• CANDIDATE / PROVISIONED: Disk is unformatted, valid, and available to be added to a diskgroup.
• FORMER: Disk previously belonged to a dropped diskgroup; safe to reuse.
• MEMBER: Disk is currently part of an active diskgroup. Do not use.
• UNKNOWN: ASM cannot read the disk header. Check OS permissions, discovery string, or multipath settings.

Part 1: How to Create a New ASM Diskgroup

When creating a diskgroup, determine the appropriate redundancy level and allocation unit (AU) size based on your workload:

• EXTERNAL REDUNDANCY: No ASM mirroring (relies on hardware RAID / SAN mirroring).
• NORMAL REDUNDANCY: 2-way ASM mirroring (requires minimum 2 failure groups/disks).
• HIGH REDUNDANCY: 3-way ASM mirroring (requires minimum 3 failure groups/disks).
• FLEX REDUNDANCY: Allows redundancy to be set at the database/file level (Oracle 12.2+).

There are two common ways to create a new ASM diskgroup: ASMCA (GUI) and SQL*Plus (SQL syntax).

If your environment uses Oracle ASMLIB for ASM disk discovery, label the disks that will be used for the diskgroup before creating it:

oracleasm createdisk ASM_DATA01 /dev/sdc1
oracleasm createdisk ASM_DATA02 /dev/sdd1

Then verify:

oracleasm listdisks

Scenario A: Create an External Redundancy Diskgroup

CREATE DISKGROUP DATA_DG EXTERNAL REDUNDANCY
DISK 
    '/dev/oracleasm/disks/ASM_DATA01',
    '/dev/oracleasm/disks/ASM_DATA02'
ATTRIBUTE 
    'compatible.asm' = '19.0.0.0.0',
    'compatible.rdbms' = '19.0.0.0.0',
    'au_size' = '4M';

Scenario B: Create a Normal Redundancy Diskgroup with Explicit Failure Groups

CREATE DISKGROUP FRA_DG NORMAL REDUNDANCY
FAILGROUP FRA_FG1 DISK '/dev/oracleasm/disks/ASM_FRA01'
FAILGROUP FRA_FG2 DISK '/dev/oracleasm/disks/ASM_FRA02'
ATTRIBUTE 
    'compatible.asm' = '19.0.0.0.0',
    'compatible.rdbms' = '19.0.0.0.0';

Verify the New Diskgroup

SELECT group_number, name, state, type, total_mb, free_mb FROM v$asm_diskgroup WHERE name = 'FRA_DG';

Part 2: How to Add Disks to an Existing Diskgroup

When storage capacity in an existing diskgroup drops below threshold, you can expand it dynamically without database downtime.

Step 1: Identify the Free Candidate Disks

SELECT path, header_status, os_mb FROM v$asm_disk 
WHERE header_status IN ('CANDIDATE', 'FORMER', 'PROVISIONED');

Tip: Production Validation

Before adding a disk to a production ASM diskgroup, verify that the disk is visible across all RAC nodes, has appropriate size and performance characteristics, and is not already in use. For NORMAL or HIGH redundancy, also ensure the disk is assigned to the appropriate failure group.

Step 2: Add Disks with Controlled Rebalance

When adding disks, ASM automatically initiates a rebalance to redistribute existing extents across the disks in the diskgroup. Use the REBALANCE POWER clause to control how aggressively ASM consumes I/O resources during this operation.

ALTER DISKGROUP DATA_DG 
ADD DISK 
    '/dev/oracleasm/disks/ASM_DATA03',
    '/dev/oracleasm/disks/ASM_DATA04'
REBALANCE POWER 4;

Tip: Rebalance Sizing

In production systems during peak hours, set REBALANCE POWER between 1 and 4 to prevent I/O contention with active database workloads. During maintenance windows or low-activity off-peak periods, increase it up to 8 or 16 (or higher depending on your asm_power_limit parameter setting) for significantly faster rebalance completion.

Dynamic Rebalance Power Tuning

If the rebalance is taking too long or saturating SAN storage, alter the power value on the fly without stopping the operation:

-- Speed up an ongoing rebalance
ALTER DISKGROUP DATA_DG REBALANCE MODIFY POWER 8;

-- Throttle it down during peak transactions
ALTER DISKGROUP DATA_DG REBALANCE MODIFY POWER 2;

Monitoring the ASM Rebalance Operation

Monitor disk rebalancing progress via the V$ASM_OPERATION dynamic view:

COL group_name FORMAT a15
COL operation FORMAT a10
COL state FORMAT a10

SELECT 
    g.name AS group_name,
    o.operation,
    o.state,
    o.power,
    o.actual,
    o.est_minutes,
    o.sofar,
    o.est_work
FROM 
    v$asm_operation o 
JOIN 
    v$asm_diskgroup g ON o.group_number = g.group_number;

If the query returns no rows, the rebalance operation has completed successfully.

Extent distribution across all member disks can be verified via:

SELECT 
    d.name, 
    d.path, 
    d.total_mb, 
    d.free_mb 
FROM 
    v$asm_disk d 
JOIN 
    v$asm_diskgroup g ON d.group_number = g.group_number
WHERE 
    g.name = 'DATA_DG';

Post-Configuration Steps for Oracle RAC Environments

In an Oracle Real Application Clusters (RAC) environment, ensure the newly created diskgroup is mounted across all cluster nodes and registered with Oracle Clusterware (CRS).

Step 1. Register and Start Diskgroup via CRS

Check diskgroup status:

srvctl status diskgroup -diskgroup DATA_DG

Mount diskgroup on all cluster nodes:

srvctl start diskgroup -diskgroup DATA_DG

Step 2. Verify Cross-Node Visibility

On each RAC node, verify the diskgroup mounts automatically:

SELECT inst_id, group_number, name, state FROM gv$asm_diskgroup  WHERE name = 'DATA_DG';

Best Practice Checklist

• Uniform Disk Sizes: Prefer disks with similar capacity and performance characteristics within a diskgroup. Mixing significantly different disk sizes or performance tiers can result in uneven utilization and performance characteristics.
• AU Size: Choose the allocation unit size during disk group creation based on the database workload and file characteristics. The AU size cannot be changed after disk group creation, so evaluate the requirement before creating the disk group.
• Rebalance Verification: Always verify v$asm_operation returns empty before shutting down or executing patching on any cluster nodes.