关于redolog的恢复

1，通常情况如果日志文件多元化，日志组好的成员拷贝到损坏的日志成员就可以了。一下只考虑一些极端的日志文件损坏的情况。
2，通常联机日志有四种状态
active 、  不是正在使用的日志文件，但是日志条目对应的脏数据并没有写到数据文件里，如果实例异常崩溃，而日志文件损坏的话是要丢数据的。                                                                                                                                                                                                                                                                                                          
inactive、不是正在使用的日志文件，且日志条目对应的脏数据已经写到数据文件中，如果实例崩溃，而日志文件损坏的话，数据不会丢失。                                                                                                                                                                                                                                  
current、正在使用的日志文件，且日志条目对应的脏数据肯定没有写到数据文件中，  和active的情况一样。                                                                                                                                                                        
unused 、一次也没有使用的日志文件。

一，正常关库的情况下，当前日志文件损坏    
SQL> select * from v$log;
    GROUP#    THREAD#  SEQUENCE#      BYTES  BLOCKSIZE    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIME   NEXT_CHANGE# NEXT_TIME
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ------------ ------------ ------------
         1          1          1   52428800        512          1 YES INACTIVE               1587531 27-DEC-13         1590896 27-DEC-13
         2          1          2   52428800        512          1 YES INACTIVE               1590896 27-DEC-13         1591896 27-DEC-13
         3          1          3   52428800        512          1 NO  CURRENT                1591896 27-DEC-13      2.8147E+14
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
删除当前日志文件3
[oracle@node1 test]$ rm /u01/app/oracle/oradata/test/redo03.log
SQL> startup
ORACLE instance started.
Total System Global Area  849530880 bytes
Fixed Size                  1339824 bytes
Variable Size             650120784 bytes
Database Buffers          192937984 bytes
Redo Buffers                5132288 bytes
Database mounted.
ORA-03113: end-of-file on communication channel
Process ID: 31070
Session ID: 1 Serial number: 5

告警日志报错            

ORA-00313: open failed for members of log group 3 of thread 1
ORA-00312: online log 3 thread 1: '/u01/app/oracle/oradata/test/redo03.log'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory

处理11g  
11g 需要重新启动实例到mount下
SQL> startup mount;
ORACLE instance started.
Total System Global Area  849530880 bytes
Fixed Size                  1339824 bytes
Variable Size             650120784 bytes
Database Buffers          192937984 bytes
Redo Buffers                5132288 bytes
Database mounted.
直接clear logfile 失败
SQL> alter database clear logfile group 3;
alter database clear logfile group 3
*
ERROR at line 1:
ORA-00350: log 3 of instance test (thread 1) needs to be archived
ORA-00312: online log 3 thread 1: '/u01/app/oracle/oradata/test/redo03.log'
需要恢复      
SQL> recover database until cancel;
Media recovery complete.
SQL> alter database open resetlogs;
Database altered.
第二种办法网上参考的                              
如果数据库是正常shutdown,非当前日志都可以直接clear来重新生成，而且不丢失数据，因为正常关闭db,数据已经写入dbf文件了。唯独当前日志不可以，当前日志必须首先从有效的备份中拷贝一个日志文件过来，然后用 
alter database clear unarchived logfile group n 或alter database clear unarchived logfile group n,除此之外，还可以用下面的方法来做  
                                                             
二，异常关库的情况，active或者current日志文件损坏                                                                                                                  
11g
   加隐含参数 _allow_resetlogs_currupption=true 在resetlog开库的时候跳过数
据块的一致性检查。这种开库 是丢失数据的。




                                                                                                                                                                                                                                                                       

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29108064/viewspace-1065152/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/29108064/viewspace-1065152/