ORA-15027: Active Use of Diskgroup Precludes Operation

ORA-15027: Active Use of Diskgroup “DG_NAME” Precludes Its Dismount

Error Overview

Error Text: ORA-15027: active use of diskgroup "DG_NAME" precludes its dismount

ORA-15027 is raised when an ASM operation (typically DISMOUNT DISKGROUP or DROP DISKGROUP) cannot proceed because one or more database instances or other clients are still actively using the diskgroup. ASM refuses to dismount to prevent in-flight I/O failures.

Common Causes

Database Instances Still Open

• Database has datafiles, controlfiles, or redo logs in the diskgroup
• One or more RAC instances still mounted with files on the diskgroup
• Pluggable database keeping files open

Background Processes

• Recovery slaves still active
• ARCn archiving to FRA in this diskgroup
• DBWR writing buffers
• LGWR active on redo members

External Clients

• Oracle GoldenGate trail files
• ACFS volumes mounted on filesystem
• Oracle Restart resources still registered

Stale Locks

• Crashed instance left lock metadata
• Failed RAC instance recovery incomplete

Diagnostic Steps

Identify Active Clients

-- Connect as SYSASM
sqlplus / as sysasm

-- List all clients connected to a diskgroup
SELECT c.instance_name, c.db_name, c.status, dg.name AS diskgroup
FROM v$asm_client c, v$asm_diskgroup dg
WHERE c.group_number = dg.group_number
AND dg.name = 'DATA';

-- Show file usage by client
SELECT c.instance_name, COUNT(*) AS open_files
FROM v$asm_client c
GROUP BY c.instance_name;

Check File Types in Diskgroup

-- File breakdown by type
SELECT type, COUNT(*) AS file_count,
       ROUND(SUM(bytes)/1024/1024/1024, 2) AS gb
FROM v$asm_file
WHERE group_number = (SELECT group_number FROM v$asm_diskgroup WHERE name = 'DATA')
GROUP BY type
ORDER BY gb DESC;

Cross-Reference Database Files

-- From RDBMS instance
SELECT 'DATAFILE' AS type, name FROM v$datafile WHERE name LIKE '+DATA%'
UNION ALL
SELECT 'TEMPFILE', name FROM v$tempfile WHERE name LIKE '+DATA%'
UNION ALL
SELECT 'CONTROLFILE', name FROM v$controlfile WHERE name LIKE '+DATA%'
UNION ALL
SELECT 'REDOLOG', member FROM v$logfile WHERE member LIKE '+DATA%';

Check Cluster Resources

# Diskgroup CRS resource and dependencies
crsctl stat res -t -w "TYPE = ora.diskgroup.type"

# Database resources using diskgroup
srvctl config database -d PROD | grep -i diskgroup

# ACFS mount points
srvctl status filesystem

Resolution Steps

1. Identify and Stop All Database Clients

# Stop all databases using the diskgroup
for db in $(srvctl config database); do
    DG_USE=$(srvctl config database -d $db | grep -i "Disk Groups")
    if echo "$DG_USE" | grep -q "DATA"; then
        srvctl stop database -d $db -stopoption immediate
    fi
done

# Stop ACFS filesystems
srvctl stop filesystem -device /dev/asm/myvol1-258

2. Dismount from Each ASM Instance

-- On each ASM instance in cluster
ALTER DISKGROUP data DISMOUNT;

-- For RAC, dismount on all instances
-- node1: ALTER DISKGROUP data DISMOUNT;
-- node2: ALTER DISKGROUP data DISMOUNT;

Or via srvctl:

srvctl stop diskgroup -diskgroup DATA -node "node1,node2"

3. Force Dismount (Last Resort)

If clients cannot be cleanly stopped, force dismount may be required. WARNING: This will cause I/O errors in active databases.

ALTER DISKGROUP data DISMOUNT FORCE;

Use only when:

• Database instances have already crashed
• Diskgroup has hardware errors and must be released
• Clients are stale/orphaned (not actively writing)

4. Move Files Off Diskgroup First

For permanent dismount/drop, relocate files first:

