看到这个标题，相信不少朋友有类似的感慨：

是呀，变更（前）不重启，就是害自己！前人挖坑，后人踩 ！

相信不少朋友有过类似残酷经历，做了一个变更，重启之后，出问题了 ！

到底是本次变更导致还是以前留下的深坑呢 ?   查不清的只能默默地背锅了 …

小 y 的建议是：

“  

         理想情况下，条件允许，做变更前，先重启一下，验证正常才开始变更。 但是，这也只是一个理想情况而已。

很多时候，我们可以做到系统上线前来一次重启操作系统，但是又有多少人可以做到变更前、变更后都重启一下呢？太难了，不是每个变更都有重启的机会的 .. 也是无奈啊！

”

今天小 y 和大家分享的就是这样一个，重启操作系统后出现数据库出现大量坏块的案例。

      问题  来了      

电话响了 …

前同事的同事，前ITPUB的资深版主，所在单位出了个比较大的故障。 Q： “小 y 快 救急, 数据库掉电重启后出现大量坏块， 数据库无法open, 没有备份 ，你帮看看呗…客户自己的判断是：掉电重启把system表空间1号数据文件的文件头写乱了，你可以参考下 ...”  小y ：  “ 好的，你把他联系方式发给我吧！等我消息 ”

这个世界真是奇妙，两个不认识的陌生人之间，中间居然只隔着三个熟人！ 正在家里补觉的我，一听到有故障，顿时精神起来！ 赶紧爬起床，洗了个脸，准备投入战斗； 加了 QQ， 对方发过来一张图片。

数据库在startup命令发出后，到了open阶段，报错如下 ：

可以看到 ：

数据库在open的过程中，发现1号文件/oracle/oradata/ora_system01.dbf出现了 datafile header ismedia corrupt ,即文件头介质损坏。看到这里，有同学想要猜一下原因：

是不是底层磁盘损坏无法访问了啊 …

 

答案是No!

如果是底层磁盘损坏无法访问 , 则会在 OS 层报 IO 相关的错误，这里没有，显然不是这个问题，退一步讲，即使是这个问题，但是当前在 没有rman和逻辑备份的情况下，接下来如果是你，怎么处理？

 

……

……

……

什么时候往下翻，由你决定…

……

……

……

……

……

……

        开启 分析   之旅      

1 、 查看alert日志

“出现文件头损坏， alert 日志会记录更详细的信息，你贴下 alert 日志的报错吧”

可以看到：

1)         System 表空间的 1 号数据文件 1 号 BLOCK ，报了坏块， Corrupt block, 原因是 Bad header

2)         重读数据文件头，依然是损坏

3)         对于该 block, 计算出来的 checksum 是 ，因此基本可以排除掉 IO 丢失 (lost write) 导致的损坏。

 

接下来如果是你，不妨思考一下，你会怎么处理？

……

……

什么时候往下翻，由你决定…

……

……

……

……

……

……

……

……

……

2 、 第一次头脑风暴

对于该block,计算出来的checksum是0，因此基本可以排除掉IO丢失导致的损坏。 Oracle 发现该数据文件头损坏，原因是 bad header, 这时会将 block header 的内容打印出来，如下图所示 ：

到底是哪里出了问题，导致 ORACLE 判断是 1 号文件 1 号块是 bad header 呢？ 最简单的方式，我们把 header 的内容挨个对一下 。

1 ） 这里 type=11 format=2 是典型的数据文件头的类型和格式，没有问题 2 ） 而 rdba:0x00800001 ， rdba 记录了这个 BLOCK 的地址，即属于哪个文件哪个 BLOCK 。

是不是这里出了问题呢？（如果不是，则继续把 block header 的内容继续检查下去）

 

因此，小 y 首先检查一下 rdba:0x00800001， 看看 block 内记录的数据块地址是不是文件 1 、 BLOCK1。 方法很简单，将 0x00800001 转为 10 进制，再用 dbms_utility 转为文件号块号即可。

 

过程如下图所示：

这一转，坏块的问题就立刻显现了！

Open 数据库时，按照控制文件中记录的 1 号文件的名字，访问 1 号 BLOCK 的时候，解析 BLOCK 的格式，其中 4-7 字节存的数据块地址

翻译过来，却发现是 2 号文件 1 号块！而不是 1 号文件 1 号块！因此，数据库报了坏块！

