Errors like ASM metadata corruption can instantly put a DBA on high alert. When Oracle Automatic Storage Management (ASM) detects inconsistencies, it may forcibly dismount a diskgroup to protect data integrity. One such real-world incident involved the following critical errors:
ORA-15130: diskgroup "ARCH" is being dismounted
ORA-15335: ASM metadata corruption detected in disk group 'ARCH'
ORA-15066: offlining disk "ARCH_0002" in group "ARCH" may result in a data loss
In this article, we’ll break down what these errors mean, why ASM dismounted the diskgroup, and how the ARCH diskgroup was safely mounted back without data loss—using actual commands and outputs from an Oracle 12c system.
Understanding the ORA-15335 Error
The error ORA-15335 indicates that ASM detected metadata corruption inside a diskgroup. ASM metadata includes:
- Disk headers
- Allocation tables
- Extent maps
- Diskgroup configuration data
When ASM cannot reliably read this metadata, it takes a protective action—dismounting the diskgroup automatically.
Why This Is Serious
Metadata corruption is more dangerous than a single disk failure because it affects ASM’s ability to understand disk layout. This is why ORA-15335 is often accompanied by:
- ORA-15130 – Diskgroup being dismounted
- ORA-15066 – Disk offlining may cause data loss
Initial Symptom: Diskgroup ARCH Dismounted
The alert log showed ASM dismounting the ARCH diskgroup after detecting corruption on disk ARCH_0002.
Before recovery, checking ASM disk status showed all disks present at OS level:
SELECT name, state, path FROM V$ASM_DISK;
Result (excerpt):
ARCH_0002 NORMAL /dev/mapper/arch03
ARCH_0001 NORMAL /dev/mapper/arch02
ARCH_0000 NORMAL /dev/mapper/arch
✔️ All disks were NORMAL
✔️ No missing or FORMER disks
✔️ No OS-level device failure
This was a critical observation—it suggested the corruption was logical, not physical.
Step 1: Connect as SYSASM (Correct Way)
ASM operations must always be performed using the SYSASM privilege.
sqlplus "/as sysasm"
Output confirmed:
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0
With the Automatic Storage Management option
Step 2: Mount the Diskgroup Manually
Since:
- All disks were visible
- No disk was marked OFFLINE or MISSING
- Redundancy was intact
We attempted a manual mount:
ALTER DISKGROUP arch MOUNT;
Result:
Diskgroup altered.
✅ ASM successfully mounted the diskgroup
✅ No force or repair options required
✅ No data loss occurred
This confirms that ASM metadata inconsistency was temporary or transient.
Step 3: Validate Diskgroup Health
After mounting, we revalidated disk visibility:
SELECT name, state, path FROM V$ASM_DISK;
Final Result:
16 rows selected.
All disks in NORMAL state
No disks were offline, no rebalance pending, and no additional errors appeared in the alert log.
Why This Recovery Worked
This incident resolved cleanly because:
✔ ASM redundancy protected metadata
✔ No physical disk failure existed
✔ Devices were stable at OS level
✔ ASM could re-read metadata after remount
In many cases, ASM dismounts a diskgroup out of caution, not because data is unrecoverable.
When You Should NOT Just Remount
Do not blindly mount a diskgroup if:
- Disks show
MISSINGorFORMER - OS paths are unavailable
- Repeated ORA-15335 errors occur
- Diskgroup is EXTERNAL redundancy
- Alert log shows checksum failures repeatedly
In such cases, you must:
- Check OS logs (
dmesg, multipath) - Validate ASM disk headers
- Consider restoring from backup
Best Practices to Prevent ASM Metadata Corruption
1. Stable Multipath Configuration
Ensure /dev/mapper devices do not change names across reboots.
2. Regular ASM Health Checks
Monitor:
V$ASM_DISKV$ASM_DISKGROUP- ASM alert log
3. Avoid Force Operations
Never use:
ALTER DISKGROUP FORCE MOUNT;
unless Oracle Support advises it.
4. Backup ASM Metadata
Use RMAN and ensure control file and ASM-backed files are protected.
Final Thoughts
ORA-15335 does not always mean disaster.
In this real-world Oracle 12c scenario, a calm, methodical approach avoided unnecessary disk offlining and data loss.
If you see:
“ASM metadata corruption detected”
Your first steps should always be:
- Verify disk visibility
- Check disk states
- Mount manually as SYSASM
- Monitor the alert log closely
ASM is designed to protect your data—even if that means temporarily stopping access.
About the Platform
This issue and recovery were performed on Oracle Database 12c with Automatic Storage Management (ASM).
