日志显示：
Tue Dec 14 15:37:40 2010
Flush retried for xcb 0x2f5fc160, pmd 0x2f7a98e8
Doing block recovery for file 2 block 145
Block recovery from logseq 8, block 65 to scn 642130
Tue Dec 14 15:37:40 2010
Recovery of Online Redo Log: Thread 1 Group 1 Seq 8 Reading mem 0
Mem# 0 errs 0: /u01/app/oracle/oradata/stream2/redo01.log
Block recovery completed at rba 8.69.16, scn 0.642132
Tue Dec 14 15:37:48 2010
DEBUG: Replaying xcb 0x2f601ec0, pmd 0x2f798cd4 for failed op 8
Doing block recovery for file 2 block 1893
Block recovery from logseq 8, block 63 to scn 642126
Tue Dec 14 15:37:48 2010
Recovery of Online Redo Log: Thread 1 Group 1 Seq 8 Reading mem 0
Mem# 0 errs 0: /u01/app/oracle/oradata/stream2/redo01.log
Block recovery completed at rba 8.67.16, scn 0.642129
Tue Dec 14 15:37:49 2010
Errors in file /u01/app/oracle/admin/stream2/bdump/stream2_pmon_3971.trc:
ORA-00600: internal error code, arguments: [4194], [38], [46], [], [], [], [], []
Tue Dec 14 15:37:50 2010
Errors in file /u01/app/oracle/admin/stream2/bdump/stream2_pmon_3971.trc:
ORA-00600: internal error code, arguments: [4194], [38], [46], [], [], [], [], []
PMON: terminating instance due to error 472
Instance terminated by PMON, pid = 3971
后来在yangtingkun博客看到解决方法如下：
检查
alert
文件，发现导致问题的原因是由于掉电导致日志文件损坏，在进行
CRASH
恢复时无法将数据库恢复到一致性的状态。
对大致情况有了一定的了解后，准备开始着手恢复工作：首先是
备份
现场，这样如果恢复失败，至少保留了出错是的环境。
然后尝试利用隐含参数
_allow_resetlogs_corruption
来打开数据库，这个步骤在很多篇文章中都描述过了，这里就不重复了，可以参考：
http://yangtingkun.itpub.net/post/468/464701
数据库顺利打开，
ALTER DATABASE OPEN RESETLOGS
操作并没有报错，但是由于使用了隐含参数，因此数据库肯定会丢失数据，而且会处于不一致的状态，为了避免数据库的不一致对数据造成进一步的损害，准备将业务用户执行逻辑导出：
D:>exp hc/hc file=hc_20100303.dmp buffer=2048000 compress=n log=hc_20100303.log
Export: Release 10.2.0.1.0 – Production on
星期三
3
月
3 17:38:01 2010