非归档模式下异常断电导致的数据库无法启动的问题修复

背景：
1、非归档模式；
2、无任何归档日志、控制文件或数据文件的备份；

3、已经被人尝试恢复，执行过很多类似clear、drop log file等操作。

由于操作太多，没有将所有操作记录下来。所以只记录简单的思路，以供日后参考。

问题现象：
控制文件scn与数据文件scn不一致；

恢复方式：
重建控制文件。

此时尝试resetlogs方式启动，提示system01.dbf尚未完全恢复。

所以，指定"_allow_resetlogs_corruption"=true：
alter system set "_allow_resetlogs_corruption"=true scope=spfile;

不考虑一致性的问题，强行启动数据库：

先关闭数据库：
shutdown abort

再启动到mount状态下：
startup mount

正常方式启动数据库，提示需要恢复指定的数据文件，于是执行：
recover datafile 1;--指system01.dbf文件
recover datafile 2;--指undotbs.dbf文件
等等。把所有的数据文件都一一按照以上语句恢复一遍。

遇到的问题很多，其中，最重要的一个问题的解决思路如下：
1、有几次以resetlogs启动，出现了致命错误，吓我一身冷汗；
2、从alertlog检查错误原因，发现是在指定的trc文件中；
3、从trc文件中，发现了类似如下的错误：
ORA-01595: error freeing extent (3) of rollback segment (1))
ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [4194], [27], [22], [], [], [], [], []
4、根据找到的资料，初步估计是因为与undo的数据不同步，导致出现以上错误。
5、改undo为手动管理模式启动：
alter system set undo_management=manual scope=spfile;
6、重启数据库：
startup force
7、启动成功，新建undo表空间：
create undo tablespace undotbs2 datafile '..........';
8、指定新的表空间：
alter system set undo_tablespace=undotbs2 scope=spfile;
9、将undo改为自动管理模式：
alter system set undo_management=auto scope=spfile;
10、重启数据库：
startup force
11、问题解决。

参考链接：
1、_allow_resetlogs_corruption参数的使用：
http://blog.163.com/hemeicun/blog/static/111573048201181611502225/

2、about recreate controlfile:
http://www.killdb.com/2012/07/11/about-recreate-controlfile.html

3、ORA-01595故障处理
http://hi.baidu.com/nixsql/item/c8325c9fd0aa8db183d29565

4、ora-01194：
http://blog.csdn.net/compard/article/details/2065431

5、ORA-01194错误恢复方法一
http://hi.baidu.com/redhairspace/item/c3fcf78745a674eae496e0be

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/12932950/viewspace-1184130/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/12932950/viewspace-1184130/