3 、 科普一下--了解下数据块的格式

下图为一个数据库块的格式的简单示意图

其中，BLOCK的4到7字节（总计4个字节）是rdba，记录着这个数据块的地址，即属于哪个文件哪个BLOCK。在open数据库的过程中，Oracle开始读取

1 号文件 1 号块， 1 号文件 2 号块 …

但是当读到 1 号文件 1 号块后，校验块的格式时， 发现第 4 到第 7 个字节的 RDBA 其实是 2 号文件 1 号块！ 因此，不可避免的报坏块，而数据库无法启动。

一句话概况为：

“我要的是 1 号文件 1 号块，但是你给我的块里的内容是 2 号文件 1 号块，！

所以是 bad header, 坏块！”

这是什么情况？

难道是掉电重启出现了卷管理 misplace 的问题？所谓 misplace, 就是上层应用（数据库）不关心底下的存储摆放，由卷管理帮忙维护和管理，但是如果 block 放错了位置，则可能出现这样“这里应该存放这个内容，但实际不是这个内容”的情况，也就是 misplace 的一种情况。

 

知道这个，又能如何呢？

接下来如果是你，不妨思考一下，你会怎么处理？

……

……

什么 时候往下翻，由你决定 …

……

……

……

……

……

……

……

……

……

4 、 接下来应该做什么？

也许接下来，有些同学开始支招了：

1、可否设置_ALLOW_RESETLOGS_CORRUPTION、_corrupted_rollback_segments、ORADEBUG推进SCN、10231跳过坏块等方式强行将库打开再导出重建呢?

 

答案是 NO ！这里文件头坏块，这样的方式不可行。

 

2、可否bbed修改rdba地址和其他BLOCK的内容为正确的内容呢…

 

答案也是 NO ！继续往下看，你就会明白为什么不可以。

 

这也不行，那也不行，那可怎么办是好！

 

正确的姿势应该是 :

1 ）采用 DBV 校验下所有文件，确认有多少损坏

2 ）判断损坏的原因

3 ）然后接下来再采取对应的解决方案。

 

“你dbv校验过所有数据文件么？情况如何，坏的多么？”我问道。 “dbv结果显示，只有1号文件是坏块的，并且是大量损坏，报错和之前类似，都是bad headr所以我怀疑是卷管理把文件写乱了！”

 

无奈？知道有多少损坏又如何？还是无能为力？ 如果是你，接下来你会怎么选择 ？

5 、 客户的选择—最后的希望破灭了

在联系到小 y 之前，客户这边由于无法查到原因，数据库又无法打开，且无可用的备份； 时间紧急，所以客户已经使用 DUL 数据抽取软件对数据文件进行直接抽取了 ，不过不幸的是，遇到了下图的一堆错误； 在 DUL 直接抽数的路也行不通后，这才多方联系到中亦 。

“ 小 y, 这个错误到底是什么意思呢 ” ( 当小 y 看到这张图的时候，脸上浮现一丝诡异的笑 …)

 

“ 这个错误很简单， wrong dba, 不是指错误的数据库管理员，而是错误的数据块地址 Data Block Address ，以最后一条记录为例 ”

“当他抽取 file#1,block# 46502 2这个BLOCK的数据时，检查BLOCK内的rdba,发现翻译出来是file#2, block# 465022,是文件2，不是文件1”

因此是错误的数据块地址，故跳过不抽取。 这里不难看出，块号是一样的！只是文件号从 1 都变成了文件 2 ！

6 、 不妨来一个大胆的猜想 ！

看到这里，估计不少朋友，开始有点感觉了，想要一试身手。

是不是 1 号文件文件名没变，但是内容被 2 号文件覆盖了啊？ 例如 cp 覆盖就有这样的效果！

 

说的没错！但是没有人会 cp ，这点从历史命令和沟通可以确认。

这个问题的本质就是：

ORACLE 认为 ora_system01.dbf 是 1 号文件（控制文件里记录），但是访问到该文件的时候，实际上文件里的内容都是 2 号文件的内容，这就是为什么块号全部一样，但是文件号全部从 1 变为 2 的原因了！

但是什么情况下出现的这个情况呢 ？

