有压力,要坚持

DBA未必是一个高薪的职业,但绝对是一个高压力的职业。

昨天晚上,数据仓库一个4节点的RAC+ASM系统,在进行新加节点操作的时候,发现新节点的ASM实例无法mount diskgroup,报ORA-15042错误。后来尝试将整个库重启,结果所有节点的ASM实例都出现同样的问题了。这个教训告诉我们,在遇到问题没有搞清楚具体原因之前,千万不要轻易重启数据库。

但是问题既然已经发生,自然要想办法修复。这是一个将近7T的生产系统,虽然目前只供内部使用,也不可能接受长时间的停机,所以重建diskgroup然后从备份恢复的方案只能是最坏情况下的打算。那么,当务之急,是要尽快查出问题所在,对症下药。

工欲善其事,必先利其器。这次问题的解决,得益于oracle的kfed工具。从dump出来的结果看到,报错的两个disk的头信息确实已经损坏,另外一点比较奇怪的就是,正常disk header中记录的disk number和path信息,和从v$asm_disk查出来的已经不一致了。这个现象可能由于两个disk的头信息损坏,导致AMS Instance读取相关信息的整个机制出现了混乱。

首先将两个损坏的disk通过dd做一个完整的备份。另外一方面,流云也通过metalink开了一级tar,并且直接电话找oracle的相关支持人员调动资源帮助解决问题,事实证明,虽然对于紧急故障处理的速度可能不是足够快,因为他们不了解系统相关情况,需要花很多时间来问一些相关的问题等等。但是oracle拥有足够的文档资源,这也为最终解决问题打下了基础。当然,文档只是提供了方向和思路,而且往往不同的两个文档之间还会有矛盾之处,这些都需要根据情况来做出修正。

从oracle得到的一份文档记录了一个相似的案例,并且也是通过kfed工具修复了disk header而最终解决了问题,这给了我们足够的信心。拖雷七公在家里也连上来和我们一起来分析如何修复损坏的disk header,根据dump出来的正常disk的头信息很快算出来两个异常disk的头信息,然后通过kfed将信息merge进去,满怀希望的重启ASM Instance,靠,问题依旧。

仔细比对文档,发现刚才没有去改时间截。时间截的信息,除了在每个disk header中保存,还会在集中保存在disk directory中。那么首先要找到这个disk directory。而disk directory的地址又保存在一个起始磁盘的某个AU上。所以就要找到这个file1block1的disk,也就是kfdhdb.f1b1locn的值不为0的disk,通过一个个disk header的查找可以确定。当然,这次我们比较幸运,坏的两个disk不是f1b1,否则可恢复的机会就要大打折扣,时间上也会拉长很多,因为可能需要扫描整个disk去查到保存在disk其他位置的file directory信息,能找到还好,找不到就彻底没戏,只能重建了。

通过f1b1的AU2 block4中的指针(大多数情况下在这个位置,但并不保证),找到disk directory对应disk的时间截,当然,这个过程说起来一句话,实际上花了相当长的时间,其中还隐藏了很多细节,呵呵。处理这种问题,一个人真的很难搞定,因为基本都是internal的东西,之前从来都没有任何经验,只能靠一点点的蛛丝马迹去不同的猜测、验证,一个人的话就很容易走入死胡同,幸好我们是团队作战。

历经艰难找时间截信息,马上merge进去重试。My God,还是不行。这个时候已经是到凌晨了,从早上9点上班算起,已经连续工作了15个小时以上了,而且似乎坏事总是喜欢扎堆,中间还处理了另外一个备库文件创建失败的故障,还有个主机的本地盘也坏了一块,当然是镜像过的,问题不大,报修一下,找个时间更换就好。到洗手间洗个脸,清醒一下。另外最坏的方案也开始做准备了,要是一两个小时内问题还是无法解决,就只能全库恢复了。

时间一点点过去,压力越来越大,脑子的运转也越来越慢。其实从dump出来的信息可以看到,disk header中的东西并不多,基本上就是四五处地方不一致需要修改的。那么为什么修改后还是不成功呢?再从头仔细的比对正常和修复过的disk header信息,发现check校验值是不一样的,而几个正常的disk都是同一个值。一般来说校验值应该是通过计算得到,所以check值没法通过merge导入,那么只有手工强行更改了来试试是否可行了。事实证明,这是行不通的。但是,这次尝试也露出了一点点希望的曙光。之前merger后从v$asm_disk.header_status看这两个盘的值一直都是INCOMPATIBLE,而这次终于有了变化,变成PROVISIONED。虽然diskgroup依旧不能mount,心里还是觉得这条路是能走通的。

