这是友情支持一个朋友的数据库恢复case,昨天圣诞节的时候来个求助，只能速度帮忙解决了好过节去了。首先我们来看下的alert log都有哪些信息：

我们可以看到，这个数据库已经宕机好几天了，在23号的时候就已经无法正常open了。上述的结果错误也很常见很简单。朋友经过处理后顺利把数据库open了，可是打开之后创建新的undo 表空间之后尝试重启后就再也打开不开了。遇到了如下的错误：

这个错误我也是第一次遇见。从kcbzpbuf函数来看，是dbwr进出写脏块时发现了坏块。很明显，从上面的坏块信息来看，dba地址0x0b07e8b2 和 rdba地址0x1c4ee895是不匹配，这肯定没法正常写入的。
针对这个错误我事后在metalink 搜索了一下，还是有不少相关的文档甚至是bug，这里不多说了。处理方式很简单，首先加入如下2个隐含参数尝试打开数据库：

*._allow_resetlogs_corruption=TRUE

*._allow_error_simulation=TRUE
做了不完全恢复后，尝试open resetlogs时发现遇到了如下错误：

看到这里2个错误，很多人可能会很迷惑，到底数据库无法open是因为哪个错误导致的呢？ 这里稍微注意一下前后报错的顺序就知道了，很明显是前面的ora-00600 [2662]错误导致无法open resetlogs完成。
对于ora-00600 [2662]错误这里不再解释了，SCN的问题。这里直接推进scn即可。
将数据库启动到mount状态，执行如下命令：

很顺利就打开了数据库。由于之前朋友已经创建了新的undo表空间，我只需要帮忙把undo重建就完事了，结束支持任务。尝试进行drop tablespace undotbs1 including contents and datafiles时，遇到ora-01548错误。
在alter session set “_smu_debug_mode” = 4; 后都无法进行drop，那只能继续使用下隐含参数了：

通过这2个隐含参数，可以顺利将旧的undo 表空间drop掉，然后修改pfile文件去掉不需要的一些隐含参数，顺利打开数据库。
到这里结束我的半小时支持友情支持任务！悲剧的下午又开始优化某客户的SQL。。。。。

备注：

1) 对于这种异常强制打开的数据库，建议进行全库检查，包括是否有坏块等，甚至检查数据字典是否一致等等（实际上检查之前的alert log发现，    之前数据库在恢复过程中就报了不少的坏块)

2) 在这个年代，还有3TB的数据库，而且是windows，更悲剧的还是非归档，没有备份，这是不应该的。

3) 我们应该多考虑下系统的容灾建设，哪怕是有备份。