实际上，当小 y 第一眼看到 DUL 的这个错误的时候，我就已经猜到了原因，尽管我从来没有遇到过这个问题，确切说，在 10 年前，喜欢思考的我，就猜到了未来我一定会遇到这个问题。只不过，我等这个问题，等了 10 年 …

如果是你，不妨思考一下，你会怎么处理？

……

……

什么时候往下翻，由你决 定…

……

……

……

……

……

……

……

……

……

……

7 、 真相大白，so easy!

1 ） 首先，我们看看报错的 1 号文件

可以看到，名字上虽然是文件系统 , 但实际上是一个裸设备

2 ） 检查裸设备和块设备的对应关系

可以看到，system表空间1号文件对应的裸设备，是对主设备号为253、次设备号为5的块设备进行绑定的。

3） 检查主设备号为253、次设备号为5的原始块设备信息

可以看到，真相出现了： 253:5，实际上对应的是ora_sysaux01.dbf,而不是我们所期望的system01.dbf ！ 而sysaux01.dbf实际上是对应2号数据文件, 而不是1号文件 ！

4） 检查1号文件对应的块设备信息

可以看到： Ora_system01.dbf对应的块设备是253:4

8 、 被误会的重启

Linux上，如果使用裸设备做为数据文件，则需要通过raw命令实现块设备到裸设备的绑定。 但是raw命令是当前生效，重启后会丢失，为了避免重启后裸设备绑定丢失，需要在规则文件中配置，在重启操作系统的时候，自动执行绑定到裸设备的命令 。

于是，我们检查了一下配置的规则文件，如下所示 ：

不难看到，由于配置错误， 误将253:5绑定为/dev/raw/raw1,而raw1做了一个软连接到ora_system01.dbf,导致重启之后，ora_system01.dbf里存储的内容实际上都是2号文件sysaux这个LV的内容，因此数据库现了大量坏块 ！

9 、 问题完美解决解决

没错，数据库实际上没有损坏，而只是单纯的对应关系错乱！

在将配置关系调整正确后，重启操作系统，数据库正常启动。 差不多1刻钟的时间，我们将问题完美解决了!

 

“ 小 y, 这一单，没少赚吧 ”, 也许有同学关心这个 …

 

实际情况是，我们没有收取一分钱，朋友的朋友介绍，就是纯帮忙而已了！ 不过后来当我出差到客户所在城市的时候，一起吃了顿饭，交了个朋友，还是很不错的…

 

      问题 原因   与 经验 总结      

故障原因总结

1)      上线前，一开始通过 raw 命令直接绑定的块设备和裸设备的对应关系是正确的。但是上线前没有重启过操作系统 ；

2)    但是为了避免重启丢失，配置规则写错了 , 误将253:5(实际为2号文件 sysaux )绑定为/dev/raw/raw1,而raw1做了一个软连接到ora_system01.dbf,导致重启之后，ora_system01.dbf里存储的内容实际上都是2号文件sysaux这个LV的内容，因此数据库现了大量坏块！

3)      数据库实际上没有损坏，在修改配置关系正确后，问题圆满解决，无任何数据丢失，数据是一致的。

经验总结

1)      出现故障时，一定要冷静、冷静、再冷静！避免不正确的病急乱投医。在这个 case 中，即时客户采用 DUL 抽取数据成功，则抽取的数据也不能是保证一致的，设置隐含参数和 event 强行拉库的方式更是不可取；

2)      上线前务必重启操作系统，不要给未来埋雷，否则炸死的是他人还是自己，都不知道；

3)       技术虽然重要，但掌握原理才可以处理更为疑难的问题。掌握数据抽取软件 DUL 的使用，并不能解决这个问题，工具只是辅助手段而已；

4)       为什么小 y 可以在一刻钟内解决这个问题呢？这是学习和思考习惯的问题。小 y 在 10 年前安装 LINUX+ 裸设备时，就已经发现了这种配置方案本身存在的问题，例如根据磁盘分区绑定裸设备，但是当分区名字发生变化，不就错乱了么。这个 CASE 虽然有点不一样，但本质是一样的。这个问题，我等了十年，但是期间我时刻准备好了。我还在时刻准备着遇到我没有遇到过的问题。

通过这样一个案例，你不难发现，遇到问题，冷静是非常重要的。

而扎实的基础、细节把握以及冷静的现场能力，则可以让你在技术的道路上越走越顺！