Oracle problems

ASM Disk Group Running Out of Space: The Number That Counts, What a Failed Disk Does to It, and the Fix

2 November 2026

An ASM disk group has four space numbers, and the one most dashboards show is the wrong one. FREE_MB says how much is not yet written. USABLE_FILE_MB says how much you can still use and survive a disk failure, and on a normal redundancy group it is less than half of the first number. When it turns negative, the group is already in trouble, with free space on the screen.

What the errors say

ORA-15041: diskgroup "DATA" space exhausted: a file could not grow or be created. A datafile that autoextends into a full group reports it under ORA-01653; the archiver reports it in the alert log and then stops, which is the ORA-00257 page.
No error at all, and a disk fails: the group cannot mirror its contents onto the remaining disks, and the next failure loses data. That is what a negative USABLE_FILE_MB means.

The number that counts

SELECT name, type, state, offline_disks,
       ROUND(total_mb / 1024)                 AS total_gb,
       ROUND(free_mb / 1024)                  AS free_gb,
       ROUND(required_mirror_free_mb / 1024)  AS reserve_gb,
       ROUND(usable_file_mb / 1024)           AS usable_gb,
       ROUND(usable_file_mb / total_mb * 100) AS usable_pct
FROM   v$asm_diskgroup
ORDER  BY usable_pct;

REQUIRED_MIRROR_FREE_MB is the space ASM wants to keep free so that it can rebuild the mirrors after one disk fails. USABLE_FILE_MB is what is left after that reserve, divided by the redundancy: by 2 on a normal redundancy group, by 3 on a high one. On external redundancy, where the storage array does the mirroring, it equals FREE_MB. Alert on USABLE_FILE_MB, never on FREE_MB.

Why the group is full when it is not

ASM spreads every file over all disks of the group in proportion to their size. A group whose disks differ in size, or whose rebalance never finished, fills its smallest disk first, and ORA-15041 arrives with hundreds of gigabytes free on the others:

SELECT group_number, name, path, state, mount_status,
       ROUND(total_mb / 1024)           AS total_gb,
       ROUND(free_mb / 1024)            AS free_gb,
       ROUND(free_mb / total_mb * 100)  AS pct_free
FROM   v$asm_disk
WHERE  group_number > 0
ORDER  BY group_number, pct_free;

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

Disks of one group with PCT_FREE ten points apart are an unfinished or a failed rebalance, and V$ASM_OPERATION says whether one runs, waits or stopped with an error.

What takes the space

On the ASM instance, by file type:

SELECT type, COUNT(*) AS files,
       ROUND(SUM(space) / POWER(1024, 3)) AS gb_with_mirrors
FROM   v$asm_file
WHERE  group_number = 1
GROUP  BY type
ORDER  BY gb_with_mirrors DESC;

SPACE already includes the mirror copies. Archived logs and backup sets in a data group mean that a recovery area shares it; the first directory under the group is the database, which is how a shared group is divided between databases on a cluster.

Fix it, in this order

Add a disk, the same size as the others. Online; the rebalance runs in the background and POWER sets how hard it works:
```
ALTER DISKGROUP data
      ADD DISK '/dev/mapper/asm_data_09'
      REBALANCE POWER 8;
```
A disk of a different size keeps the group unbalanced; a far larger one is wasted beyond the size of the others.
Grow the LUNs, then the disks. When the storage team enlarged the LUNs instead: ALTER DISKGROUP data RESIZE ALL; tells ASM to use the new size.
Give back what is not needed. Archived logs and obsolete backups in the group, through RMAN, never with asmcmd rm while the database still lists them. Datafiles with free space at their end: ALTER DATABASE DATAFILE '+DATA/ORCL/DATAFILE/old_data.123.456' RESIZE 20G;. Tablespaces nobody uses any more.
Finish the rebalance. A rebalance that stopped on an error leaves the group unbalanced: fix the error, then ALTER DISKGROUP data REBALANCE POWER 8;.

See it coming

A disk group fills at the rate the databases on it grow, and that rate is steady enough to give a date. Radar Engine, the detection layer of Scops, forecasts each group and the datafiles that will grow into it:

Detector	Clock	When it fires
ASM disk group running low	Hourly forecast and level	The date it fills, against horizons of 14, 45 and 90 days. Under 5%: Watch. Under 2% and 100 GB: Warning. Under 1% headroom and 50 GB usable: Critical.
ASM space running out	Daily forecast for all disk groups	The date, against the same horizons.
Datafile space running out	Daily forecast: the datafiles to their maximum size, then ASM	The date when ASM is full. Else Watch.
Unusual database growth	Daily	Growth far above the usual: Watch. If the space limit comes within 90 days: Warning.

The third one is the one that matters on a shared group: every datafile on every database can autoextend into the same space, and the group is full on the date their maximum sizes add up to it, not on the date any single tablespace is full.

Questions

Why ORA-15041 when FREE_MB shows space?
The group is unbalanced: disks of different sizes, or a rebalance that did not finish, so the smallest disk is full. V$ASM_DISK shows the disk, V$ASM_OPERATION the rebalance.

What does a negative USABLE_FILE_MB mean?
The group has less free space than it needs to re-mirror its contents after one disk fails. Files can still grow, but the next disk failure cannot be absorbed. Add space before that.

Does adding a disk need downtime?
No. The disk joins online and the rebalance runs in the background. A high rebalance power finishes sooner and takes more I/O from the databases; a low one does the opposite.

Which number should I alert on?
USABLE_FILE_MB, and the date it reaches zero at the current growth, not a percentage of FREE_MB.

Sources

Oracle: ORA-15041
Oracle: V$ASM_DISKGROUP, V$ASM_DISK, Administering Disk Groups
Scops docs: Detector reference