晚上原计划要将一个库rebuild几个索引到新的磁盘上以分布IO压力的,先把这个命令下了再说。回头再来想,为什么check会不正确呢?说明check的计算,不但跟dump出来的那些值相关,跟头部中的其他一些位应当也是相关的,而这些位通过dump是看不到的。于是用od直接看16进制的值,通过比较发现很多在正常的disk header中全0的地方,在损坏的两个盘中都是有值的,莫非问题就出在这里?狠一点,将前面4k的头部全部用dd清零,然后重新merge。谢天谢地,diskgroup正常mount上了,oh,yeah!这个时候虽然已经凌晨4点了,因为持续的紧张和熬夜,我们都是面容疲倦,但是问题最终得到解决,还是相当的激动,流云同学甚至一拳打在椅背上将手都打出血来了^_^

做完一些善后工作,外面公交车在开始高叫“行人车辆请注意安全”了。再回头看这个晚上,其实中途好多次都想放弃了,一次次的失败真的让人非常的沮丧,而且周三的晚上才做了一次维护,疲劳状态下很多处理其实做得都不好,走了很都的弯路。也许很多事情都是这样,在你即将绝望放弃的时候,其实离最终的终点已经非常非常的接近,只要再坚持一下,但是这一下,又谈何容易呢。



无觅相关文章插件,快速提升流量

13条评论

  • […] 这几天可能由于这篇ASM故障处理的文章的原因,访问量开始直线上升。根据awstats的统计,美国时间2008-2-25日独立IP突破了500。虽然和Fenng,eygle,Anysql,piner等牛人们的blog相比,还不足零头,不过还是值得小小的记录一下。 […]

    • At 2008.02.27 07:56, 木匠 said:

      这么牛的回复技术, 上哪里去学呀, 高薪不易.

      • At 2008.02.27 21:43, ricky said:

        佩服佩服,ASM的东西弄这么透,实在不容易

        AU和block。。。

        • At 2008.02.27 21:53, NinGoo said:

          透什么啊,瞎子摸象而已。用于RAC的ASM我都还不会安装呢。。。

        • At 2008.02.27 22:22, looric said:

          是挺难的。

          • At 2008.02.29 15:56, Kamus said:

            great!
            其实从一个侧面告诉我们,asm的磁盘验证机制是比较简单的,就是disk header处的那些信息。

            • At 2008.03.01 00:07, Oracle11g ASM强大的新工具AMDU said:

              […] 在上次ASM故障恢复的案例中,强烈的感觉到ASM过于封装的特性,虽然极大的减轻了DBA的管理负担,但同时也使得灾难发生的时候处理的难度更高。 […]

              • At 2008.03.08 10:21, freebug said:

                想不通为什么这么重要的数据,不做硬件磁盘阵列?????????????????

                • At 2008.03.08 15:53, NinGoo said:

                  你从哪里看出没有用raid的?损坏的是ASM disk header,又不是物理磁盘。ASM disk只是物理磁盘上的一层逻辑设备,就像file一样。即使你用raid10,也不能防止file的逻辑损坏不是?

                  • At 2008.03.09 08:24, freebug said:

                    哦,明白了,不过ASM DISK既然是逻辑层的,在没有误操作的情况下,为什么自己损坏?

                    • At 2008.03.09 11:58, NinGoo said:

                      逻辑错误一定要误操作才会出现的么?呵呵

                • At 2008.03.09 00:28, ASM实例中的隐含参数 said:

                  […] 上一次ASM故障处理中有提到清空了前面4k的头部,为什么是4K,就是因为_asm_blksize=4096,这是一个block的大小,可不是随便来的,呵呵。 […]

                  • […] 好吧,其实我是想说,这一天,终于成为了阿里巴巴五年陈。从进入淘宝的第一天,一年香,三年醇,五年陈的说法就一直萦绕在耳边。还记得一年香的时候礼物是一个印着小蚂蚁的杯子,貌似当年的蚂蚁已经进化成了如今的淘公仔,蚂蚁标记已经从各种地方慢慢消失。其实当年绿敏同学的一首小蚂蚁大淘宝的歌依然还在记忆深处吟唱,那时候的淘宝真的非常草根,而今这种感觉可能随着时间感觉已经冲淡了不少。不过那个杯子我其实没有收到,只是看其他同学有,当时工作都很忙,也没在意。那时候的淘宝DBA团队,兵少而精,数据库都跑在高富帅的IOE(IBM小型机/Oracle数据库/EMC存储)上,现在回首整个就是一青葱岁月,但第一年的收获真的非常大,也经历过至今想起来还浑身冒冷汗的故障。 […]


                    (Required)
                    (Required, will not be published)