职业生涯最严重的一次宕机

昨天,经历了职业生涯中最令人心惊胆颤的危机,差点要去买锄头准备回家种地去了。-_-!!

早上5点钟,被同事叫醒,说应用程序连数据库报TNS没响应。于是开始登录数据库主机。登录的时候,用常用的浮动IP连接,没响应,此时第一个反映就是是不是数据库主机挂了?难道要去机房?现在可是奥运前期,进出机房是件挺麻烦的事情……再试了试实际IP,幸好,登录进去了。check了一下进程和alertlog,发现是控制文件的读取有问题了:

赶紧请主机工程师也登录上来检查,主机工程师上来之后,重新把VG mount了一次,也重新在db01激活了一次(有做HP的MC双机热备),再次启动数据库,又是报错:

坏了,vg_ora1上的spfile读不出来了,那换备份的pfile,用pfile到nomount,接着到mount时,再次报错:

查alertlog是控制文件1的问题,ok,在pfile中去掉控制文件1,再次mount,OK,没问题,再次open,报错找不到system的数据文件!!

看来vg_ora1上的lv(裸设备)全完了!!

开始着手恢复措施:一方面,请主机工程师着手vg_ora1的恢复;另一方面,开始在db02上搭建环境,在上面做数据库的恢复。可是,一看备份,寒了,legato的数据库全备不知道被那个兄弟给disable了,最近的一次全备是今年的4月的!要追加2个月的arch,不知道要多久……-_-!!

进一步检查,备份的磁带还被recycle了。当时那个寒呀……

只好寄希望在主机那边的存储恢复了,终于,经过仔细的检查,发现vg_ora1上链路挂错了,重新配置后,数据库启动了……成功!此时已经中午12点半了。

通过这次事故,得到的教训还是很深刻的:

(1)备份高于一切,没有合适的备份,神仙都没办法救。必须保证备份的有效性和时效性。


(2)单点存储很危险,虽然有主机层面的MC双机热备,但是仅仅是存储挂在A机还是挂在B机的区别,要是存储坏了,后果很严重……就算有备份,恢复也是需要一段时间。如果有条件的话,还是做个DG比较安全……


(3)要有合适的还原策略,还原方案、还原脚本必须提前准备妥当,而不是待事故发生以后现场找数据库需要的LV,再划分VG和LV,再编写restore/recover脚本进行还原。


 

附:HP的诊断报告节选:

PS:HP的auto path也不是个什么好东西:“在使用vgimport命令对vg_ora1进行重建中,系统将盘头信息属于vg_ora1的所有PV同时归于旗下,因而会产生c14t0d2与c14t0d6同时属于该vg的现象。但是vg信息中记录该vg只包含一块PV,因而OS误将c14t0d6作为了c14t0d2的副路径(alternate link)。”


======== END ========



如果觉得文章好,欢迎打赏:
pay

相关文章

13条评论

  1. 经历了4次心寒。。。。可想而知,当时是多大的打击。
    死的心都有了。
    当时那个悔啊。不可能的都在瞬间出现了。
    。。。
    只有经历过这样的事情,人才会成长,才能改变自己的思维以及想法。

  2. 发现vg_ora1上链路挂错了,重新配置后,数据库启动了

    请问这是在哪步挂错了?

    造成这个问题的最出原因是什么?

发表评论

电子邮件地址不会被公开。 必填项已用*标注