-- Move datafiles to another diskgroup
ALTER TABLESPACE users
  ADD DATAFILE '+DATA_NEW/PROD/users02.dbf' SIZE 10G;

ALTER DATABASE DATAFILE '+DATA/PROD/users01.dbf' OFFLINE;

-- Use RMAN BACKUP AS COPY to migrate
RMAN> BACKUP AS COPY DATABASE FORMAT '+DATA_NEW';
RMAN> SWITCH DATABASE TO COPY;

-- Move controlfiles
SHUTDOWN IMMEDIATE;
-- Update parameter file with new locations
ALTER SYSTEM SET control_files='+DATA_NEW/PROD/control01.ctl' SCOPE=SPFILE;
STARTUP MOUNT;
RMAN> RESTORE CONTROLFILE FROM '+DATA/PROD/control01.ctl';

-- Move redo logs
ALTER DATABASE ADD LOGFILE GROUP 4 ('+DATA_NEW/PROD/redo04.log') SIZE 100M;
ALTER DATABASE DROP LOGFILE GROUP 1;

5. Check for Stale Lock Cleanup

After crashed instance, lock cleanup may be needed:

-- Verify no orphaned client metadata
SELECT instance_name, db_name, status FROM v$asm_client;

-- Restart ASM to clear stale state (last resort)
srvctl stop asm -node node1 -force
srvctl start asm -node node1

Common Scenarios

Scenario 1: Cannot Dismount FRA

ALTER DISKGROUP fra DISMOUNT;
ORA-15027: active use of diskgroup "FRA" precludes its dismount

Fix: Database is archiving here. Set LOG_ARCHIVE_DEST_n to another location, archive current log, then dismount.

Scenario 2: Cannot Drop Old Diskgroup After Migration

DROP DISKGROUP old_data INCLUDING CONTENTS;
ORA-15027: active use of diskgroup "OLD_DATA" precludes its dismount

Fix: Verify all v$asm_client entries are stopped. Check v$asm_file for hidden files (ACFS, GG trails).

Scenario 3: ACFS Volume Active

ORA-15027: active use of diskgroup "ACFS_DG" precludes its dismount

Fix: Unmount filesystem first: umount /acfs_mount; srvctl stop filesystem -device /dev/asm/vol1-258

Sample Output

SQL> ALTER DISKGROUP fra DISMOUNT;
ALTER DISKGROUP fra DISMOUNT
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15027: active use of diskgroup "FRA" precludes its dismount

SQL> SELECT instance_name, db_name, status FROM v$asm_client
  2  WHERE group_number = (SELECT group_number FROM v$asm_diskgroup WHERE name='FRA');

INSTANCE_NAME    DB_NAME    STATUS
---------------- ---------- ------------
PROD1            PROD       CONNECTED
PROD2            PROD       CONNECTED

PROD database has files in FRA — must shut down or migrate before dismount.

Prevention Strategies

Pre-Maintenance Checklist

1. List all clients with SELECT * FROM v$asm_client
2. List all file types with SELECT type, COUNT(*) FROM v$asm_file GROUP BY type
3. Verify no scheduled jobs writing to diskgroup
4. Schedule dismount during maintenance window
5. Stop dependent ACFS filesystems explicitly

Documentation

• Keep a diskgroup → application mapping document
• Tag diskgroups by purpose (DATA, FRA, TEMP, REDO)
• Avoid mixing critical and non-critical files in same diskgroup

Use srvctl for Safe Operations

# srvctl handles dependencies automatically
srvctl stop diskgroup -diskgroup DATA -node node1

Related Errors

• ORA-15001: Diskgroup does not exist or is not mounted
• ORA-15032: Not all alterations performed
• ORA-15040: Diskgroup is incomplete
• ORA-15054: Disk in diskgroup does not exist
• ORA-15056: Additional error message

Troubleshooting Checklist

• List all clients via v$asm_client
• Inventory files via v$asm_file by type
• Check for ACFS filesystems on diskgroup
• Stop dependent databases first
• Stop ACFS filesystems before diskgroup dismount
• Use srvctl stop diskgroup for safe ordering
• Avoid DISMOUNT FORCE unless instances already down