首先是实例恢复需要用到的REDO文件损坏
用CLEAR命令重建该日志文件SQL>alter database clear logfile group 3;
如果是该日志组还没有归档,则需要用SQL>alter database clear unarchived logfile group 3;
因为是当前实例恢复需要用的REDO,且未归档,使用是CLEAR命令不行的。拷贝有效的数据库的全备份,并不完全恢复数据库
可以采用获取最近的SCN的办法用until scn恢复或用until cnacel恢复
recover database until cancel
先选择auto,尽量恢复可以利用的归档日志,然后重新
recover database until cancel
这次输入cancel,完成不完全恢复,也就是说恢复两次。如:
SQL> recover database until cancel;
Auto
……
SQL> recover database until cancel;
Cancel;
、利用alter database open resetlogs打开数据库
说明:
这种办法恢复的数据库是一致的不完全恢复,会丢失当前联机日志中的事务数据
这种方法适合于归档数据库并且有可用的数据库全备份。
恢复成功之后,记得再做一次数据库的全备份。
建议联机日志文件一定要实现镜相在不同的磁盘上,避免这种情况的发生,因为任何数据的丢失对于生产来说都是不容许的。
_allow_resetlogs_corruption=TRUE
重新启动数据库,利用until cancel恢复
SQL>recover database until cancel;
Cancel
如果出错,不再理会,发出
SQL>alter database open resetlogs;
数据库被打开后,马上执行一个full export
shutdown数据库,去掉_all_resetlogs_corrupt参数ksedmp: internal or fatal error这个错误不难解决,但是其具体成因有点意思。
ORA-00600: internal error code, arguments: [kcratr1_lostwrt], [], [], [], [], [], [], []
Current SQL statement for this session:
alter database open
When an instance is restarted following an instance crash, Oracle carries out some checks against the last block that was written to disk prior to the instance crash.这句话是说,当实例崩溃之后启动,Oracle会去检查崩溃前最后一个写出的数据块,通过控制文件校验其是否一致,如果这个块是Old的,则说明最后的写操作丢失了。
If Oracle finds an old block, then this suggests a lost write and the error is raised.
Last BWR afn: 6 rdba: 0x18f9590(blk 1021328) ver: 0x0001.5c21fd6e.01 flg: 0x04提示说,控制文件记录的最后一次写的数据块是file6 block 1021328,SCN版本为:5c21fd6e,而数据文件上记录的SCN则是5c1ec4f0,后者Old,小于前者,这说明丢失了写操作。
Disk version: 0x0001.5c1ec4f0.04 flag: 0x04
Thread checkpoint rba:0x00dfeb.00000002.0010 scn:0x0001.5c1ee5b7线程检查点的SCN为5c1ee5b7,而On-Disk Rba的SCN为5c2266d6,完全可以推演超过5c21fd6e,可以恢复。
On-disk rba:0x00dfeb.0001161f.0000 scn:0x0001.5c2266d6
SQL>startup mount;一般就可以完成恢复了,如果不幸的,你的On-Disk Rba不足以恢复丢失的写操作,则问题将严重了。
SQL>recover database;
SQL>alter database open;
参考:http://blog.itpub.net/25964700/viewspace-709097/ http://www.eygle.com/archives/2010/05/ora-00600_kcratr1_lostwrt.html
联系客服