Oracle ASM LUNs Exhaust Volume Space Despite Aggregate Free Space
A new Oracle 19c database on RHEL 8 uses eight 2TB LUNs in an ASM disk group with external redundancy. The LUNs are presented through an igroup with ALUA and Linux DM-Multipath. The customer wants thin provisioning and 30 daily snapshots. The volumes were created with space guarantee none, LUN space reservation disabled, and 5% snapshot reserve. Three months later, Oracle writes fail with ENOSPC even though the containing aggregate is only 45% used. ASM reports disks going offline. The storage team confirms the aggregate has free space and asks why the database failed and how the design should be corrected without rebuilding the database.
1. Explain why the database hit ENOSPC when the aggregate still had free space.
Read the worked answer
Aggregate free space is not the same as volume free space. The LUNs were thin-provisioned with reservation disabled, so the volumes could be overcommitted. As Oracle wrote data, the volumes consumed space. At the same time, 30 daily snapshots retained changing blocks, and snapshot usage competed for the same volume space. When a volume's own free space reached zero, writes to the LUN failed with ENOSPC even though the aggregate had capacity.
The 5% snapshot reserve is a planning value, not a guarantee that snapshots will never affect writes. Snapshot growth plus database growth exhausted the volume. ASM disks then went offline because the underlying LUNs could no longer accept writes. The aggregate had free space, but the volume did not automatically grow into it.
2. Describe the corrected provisioning and monitoring design, including what to change for Oracle ASM.
Read the worked answer
For Oracle ASM on SAN, enable LUN space reservation or set the volume guarantee to volume so the LUN's blocks are protected. Thin provisioning at the aggregate level is acceptable, but the LUN should not be allowed to run out of volume space independently of the database. Size volumes with headroom for ASM rebalance and snapshot growth.
Set snapshot reserve deliberately or use snapshot autodelete policies that trigger before the volume fills. Enable volume autogrow with a maximum size and adequate aggregate headroom. Monitor volume free space, snapshot usage, and LUN reservation state, not just aggregate capacity. Alert well before volume free space reaches zero.
For the existing database, extend the affected volumes and LUNs, rescan and bring ASM disks back online, then adjust reservation, snapshot, and autogrow settings. Validate with ASM and Oracle before returning to production.