非歸檔模式下異常斷電導致的資料庫無法啟動的問題修復

背景：
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:

3、ORA-01595故障處理


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

5、ORA-01194錯誤恢復方法一