5.5TB 数据命悬一线：一次 Oracle ASM 异常盘的“保命”实战复盘

凌晨，电话响起。

后端反馈：数据库连接异常，应用大面积报错。

我登录后台，dmesg 日志里密密麻麻的 DID_NO_CONNECT 和 multipath failing path 像是在无声地宣告着：集群正在崩溃。

对于 Oracle 数据库管理员来说，没什么比"5.5TB 数据在不可靠的存储链路和异常 ASM 盘上裸奔"更让人绝望。

很多 DBA 在这种时候，第一反应是去查 SQL，或者尝试 expdp 导出，甚至盲目执行 drop disk 试图触发 Rebalance。

但在那个瞬间，任何一个错误的"想当然"，都可能让 5.5TB 数据彻底化为乌有。

这不是一篇单纯的技术笔记，这是一份记录在生死边缘，如何依靠冷静判断和"拒绝盲操"，把数据从毁灭中抢回来的实战复盘。

如果你的环境里也跑着 Oracle RAC，请务必读完这篇文章，这可能是你应对极端事故时的最后一道"急救手册"。

环境说明

Oracle 11g RAC，双节点
ASM Normal Redundancy
后端 SAN 存储，multipath 多路径接入

从一个 ORA-01115 开始

报警进来的时候，业务侧是正常的数据库 I/O 报错，不算罕见：

复制代码

ORA-01115: I/O error reading block
ORA-15081: failed to submit I/O

这两个错误本身不稀奇，但我的习惯是------看到 I/O 报错，第一件事不是去翻 AWR、不是去查哪条 SQL 跑慢了，而是直接下沉到 OS 层。

数据库在这个位置只是个报警器，真正的问题在下面。

果然，dmesg 和 multipath 日志里已经很热闹了：

复制代码

rejecting I/O to offline device
FAILED Result: hostbyte=DID_NO_CONNECT
device-mapper: multipath: Failing path
LUN assignments have changed

DID_NO_CONNECT 说明主机到存储目标的连接出了问题；Failing path 说明多路径的故障切换没有正常接管；LUN assignments have changed 是最让人警觉的一条------LUN 呈现或映射发生了变化，设备号可能已经不稳定。

没过几分钟，RAC 发生了 eviction。

一个节点被踢出集群，VIP 漂移，系统降级到单节点运行。这在共享存储 I/O 长时间卡顿的时候不少见，集群为了防脑裂会做这个判定。

但问题是，剩下的单节点还在接业务，还在持续写入。

这个时候我的判断是：风险不是"会不会出问题"，而是"什么时候扩大"。

ASM 侧的信号：盘在线，

但读不稳

去 ASM 里查了一下磁盘状态：

复制代码

select name, state, mode_status, mount_status, header_status
from v$asm_disk;

问题盘出现了这个组合：

复制代码

STATE         = NORMAL
MODE_STATUS   = ONLINE
HEADER_STATUS = UNKNOWN

ONLINE 这个状态很容易让人放松警惕，觉得"盘还在线，先观察一下"。

但 HEADER_STATUS=UNKNOWN 是个危险信号------ASM 无法稳定读取这块盘的头部元数据，它只是在名义上还挂着，实际可读性已经存疑。

这个时候还不能直接定性成"物理坏道"，因为 UNKNOWN 的原因可能是路径抖动、I/O 超时、设备重新呈现等等。

所以我同步拉了存储侧的日志，把时间线对上------存储后端确实存在介质类异常，告警时间和主机侧的 I/O 报错完全吻合。

到这里根因基本清楚了：后端介质风险叠加链路不稳，主机侧 I/O 既提交不进去，也读不出来。

第一个关键判断：别赌"还能跑"

系统这时候还能用，主要是因为 Normal Redundancy 还能从镜像副本读到数据。

但我不打算赌它能撑多久，原因很简单：单节点持续写入，每次写都在踩新的地址空间，谁也不知道下一次写会不会踩到更坏的位置。

一旦某个 extent 的两份副本都出了问题，磁盘组就可能直接挂掉，到那时候什么都来不及了。

所以策略从"维持运行"改成"止血"：能少写就少写，先把能读到的数据尽快固化出来。

为什么不直接 drop disk

当时有人提了一个听起来很合理的方案：把问题盘 drop 掉，让 ASM 自己 rebalance，数据就搬走了。

我没同意，原因是：drop disk 会触发 rebalance，rebalance 会产生大量的读写和 extent 扫描。

在路径已经不稳定的情况下，这相当于主动拉高 I/O 压力。

如果中途再抖一下，rebalance 可能反复卡住、反复失败，甚至把磁盘组整个拖垮。

不是说 drop disk 永远不能做，而是在没摸清可读范围、没确认稳定性之前，不能先做这种会强制扩大 I/O 面的操作。

为什么不用 expdp 先导一份出来

另一个方案是先跑 expdp，逻辑导出一份数据备用。

这个思路也不对，至少不适合作为第一步。

expdp 需要做大量逻辑读，大表、LOB、全表扫描都要走一遍。

底层 I/O 已经在报错的情况下跑这个，中途遇到一次 I/O error 整个任务就失败了，时间窗口白白消耗在重跑上，I/O 压力也没减下来。

这个阶段的目标只有一个：把可读数据先固化下来，不能让二次波动把剩下的窗口期吃掉。

救援的实际做法：基于 ASM 结构

做块级固化

核心思路说起来不复杂：

先搞清楚数据的 extent 分布和镜像副本的位置，找到健康的读取路径；
优先从健康副本读，把能完整读到的数据落地；
遇到坏块或超时就绕开，不为了"完美读取"把整个过程拖死；
整个过程尽量保持只读验证加最小干预，不在这个阶段做任何在线写修复。

