How to Create and Configure ASM Disk Groups on Oracle Exadata Database Machine

Oracle Automatic Storage Management (ASM) serves as the foundational storage management layer for Oracle Exadata environments. By organizing grid disks into logical disk groups, database administrators can achieve optimal redundancy, enhanced performance, and seamless integration with Exadata’s intelligent storage features like Smart Scan offloading.

This comprehensive guide walks you through the complete process of creating ASM disk groups, understanding critical configuration parameters, and implementing proven strategies for production environments.

Complete Implementation Guide

Initial Setup: Establishing ASM Connection

Before creating disk groups, you must establish a connection to the ASM instance with appropriate privileges.

Configure your environment variable to point to the correct ASM instance:

$ export ORACLE_SID=+ASM1

Access the ASM instance using SYSASM administrative privileges:

$ sqlplus / as sysasm

Inventory Assessment: Discovering Available Storage

Before provisioning new disk groups, examine the available grid disks in your Exadata environment:

sql

SQL> SELECT path, header_status 
FROM v$asm_disk 
WHERE path LIKE 'o/%'
ORDER BY path;

This query returns all Exadata-managed grid disks and their current assignment status, helping you identify unallocated storage resources.

Disk Group Creation Examples

Primary Data Storage (High Redundancy Configuration)

For mission-critical database files requiring maximum protection:

CREATE DISKGROUP primary_data HIGH REDUNDANCY
DISK 'o/*/DATA_CD_*'
ATTRIBUTE 'au_size' = '4M',
          'content.type' = 'data',
          'compatible.rdbms' = '12.2.0.1',
          'compatible.asm' = '21.0.0.0',
          'cell.smart_scan_capable' = 'TRUE';

Recovery Area Storage (High Redundancy Configuration)

For archived redo logs, RMAN backups, and flashback logs:

CREATE DISKGROUP fast_recovery HIGH REDUNDANCY
DISK 'o/*/RECO_CD_*'
ATTRIBUTE 'au_size' = '4M',
          'content.type' = 'recovery',
          'compatible.rdbms' = '12.2.0.1',
          'compatible.asm' = '21.0.0.0';

System Files Storage (For Earlier Exadata Models)

On pre-X8 Exadata systems, configure the system disk group:

ALTER DISKGROUP system_files SET ATTRIBUTE 
'content.type' = 'system',
'compatible.rdbms' = '12.2.0.1',
'compatible.asm' = '21.0.0.0';

Sparse Disk Group (For Snapshot and Clone Operations)

Enable thin provisioning for test/development clones:

CREATE DISKGROUP snapshot_storage NORMAL REDUNDANCY
DISK 'o/*/SPARSE_CD_*'
ATTRIBUTE 'au_size' = '4M',
          'content.type' = 'data',
          'cell.smart_scan_capable' = 'TRUE',
          'compatible.rdbms' = '12.2.0.1',
          'compatible.asm' = '21.0.0.0',
          'cell.sparse_dg' = 'allsparse';

Critical Configuration Parameters

Version Compatibility Guidelines

The compatibility settings determine which Oracle features your disk group can utilize. Sparse disk groups specifically require both compatible.asm and compatible.rdbms set to version 12.2.0.1 or higher. Remember that disk group compatibility attributes take precedence over ASM instance-level compatibility settings, so plan your version strategy carefully.

Allocation Unit Sizing

The allocation unit size determines how ASM allocates space within the disk group. For Exadata environments, Oracle recommends setting au_size to 4MB to optimize parallel query performance and Smart Scan efficiency. This sizing balances metadata overhead with I/O performance for typical Exadata workloads.

Verifying Disk Group Configuration

After creating disk groups, validate their configuration using ASM dynamic performance views:

SQL> SELECT dg.name AS diskgroup_name, 
            a.name AS attribute_name, 
            a.value AS attribute_value
FROM v$asm_diskgroup dg 
JOIN v$asm_attribute a ON dg.group_number = a.group_number
WHERE dg.name IN ('PRIMARY_DATA', 'FAST_RECOVERY')
ORDER BY dg.name, a.name;

Sample Attribute Configuration

Implementing Tablespaces on ASM Disk Groups

Once your disk groups are configured, create tablespaces that leverage Exadata’s intelligent storage capabilities:

SQL> CREATE TABLESPACE app_data 
DATAFILE '+PRIMARY_DATA' 
SIZE 10G 
AUTOEXTEND ON 
NEXT 1G 
MAXSIZE UNLIMITED;

Confirming Smart Scan Enablement

Verify that your tablespace is configured for storage-side query processing:

SQL> SELECT tablespace_name, 
            predicate_evaluation,
            def_inmemory
FROM dba_tablespaces 
WHERE tablespace_name = 'APP_DATA';

When predicate_evaluation displays ‘STORAGE’, your queries can be offloaded to Exadata storage servers, dramatically reducing the volume of data transferred to database servers and accelerating analytical query performance.

Production Best Practices

• Standardize allocation unit sizing by consistently using 4MB allocation units across all Exadata disk groups to ensure optimal Smart Scan performance and minimize storage fragmentation.
• Apply appropriate content classification by setting correct content.type values for each disk group purpose. This classification enables ASM to apply appropriate failure group policies and helps with capacity planning and performance monitoring.
• Maintain storage homogeneity by ensuring disk groups contain only Exadata grid disks. Mixing storage types can lead to performance unpredictability and complicate troubleshooting.
• Implement regular validation routines by periodically querying ASM dynamic views to verify disk group attributes remain correctly configured, especially after maintenance windows or system upgrades.
• Optimize for query offloading by placing frequently accessed analytical tables in disk groups configured with Smart Scan capability enabled. This maximizes the performance benefits of Exadata’s storage intelligence.
• Plan compatibility progression before upgrading ASM or database software by understanding that compatibility attribute changes are one-way operations. Always test compatibility upgrades in non-production environments first.
• Monitor disk repair time settings to ensure failed disk replacement windows align with your availability requirements. The default 3.6-hour setting works well for most Exadata configurations with Oracle support SLAs.

Summary

Properly configured ASM disk groups form the foundation of reliable, high-performance Oracle Exadata deployments. By understanding allocation unit sizing, compatibility requirements, redundancy levels, and content classification, you can build storage architectures that maximize Exadata’s unique capabilities while ensuring data protection and operational flexibility. The configuration examples and validation techniques provided here enable you to implement disk groups that meet both current operational needs and future scalability requirements.