ORA-15003: Diskgroup Already Mounted in Another Lock Name Space

ORA-15003: Diskgroup “diskgroup_name” Already Mounted in Another Lock Name Space

Error Overview

Error Text: ORA-15003: diskgroup "DGNAME" already mounted in another lock name space

ORA-15003 occurs when ASM detects that a diskgroup is registered under a different cluster lock name space than the one the current instance belongs to. The error commonly surfaces during diskgroup creation, mount operations, or after cluster reconfiguration when ASM metadata still references a prior cluster identity.

Common Causes

Cluster Lock Name Space Conflicts

• Diskgroup created on a different cluster previously
• ASM disk header still references an old cluster GUID
• Single-instance ASM and clustered ASM trying to access same disks
• Mismatched cluster_database setting between instance and disks

Restored or Cloned Storage

• Disks restored from another environment (test → production cross-mount)
• SAN snapshots reattached without header reset
• Storage migration from one cluster to another
• Failed cluster rebuild leaving stale ASM headers

Configuration Drift

• ASM instance running standalone after cluster removal
• GI Home reinstalled without clearing ASM disks
• Mismatch between OCR/voting disk cluster name and ASM disks

Diagnostic Steps

Identify Conflicting Diskgroup

-- Connect as SYSASM
sqlplus / as sysasm

-- Check diskgroup state
SELECT name, state, type, total_mb, free_mb
FROM v$asm_diskgroup;

-- Look at disk header info
SELECT name, path, header_status, mount_status, mode_status,
       label, group_number
FROM v$asm_disk
WHERE path LIKE '%/dev/oracleasm/disks%';

Inspect Disk Headers with kfed

# Read ASM disk header for cluster info
kfed read /dev/oracleasm/disks/DISK1 | grep -E "kfdhdb.grpname|kfdhdb.dskname|kfdhdb.fgname|kfdhdb.driver"

# Check cluster lock name space
kfed read /dev/oracleasm/disks/DISK1 | grep -E "kfbh.endian|kfdhdb.compat"

# Compare against expected cluster
crsctl query css clustername
crsctl get cluster name

Verify Cluster Registration

# Check if running in cluster mode
srvctl config asm

# Check ASM instance type
ps -ef | grep asm_pmon

# Verify CRS state
crsctl stat res -t -init | grep -i asm

Resolution Steps

1. Diskgroup Created on Different Cluster

If the diskgroup belongs to another cluster’s namespace, mount it forcibly only after confirming no other cluster is using it:

-- Force mount with namespace override (DESTRUCTIVE if other cluster active)
ALTER DISKGROUP data MOUNT FORCE;

WARNING: Force mounting a diskgroup that is actively mounted on another cluster will cause corruption.

2. Reset Disk Headers After Migration

If migrating disks between environments and the source cluster is decommissioned:

# Backup disk headers first
for disk in /dev/oracleasm/disks/DISK*; do
    dd if=$disk of=/backup/$(basename $disk).hdr bs=4M count=1
done

# Use renamedg to update cluster registration without losing data
renamedg dgname=DATA newdgname=DATA \
    asm_diskstring='/dev/oracleasm/disks/*' \
    verbose=true \
    phase=both

3. Clear Stale Headers (Empty Disks)

For disks confirmed empty or reusable:

# Clear ASM header (DESTROYS DATA)
dd if=/dev/zero of=/dev/oracleasm/disks/DISK1 bs=4M count=10

# Recreate ASM disk
oracleasm createdisk DISK1 /dev/sdb1
oracleasm scandisks

4. Cluster Name Mismatch Fix

If cluster_database parameter doesn’t match disk metadata:

-- For RAC ASM
ALTER SYSTEM SET cluster_database=TRUE SCOPE=SPFILE SID='*';

-- For single-instance ASM (Oracle Restart)
ALTER SYSTEM SET cluster_database=FALSE SCOPE=SPFILE;

Restart the ASM instance after parameter change.

Prevention Strategies

Document Cluster Identity

• Maintain a registry of which cluster owns which disks
• Tag SAN LUNs with cluster name in storage metadata
• Use ASM disk labels that include cluster identifier

Pre-Migration Checklist

• Confirm source cluster has dismounted the diskgroup
• Backup disk headers before any migration
• Use renamedg rather than recreate when possible
• Document asm_diskstring and disk paths

Post-Cluster-Rebuild

• Run oracleasm scandisks after GI reinstall
• Verify diskgroup state in v$asm_diskgroup before adding new disks
• Check header_status in v$asm_disk for FOREIGN or CONFLICT entries

Sample Diagnostic Output

SQL> ALTER DISKGROUP data MOUNT;
ALTER DISKGROUP data MOUNT
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15003: diskgroup "DATA" already mounted in another lock name space

SQL> SELECT path, header_status, mode_status, mount_status
  2  FROM v$asm_disk WHERE name LIKE 'DATA%';

PATH                          HEADER_STATU MODE_STAT MOUNT_S
----------------------------- ------------ --------- -------
/dev/oracleasm/disks/DISK1    FOREIGN      ONLINE    CLOSED
/dev/oracleasm/disks/DISK2    FOREIGN      ONLINE    CLOSED

HEADER_STATUS = FOREIGN confirms the disks belong to another ASM cluster.

Related Errors

• ORA-15001: Diskgroup does not exist or is not mounted
• ORA-15017: Diskgroup cannot be mounted
• ORA-15032: Not all alterations performed
• ORA-15042: ASM disk is missing
• ORA-15077: Cannot locate ASM instance

Troubleshooting Checklist

• Confirm cluster name matches disk header
• Verify no other cluster has the diskgroup mounted
• Backup disk headers before any reset
• Use renamedg for legitimate cluster migrations
• Validate cluster_database parameter matches environment
• Check header_status in v$asm_disk for FOREIGN entries