过程中结合 kfed 做了只读核验，确认磁盘头、AU 和元数据的状态，划清可读性的边界。

这一步更像是"抢救"而不是"导出"。

5.5T 的数据，目标是在盘还能读的窗口期内尽量完整地固化出来。

第二阶段：重建，不是缝缝补补

数据固化完成之后，没有走"修复原有磁盘组"的路，而是选择彻底重建：

废弃原有风险磁盘组，存储侧替换后端物理盘并重新呈现 LUN，重新规划 failure group（原来的规划有问题，冗余副本落在了同一风险域），重建 ASM diskgroup，然后做数据回迁。

回迁过程包括：重建表结构、导入数据、重建索引、恢复统计信息，最后逐表做核心数据的对账校验。

整个过程断断续续跑了几十个小时，最终结果：5.5T 数据完整恢复，RAC 双节点恢复正常，冗余结构重新可靠。

几点事后的判断

I/O 报错要第一优先级处理。

当你同时看到 ORA-01115、ORA-15081、DID_NO_CONNECT、rejecting I/O、multipath failing path，不要先去查 SQL，先查磁盘和路径。

数据库报的错是症状，问题在下面。

Normal Redundancy 不是保险。

它只能容忍单点盘故障，解决不了路径长期抖动、介质不可恢复读、failure group 规划不合理这些问题。

镜像能延缓问题暴露，但不会消除风险本身。

这次如果 failure group 规划合理，两份副本不在同一风险域，处理起来会从容得多。

"还能用"是最危险的状态。

系统没宕机，不代表安全。

单节点加异常盘加持续写入，这个组合是真正的高风险。

没宕机只是意味着窗口期还在，但窗口期是在缩短的。

从"还能用"到"救不回来"，有时候只差一次 I/O 抖动。

这类问题，别等到倒计时结束

才找人

这次 5.5T 的数据能完整救回来，很大程度上是因为判断足够快、第一步没走错。

但现实里，我们接到的很多求助电话，往往已经是"系统宕了好几个小时"或者"自己试着恢复反而越来越糟"的状态。

如果你遇到以下场景，建议第一时间联系我们的专业团队介入，而不是自己摸索：

ASM 磁盘组挂载失败，mount_status 异常，实例无法正常启动
RAC eviction 后单节点无法拉起，或双节点连续崩溃
ORA-600 / ORA-7445 内部错误反复出现，数据库不稳定
数据文件头损坏、控制文件丢失，常规恢复手段失效
误删表、误 truncate、误 drop，归档不完整或没有 RMAN 备份
存储侧 LUN 异常、多路径全部 fail，数据库 I/O 完全中断
ASM 元数据损坏，kfed 读取异常，磁盘组无法识别
跨版本迁移或 P2V 之后数据库起不来，块格式或字节序不一致

这些场景的共同特点是：窗口期有限，操作顺序错一步就可能让数据不可逆。

自己试的每一个动作，都可能在缩短本来就不多的时间。

写在最后

回过头看，这次数据抢救之所以能成功，核心不在于我们用了什么冷门参数，而在于我们守住了"不扩大故障面"的底线。

在数字化时代，5.5TB 的数据背后是企业的命脉。

我们之所以公开发布这篇文章，不是为了炫技，而是为了警示：当系统还没宕机时，往往才是最危险的时候。

安呀智数据坊，专注解决疑难数据库与存储链路故障。

如果你在工作中遇到这些"心跳停止"的瞬间，请记住，盲目的尝试往往比故障本身更可怕：

ASM 磁盘组挂载失败，kfed 读取报错？
RAC 集群频繁 Eviction，单节点无法拉起？
存储链路异常，IO 长时间卡死？

如果你的数据窗口期有限，请第一时间联系我们。

相比于事后修复，我们更希望能在"窗口期"彻底关闭之前，为你拦截掉那些可能导致数据不可逆的错误动作。

关注【安呀智数据坊】，转发这篇复盘给你的 DBA 同事。

哪怕这篇文章能救回哪怕一次意外，所有的辛苦记录都是值得的。

作者介绍

大家好，我是刘峰，安丫科技创始人 & 数据库技术高级讲师，专注于 PostgreSQL、国产数据库运维与迁移、数据库性能优化 等方向。

作为 PG中国分会官方授权讲师、PostgreSQL ACE 讲师认证专家，我长期活跃在****一线项目实战 中，拥有 10年以上大型数据库管理与优化经验，曾深度参与电信、金融、政务等多个行业的数据库性能调优与迁移项目。

欢迎关注我，一起深入探索数据库的无限可能，技术交流不设限！

📌 觉得有收获的话，记得点赞、收藏、转发支持一下哦，别忘了关注我获取更多数据库干货~

安呀智数据坊｜我们能做什么

无论你是业务系统的技术负责人，还是数据部门的第一响应人，我们都能为你提供可靠的支持：

数据库类型支持

Oracle / MySQL / PostgreSQL / SQL Server 等主流数据库

核心服务内容

性能优化 / 故障处理 / 数据迁移 / 备份恢复 / 版本升级 / 补丁管理

系统性支持

深度巡检 / 高可用架构设计 / 应用层兼容评估 / 运维工具集成

专项能力补充

定制课程培训 / 甲方团队辅导 / 复杂问题协作排查 / 紧急救援支持

📮 如果你有一张删不掉的表、一个跑不动的查询，或者一场说不清的升级风险，欢迎来找我们聊聊。