前几天某客户遇到一个棘手问题；其一套Oracle rac环境运行在HW超融合环境中；由于硬件问题导致数据库crash；期间出现了不少数据坏块；不过还好客户有RMAN物理备份；因此客户在找到我之前就已经先进行了全库Restore；首先我们来看下相关日志信息：

上述类似的大量坏块信息，最终导致数据库挂掉；其中我们可以看到客户这里asm diskgroup为normal冗余；当primary extent数据有问题时，Oracle会尝试从mirror extent去获取；如果mirror extent是正常的；那么Oracle会自动进行修复；否则会导致数据丢失；严重的话会导致数据库宕机。

最因为部分文件需要介质恢复（因为primary和mirror 数据都异常）；而数据库强行终止了实例。数据库实例重启后则开始出现大量错误：

不难看出数据库控制文件和system都出现了异常；这也难怪数据库无法正常打开。期间还出现了ora-00600 [4193]等常见错误：

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

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

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

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

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

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

6、使用_corrupted_rollback_segments参数屏蔽回滚段；

7、open resetlogs数据库成功

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

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

备注：话说这次客户貌似2年前我帮忙恢复过一次数据库，也是Oracle ASM；没想到2年后一大清早又找来了。再次叮嘱大家，注意数据库备份、注意数据容灾环境建设！