Oracle报错|磁盘组故障 ORA-15035:no disks belong to diskgroup string”故障修复与远程处理

🚨 Oracle磁盘组故障：ORA-15035报错急救指南 🛠️

场景还原：
凌晨3点，你正睡得香甜，突然手机疯狂震动——Zabbix告警炸了！📱💥 屏幕上刺眼的红色提示："ORA-15035: no disks belong to diskgroup 'DATA'"，客户的核心业务数据库ASM磁盘组突然离线，交易系统全面瘫痪... 别慌！这份实战指南能让你远程快速止血！

🔍 故障现象速诊

SQL> select name,state from v$asm_diskgroup;
NAME       STATE
---------- ----------
DATA       DISMOUNTED  -- 目标磁盘组已卸载

报错核心提示：
ORA-15035: 磁盘组"DATA"没有可用磁盘
（翻译：Oracle找不到这个磁盘组对应的物理磁盘了😱）

🧐 根本原因排查

常见元凶TOP3

1️⃣ 磁盘路径变更：服务器重启后，/dev/mapper/路径下的磁盘名变了
2️⃣ 权限问题：grid用户突然失去磁盘读写权限（比如误操作chmod）
3️⃣ 硬件故障：存储阵列掉盘或HBA卡异常（最头疼的情况💔）

🚑 远程修复五步法

步骤1：确认磁盘物理状态

# 以grid用户登录服务器
$ ls -l /dev/mapper/* | grep asm  # 检查磁盘设备是否存在
$ asmcmd lsdsk --discovery  # 强制重新扫描磁盘

👉 预期结果：应看到类似/dev/mapper/data01的ASM磁盘条目

步骤2：检查磁盘头状态

SQL> select path,header_status from v$asm_disk;

🚨 危险信号：

• MEMBER → 正常
• FORMER → 磁盘被强制踢出过
• CANDIDATE → 未初始化的新磁盘

步骤3：手动挂载磁盘组（谨慎操作！）

SQL> alter diskgroup DATA mount;  -- 尝试普通挂载
-- 若失败则强制挂载（可能需牺牲数据一致性）
SQL> alter diskgroup DATA mount force;

步骤4：权限修复（经典坑位！）

# 确保grid用户有权限
$ chown grid:asmadmin /dev/mapper/data*
$ chmod 660 /dev/mapper/data*

步骤5：终极方案 - 重建磁盘组

如果磁盘物理存在但Oracle仍不识别：

SQL> create diskgroup DATA NORMAL REDUNDANCY
     disk '/dev/mapper/data01','/dev/mapper/data02'
     attribute 'compatible.asm'='19.0';

💡 注意：此操作会清空原有数据！需提前确认有备份！

💡 预防性建议

1. 设备命名固化：在/etc/udev/rules.d/下配置永久磁盘别名
2. 监控强化：对v$asm_diskgroup的STATE列设置实时监控
3. 定期演练：每季度模拟磁盘故障进行恢复测试

📚 技术背景延伸

根据Oracle 19c官方文档（2025-07版），ORA-15035通常发生在：

• ASM实例参数asm_diskstring未正确包含磁盘路径
• 多路径软件配置变更后未更新Oracle配置
• 存储阵列LUN被意外卸载

最后叮嘱：遇到生产环境ASM故障时，先联系存储团队确认硬件状态！盲目操作可能导致数据二次损坏，保持冷静，你一定能搞定！ 💪

（凌晨4点30分，磁盘组终于MOUNTED，系统恢复运转... 可以喝杯咖啡等日出了 ☕🌄）