ORA-15131报错磁盘组文件块读不了，远程帮忙修复故障经验分享

关于ORA-15131报错，也就是磁盘组文件块读不了的故障，我分享一次真实的远程帮忙处理经历，那次是客户一个挺重要的系统，突然应用报连接失败，他们自己查数据库日志，看到了这个ORA-15131错误，后面还跟着一个具体的文件号和块号，说无法读取，客户自己的运维人员有点慌，因为涉及到存储，怕数据丢了,就紧急联系了我们远程支持。

我让他们别急着重启任何东西，第一步，不是直接去碰数据库，而是让他们把最近的数据库告警日志（alert log）和ASM实例的告警日志完整地发过来，也让他们到操作系统层面，用他们自己的命令（因为他们是Linux系统，我让他们用dmesg和/var/log/messages）看看有没有硬件或者磁盘相关的报错，这是为了从整体上判断问题是出在数据库软件层，还是更底层的操作系统或存储硬件。（来源：基于Oracle MOS文档“Troubleshooting ORA-15131”的基本排查思路,并结合实际运维经验）

看日志发现，ASM日志里确实有那个磁盘组（比如叫DATA）的某个磁盘（他们用的是裸设备，类似/dev/raw/raw1这样的路径）有I/O超时的记录，而且反复出现，操作系统的dmesg里也看到了对应那块磁盘的SCSI错误，I/O error, dev sdb, sector xxxxx”这类信息，这就基本把问题范围缩小了，不是数据库表坏了，而是存储访问路径出了问题，很可能是某块物理磁盘不稳定或者存储链路（比如HBA卡、光纤线）有闪断。

我指导他们分头操作，一边让数据库人员登录到ASM实例，用asmcmd工具运行lsdg看看所有磁盘组的状态，特别是那个报错的磁盘组，确认是不是有磁盘显示为“OFFLINE”或者“PROVISIONED”等异常状态，另一边，让系统管理员联系存储管理员，一起检查存储阵列的健康状态，远程协作的关键就在这里，信息要同步，很快，存储那边反馈说，阵列日志显示对应那块物理硬盘确实有介质错误预警，但还没完全掉线,阵列正在尝试修复和重映射坏块。

这时候，情况比较明确了：一块磁盘正在“挣扎”，导致数据库读它上面的数据块时超时，抛出ORA-15131，由于磁盘组有冗余（他们用的是NORMAL冗余，相当于有镜像），数据本身没有丢失风险,但性能和应用访问已经受影响。

修复方案就清晰了，我们决定由存储管理员在阵列管理软件里，将那块预警的物理硬盘直接标记为失败并热拔掉更换，在更换过程中，我让数据库人员在ASM实例里监控，看到对应的ASM磁盘果然变成了“OFFLINE”，但因为有镜像，数据库依然能运行，只是性能略有下降，等存储管理员换上新盘，并完成阵列层面的重建和上线后，我指导数据库人员在ASM实例里，使用alter diskgroup DATA online disk ‘你的磁盘名’这样的命令，将那块ASM磁盘重新上线，ASM会自动从镜像盘上同步数据到这块新盘上，同步期间，磁盘组状态会显示“REBALANCING”,这是正常的。

整个同步过程花了几个小时，期间数据库一直可用，同步完成后，所有错误消失，我们让大家一起再全面检查一遍数据库、ASM和操作系统的日志，确认没有其他遗留报错,并且应用连接完全恢复正常。

这次远程修复给我的核心经验是：第一，遇到ORA-15131别只盯着数据库，它更像一个“症状”，病根多半在存储，第二，日志是关键，数据库告警日志、ASM日志、操作系统日志三件套要一起看，像破案一样找线索，第三，远程处理这种涉及多部门（数据库、系统、存储）的问题，沟通和实时信息共享比技术操作本身更重要，要当好这个“协调中心”和“翻译”，把数据库错误翻译成存储能听懂的语言，反过来也是，第四，如果磁盘组有冗余，心里会踏实很多，修复起来可以从容不迫，优先保证业务不停；如果没有冗余，那压力就大得多了，每一步都要更谨慎。（来源：本次实际故障处理过程的总结与反思）