oracle的redolog停止,Oracle Redo Log日志故障处理一则
Oracle Redo Log日志故障处理一则
某日oracle服务器异常重启，当重启oracle数据时，发现redo log文件被损坏，
且这个日志文件是current状态的，导致数据库无法打开;
数据库的alert.log报如下错误
Sat Mar 14 08:34:25 2015
ALTER DATABASE OPEN
Beginning crash recovery of 1 threads
parallel recovery started with 3 processes
Started redo scan
Sat Mar 14 08:34:47 2015
Errors in file /usr/oracle/diag/rdbms/ftest/ftest/trace/ftest_ora_20852.trc:
ORA-00333: redo log read error block 20482 count 4096
ORA-00312: online log 2 thread 1: '/usr/oracle/oradata/ftest/redo02.log'
ORA-27072: File I/O error
Linux-x86_64 Error: 2: No such file or directory
Additional information: 4
Additional information: 20482
Additional information: 732160
Sat Mar 14 08:34:58 2015
Errors in file /usr/oracle/diag/rdbms/ftest/ftest/trace/ftest_ora_20852.trc:
ORA-00333: redo log read error block 16386 count 8192
ORA-00312: online log 2 thread 1: '/usr/oracle/oradata/ftest/redo02.log'
ORA-27072: File I/O error
Linux-x86_64 Error: 2: No such file or directory
Additional information: 4
Additional information: 16386
Additional information: 2829312
Aborting crash recovery due to error 333
可以看出当数据库在打开时，做实例恢复时需要扫描redo02.log文件，但是读取该文件报错
这个redo02.log文件是存在的，只是无法进行io了，在os级别使用cp命令也无法读取这个文件.
启动实例到mount状态,这个日志是current状态的.
SQL> select group#,status from v$log;
GROUP# STATUS
---------- ----------------
1 INACTIVE
2 CURRENT
3 INACTIVE
由于该数据库没有人做备份，所以现在使用备份来做不完全恢复也是不可能了.看来只有使用非常规手段
来进行修复了.
启动数据库到mount状态，然后使用了不完全恢复
SQL> recover database until cancel;
选择auto
这时候恢复并没有真正的恢复，只是有点类似于不完全恢复的标志，这样下次在打开时候就可以
resetlogs操作了.
查看各文件的checkpoint信息，发现一致，接下来可以使用隐含参数应该可以打开数据库.
SQL> select file#,checkpoint_change# from v$datafile;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 6880798637
2 6880798637
3 6880798637
4 6880798637
5 6880798637
6 6880798637
7 6880798637
7 rows selected.
使用"_allow_resetlogs_corruption"参数，然后alter database open resetlogs
数据库被成功打开。但是alert.log中会报ora-600[4194]的错误，这个需要清理一下原
来的undo表空间，之前的blog有介绍，可以参考.