Understanding ASM Disk Group Attributes in Oracle Exadata

Introduction

When you create an ASM disk group on Exadata, the ATTRIBUTE clause decides a lot about how it behaves: which software versions can use it, whether Smart Scan works, how quickly a failed disk is dropped, and more. Some of these attributes cannot be reverted once set, so it pays to understand them before running CREATE DISKGROUP.

This post starts with the most commonly asked-about attribute, COMPATIBLE.ASM, then covers the other attributes that matter on Exadata.

1. The Compatibility Attributes

Three attributes control which software versions can work with a disk group.

COMPATIBLE.ASM

COMPATIBLE.ASM sets the minimum Oracle ASM software version that can mount and use the disk group. It determines the format of ASM metadata structures such as disk headers, file directories and extent maps.

• An ASM instance with a lower software version cannot mount the disk group.
• It determines which ASM features are available to the disk group.
• If you don’t specify it, the default is 10.1, which is rarely what you want on a modern system.

COMPATIBLE.RDBMS

COMPATIBLE.RDBMS sets the minimum COMPATIBLE initialization parameter value a database instance must have to use the disk group.

Rule: COMPATIBLE.RDBMS must be less than or equal to COMPATIBLE.ASM, and each database’s COMPATIBLE parameter must be at least COMPATIBLE.RDBMS.

Why this matters

⚠️ Compatibility attributes can only be advanced, never lowered.
To go back, you must drop and recreate the disk group and restore the data.

If older databases share the disk group, or you may need to roll back after an upgrade, keep COMPATIBLE.RDBMS at the lowest database version that must use it. Raising it too high locks out older databases.

2. Exadata-Specific Attributes

CELL.SMART_SCAN_CAPABLE

Set to TRUE so the disk group’s grid disks can use Smart Scan offload to the storage cells. This requires COMPATIBLE.RDBMS of 11.2.0.0.0 or higher. Without it, the database cannot offload SQL processing to the cells for that disk group.

AU_SIZE

The allocation unit size is the basic unit of space allocation in ASM. It can only be set at creation time. Oracle generally recommends 4 MB for Exadata disk groups. This works well with large sequential I/O and keeps ASM extent maps compact for large databases.

APPLIANCE.MODE

Appliance mode is enabled on Exadata disk groups. It optimizes disk partnership and rebalance behavior for Exadata’s storage layout. Exadata’s deployment tooling sets it for you, so check the current setting before changing anything by hand.

CONTENT.TYPE

Values are DATA, RECOVERY or SYSTEM. It influences how ASM chooses disk partners, so a failure affecting one disk group is less likely to also hit the related one. This is useful for keeping DATA and RECO separated.

Repair time attributes

• DISK_REPAIR_TIME: how long ASM waits after a disk goes offline before dropping it. The default is 12 hours in recent releases (3.6 hours in 11g).
• FAILGROUP_REPAIR_TIME: the same idea for a whole failure group (a storage cell on Exadata). The default is 24 hours.

Increase these if you plan extended cell maintenance. This lets ASM resync only the changed extents instead of fully rebalancing when the disks return.

3. Putting It Together: A Typical Exadata Disk Group

CREATE DISKGROUP DATAC1 HIGH REDUNDANCY
  DISK 'o/*/DATAC1_*'
  ATTRIBUTE 'compatible.asm'          = '19.0.0.0.0',
            'compatible.rdbms'        = '19.0.0.0.0',
            'cell.smart_scan_capable' = 'TRUE',
            'au_size'                 = '4M';

On Exadata, each storage cell is automatically its own failure group, so you don’t define failure groups manually.

4. Changing and Checking Attributes

Raise a compatibility attribute:

ALTER DISKGROUP DATAC1 SET ATTRIBUTE 'compatible.asm' = '19.0.0.0.0';
ALTER DISKGROUP DATAC1 SET ATTRIBUTE 'compatible.rdbms' = '19.0.0.0.0';

Check the current values:

SELECT g.name AS diskgroup, a.name AS attribute, a.value
FROM   v$asm_diskgroup g, v$asm_attribute a
WHERE  g.group_number = a.group_number
AND    a.name NOT LIKE 'template%'
ORDER  BY g.name, a.name;

To see only the compatibility attributes, change the filter to AND a.name LIKE 'compatible%'.

5. Best Practices Checklist

1. Set COMPATIBLE.ASM to the Grid Infrastructure version you are running (for example 19.0.0.0.0).
2. Set COMPATIBLE.RDBMS to the lowest database version that will use the disk group, and raise it only after every database using it has been upgraded.
3. Always set CELL.SMART_SCAN_CAPABLE to TRUE on Exadata data disk groups.
4. Choose AU_SIZE at creation (4 MB is the usual recommendation); it cannot be changed later.
5. Tune DISK_REPAIR_TIME and FAILGROUP_REPAIR_TIME before planned cell maintenance.
6. Document your attribute values and verify them after every upgrade or patching cycle.

Conclusion

Disk group attributes are easy to overlook but hard to undo. A few minutes of planning around COMPATIBLE.ASM, COMPATIBLE.RDBMS, AU_SIZE and CELL.SMART_SCAN_CAPABLE can save you from a disk group rebuild later. Do you use different compatibility settings across your Exadata environments? Let me know in the comments.

Disclaimer: Always test attribute changes in a non-production environment first, and verify against the Oracle documentation for your specific Grid Infrastructure and Exadata System Software versions.