日志显示:
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
Copyright (c) 1982, 2005, Oracle. All rights reserved.
EXP-00056:遇到ORACLE错误1034
ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
EXP-00005:所有允许的登录尝试均失败
EXP-00000:导出终止失败
看错误信息似乎数据库没有启动,检查发现果然数据库自动关闭了,查询alert文件发现了大量的ORA-600(4194)错误。
再次尝试启动数据库报错:
C:Documents and SettingsAdministrator>sqlplus / as sysdba
SQL*Plus: Release 10.2.0.1.0 - Production on星期三3月3 17:35:43 2010
Copyright (c) 1982, 2005, Oracle. All rights reserved.
已连接到空闲例程。
SQL> STARTUP
ORACLE例程已经启动。
Total System Global Area 612368384 bytes
Fixed Size 1250428 bytes
Variable Size 121637764 bytes
Database Buffers 482344960 bytes
Redo Buffers 7135232 bytes数据库装载完毕。
ORA-00607:当更改数据块时出现内部错误
ORA-00600:内部错误代码,参数: [4194], [38], [22], [], [], [], [], []
虽然STARTUP命令报错,但是数据库已经打开可以访问了,但是没过几分钟的时间,数据库就又自动关闭了,导致数据库自动关闭的原因仍然是ORA-600(4194)错误。
查询metalink发现,导致这个错误是由于UNDO信息出现了不一致,虽然metalink上没有给出解决方法,不过根据经验,利用隐含参数_corrupted_rollback_segments尝试打开数据库。
好在数据库可以短暂的打开,这样可以方便的查询到系统启动的回滚段名称:
SQL> CONN / AS SYSDBA已连接。
SQL> SELECT SEGMENT_NAME FROM DBA_ROLLBACK_SEGS;
SEGMENT_NAME
------------------------------
SYSTEM
_SYSSMU1$
_SYSSMU2$
_SYSSMU3$
_SYSSMU4$
_SYSSMU5$
_SYSSMU6$
_SYSSMU7$
_SYSSMU8$
_SYSSMU9$
_SYSSMU10$
已选择11行。
SQL> CREATE PFILE='D:ORACLEADMINORCLPFILEINITORCL.ORA' FROM SPFILE;
文件已创建。
在初始化参数文件中添加下面的参数:
undo_management='MANUAL'
_corrupted_rollback_segments=(_SYSSMU1&,_SYSSMU2&,_SYSSMU3&,_SYSSMU4&,_SYSSMU5&,_SYSSMU6&,_SYSSMU7&,_SYSSMU8&,_SYSSMU9&,_SYSSMU10&)
下面尝试打开数据库:
SQL> conn / as sysdba已连接到空闲例程。
SQL> STARTUP PFILE=D:ORACLEADMINORCLPFILEINITORCL.ORA MOUNT
ORACLE例程已经启动。
Total System Global Area 612368384 bytes
Fixed Size 1250428 bytes
Variable Size 121637764 bytes
Database Buffers 482344960 bytes
Redo Buffers 7135232 bytes数据库装载完毕。
SQL> RECOVER DATABASE;完成介质恢复。
SQL> RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL
ORA-00279:更改19786562 (在03/03/2010 18:20:31生成)对于线程1是必需的
ORA-00289:建议: D:ORACLEFLASH_RECOVERY_AREAORCLARCHIVELOG2010_03_03O1_MF_
1_3_%U_.ARC
ORA-00280:更改19786562 (用于线程1)在序列#3中
指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
CANCEL介质恢复已取消。
SQL> ALTER DATABASE OPEN RESETLOGS;
数据库已更改。
数据库成功打开,下面再次利用EXP将数据库的业务用户进行导出:
D:>exp hc/hc file=hc_20100303.dmp buffer=2048000 direct=y recordlength=65534 compress=n log=hc_20100303.log
Export: Release 10.2.0.1.0 - Production on星期三3月3 18:26:57 2010
Copyright (c) 1982, 2005, Oracle. All rights reserved.
连接到: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options已导出ZHS16GBK字符集和AL16UTF16 NCHAR字符集
.正在导出pre-schema过程对象和操作
.正在导出用户HC的外部函数库名
.导出PUBLIC类型同义词
.正在导出专用类型同义词
.正在导出用户HC的对象类型定义即将导出HC的对象...
.正在导出数据库链接
.正在导出序号
.正在导出簇定义
.即将导出HC的表通过直接路径...
. .正在导出表CAT_ORG导出了6116行
. .正在导出表CESHI_USER_FUNC导出了0行表HC_AGENT_ANN将以常规路径导出。
. .正在导出表HC_AGENT_ANN导出了295行
. .正在导出表HC_AGENT_ANN_ITEM导出了0行
. .正在导出表HC_AGENT_LINK导出了5行表HC_AGENT_NEWS将以常规路径导出。
. .正在导出表HC_AGENT_NEWS导出了2054行
. .正在导出表HC_AGENT_NEWS_ITEM导出了0行
.
.
.
. .正在导出表HC_USER_MSN_SEND导出了122行
. .正在导出表HC_VIP_PUBLISH_PRODUCT导出了1858行
. .正在导出表HC_VISIT_COUNT导出了1行
. .正在导出表PLAN_TABLE导出了0行
. .正在导出表T_INVITE导出了0行
.正在导出同义词
.正在导出视图
.正在导出存储过程
.正在导出运算符
.正在导出引用完整性约束条件
.正在导出触发器
.正在导出索引类型
.正在导出位图,功能性索引和可扩展索引
.正在导出后期表活动
.正在导出实体化视图
.正在导出快照日志
.正在导出作业队列
.正在导出刷新组和子组
.正在导出维
.正在导出post-schema过程对象和操作
.正在导出统计信息成功终止导出,没有出现警告。
至此,数据库的恢复工作完成。虽然数据库可以打开,但是丢失数据在所难免,所以关键数据一定要做好备份工作。