database：10.2.0.1
OS WINDOWS SERVER 2008
今天由于朋友的数据的断电重启后，数据库起不来，更蛋疼的是SQLPLUS，LSNRCTL都进不去
要么一直hang住要么报错
ORA-12560: TNS: Protocol Adapter Error
由于alert日志非常大，我新建了一个日志文件发现DOWN库的报错如下：
Mon May 09 13:31:43 2016
Completed redo application
Mon May 09 13:31:43 2016
Errors in file d:\oracle\product\10.2.0\db_1\admin\orcl\bdump\orcl_p001_5116.trc:
ORA-00600: internal error code, arguments: [2037], [12627367], [2913444358], [6], [1], [0], [1667018151], [100925440]
Mon May 09 13:31:43 2016
Errors in file d:\oracle\product\10.2.0\db_1\admin\orcl\bdump\orcl_p000_1372.trc:
ORA-00600: internal error code, arguments: [2037], [12622839], [2616697350], [6], [1], [0], [1668258807], [100875008]
Mon May 09 13:31:43 2016
Errors in file d:\oracle\product\10.2.0\db_1\admin\orcl\bdump\orcl_p002_968.trc:
ORA-00600: internal error code, arguments: [2037], [12637266], [3562185222], [6], [4], [0], [294376530], [100743216]
Mon May 09 13:31:43 2016
Errors in file d:\oracle\product\10.2.0\db_1\admin\orcl\udump\orcl_ora_4960.trc:
ORA-07445: exception encountered: core dump [ACCESS_VIOLATION] [_kews_cln_timestate+720] [PC:0x603310] [ADDR:0xC876412] [UNABLE_TO_READ] []
ORA-01033: ORACLE initialization or shutdown in progress
看到这里错误为ORA-00600和ORA-07445这种错误很可能导致数据库崩溃，同时只能提取备份进行恢复，更郁闷的是压根没有备份。
查看TRACE文件如下：
TYP:0 CLS: 1 AFN:3 DBA:0x00c09bf7 OBJ:3690 SCN:0x0000.666d636d SEQ: 9 OP:11.2
buffer rdba: 0x9bf7a206
scn: 0x636f.636f9bf7 seq: 0x00 flg: 0x00 tail: 0x06033b00
frmt: 0x06 chkval: 0x0000 type: 0x01=KTU UNDO HEADER
Hex dump of corrupt header 4 = CORRUPT
如此我们可以总结一下，错误是在进行了
Completed redo application
开启并行UNDO回滚的时候出现的，TRACE中也能明显的看到
错误
0x01=KTU UNDO HEADER
Hex dump of corrupt header 4 = CORRUPT
那么我们大概可以知道由于UNDO的损坏导致了数据库恢复不能进行恢复，那么首先我们关闭掉并行恢复，
然后设置损坏的UNDO，同时设置不进行回滚，如果出现问题我们在一步一步的解决只能听天由命了，
幸运的是这个库这样做后正常启动了。但是在此之前我们必须解决SQLPLUS 根本不能的登陆的问题。
我查看了MOS的很多关于
ORA-12560: TNS: Protocol Adapter Error
的错误的文章，大概都是如下的描述：
1、ORACLE_HOME正确
2、PATH正确
3、ORACLE_SID正确
4、权限正确
5、可能多个oracle的软件有SQLPLUS使用正确的那一个其实就是PATH正确
我逐个排查，但是还是没有效果，我用ORADIM重建了服务如下：
oradim -new -sid -startmode AUTO -pfile
同时我还检查PWDfile存在，其实不关这个事
关于LISTENER我也设置了HOSTS多次试验，LINUX下HOSTS如果设置不正确
动态注册会有问题，还是不行我又设置了固定IP，还是不行。检查LISTER日志
没有超过4G。
但是还是不行，数据一旦启动DOWN掉后就登陆不进去了，郁闷了很久WINDOWS的东西就是这样稀奇古怪，
当然也是和运维人员的WINDOWS水平有关，因为要知道线上的服务器一般都不是WINDOWS。
搞了好几个小时一直没解决，又不想草草了事。
最后我发现虽然ORACLE实例DOWN掉了，但是WINDOWS进程还占用了部分内存，犹如LINUX下使用IPCS -m
看到没有完全释放内存一样，如此我使用了
oradim -new -sid -startmode m -pfile
设置ORACLE数据库不随服务启动，这下终于可以连接到空实例了。
接下来我们就按照常规的方法设置几个参数，然后慢慢看是否报错吧
1、undo_mangment='MANUAL'
2、fast_start_parallel_rollback=false
3、*._corrupted_rollback_segments=(_SYSSMU1$,_SYSSMU2$,_SYSSMU3$,_SYSSMU4$,_SYSSMU5$,_SYSSMU6$,_SYSSMU7$,_SYSSMU8$,_SYSSMU9$,_SYSSMU10$)
还是不行加上参数
4、_ALLOW_RESETLOGS_CORRUPTION=true
在mount阶段我做了RECOVER DATABASE使用LOGFILE进行了恢复完成了这一步
其实这一步一定成功因为LOGFILE恢复没有问题，
然后我就
ALTER DATABASE OPEN
成功启动。
没有出现额外的ORA-600错误如：
ora-600[2662](推进scn)
ora-600[4194]
最后导出数据，新建库吧。
这完全是幸运。
主要解决了2个问题
1、ORA-12560: TNS: Protocol Adapter Error 由于ORACLE随服务启动后DOWN掉没有完全示范进程内存。
2、ORA-00600: internal error code, arguments: [2037] 由于UNDO PARALLEL RECOVERY失败。