公司新闻

超融合硬件损坏导致Oracle RAC异常恢复实录

　　墨墨导读：一套Oracle RAC环境运行在HW超融合环境中，由于硬件问题导致数据库crash，期间出现了不少数据坏块，本文详述整个恢复过程，希望对大家有帮助。

　　前几天某客户遇到一个棘手问题：其一套Oracle RAC环境运行在HW超融合环境中，由于硬件问题导致数据库crash，期间出现了不少数据坏块，不过还好客户有RMAN物理备份，因此客户提前进行了全库Restore。

　　首先我们来看下相关日志信息：

　　上述类似的大量坏块信息，最终导致数据库挂掉。

　　我们可以看到客户这里asm diskgroup为normal冗余；当primary extent数据有问题时，Oracle会尝试从mirror extent去获取；如果mirror extent是正常的，那么Oracle会自动进行修复，否则会导致数据丢失，严重的话会导致数据库宕机。

　　因为部分文件需要介质恢复（因为primary和mirror 数据都异常），而数据库强行终止了实例。

　　数据库实例重启后则开始出现大量错误：

　　不难看出数据库控制文件和system都出现了异常，这也难怪数据库无法正常打开。

　　期间还出现了ora-00600 [4193]等常见错误：

　　对于此次恢复case总体来讲比较简单，这里提供一下处理思路：

　　首先利用客户的归档和Redo(Redo log客户已copy到了本地进行备份)，进行正常的recover database using backup controlfile until cancel操作；

　　由于恢复过程中出现了ora-00600 [3020]错误，因此需要通过recover database allow xx corruption的方式进行；

　　完成恢复之后尝试打开数据库；

　　打开数据库时仍然提示ora-01113和ora-01110错误，即system文件还需要进行恢复；这种情况下只能先强制拉库；通过加入*._allow_resetlogs_corruption=TRUE *._allow_error_simulation=true 等隐含参数即可；

　　若上述参数后仍然提示undo 存在坏块，由于该数据库版本在报错时不会直接提示具体是哪个回滚段有问题，在alter database open resetlogs之前通过10046 event定位error cursor，找到回滚段名称即可；

　　使用_corrupted_rollback_segments参数屏蔽回滚段；

　　open resetlogs数据库成功；

　　最后就是重建undo以及处理相关坏块等善后工作。

　　恢复完成之后，由于客户担心HW超融合环境再次出现故障因此进行了全库备份并进行数据迁移到新平台，到这里这个case告一段落。

　　再次叮嘱大家，注意数据库备份、注意数据容灾环境建设！

　　推荐阅读：144页！分享珍藏已久的数据库技术年刊

　　数据和云

　　ID：OraNews

　　如有收获，请划至底部，点击“在看”，谢谢！

　　点击下图查看更多 ↓

　　云和恩墨大讲堂 | 一个分享交流的地方

　　长按，识别二维码，加入万人交流社群

　　请备注：云和恩墨大讲堂 点个“在看”