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

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

早上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）。”