oracle联机日志修复

说明

        针对联机重做日志文件，我们并不需要做特殊的备份，因为他的存在特殊性，oracle几乎每时每刻都在写入应用日志文件，只要对其有一定的冗余处理即可，oracle会划分日志文件组，每个组中还会包含多个成员，保证日志文件的安全性，但不能保证日志文件都已经损坏，如磁盘损坏等情况。针对日志文件有无写入应用，这里有不同的情况来恢复。

 

丢失非当前联机日志

1       查询日志文件状态

SQL>select group#,thread#,sequence#,members,archived,status from v$log;       GROUP#    THREAD#  SEQUENCE#    MEMBERS ARC STATUS ---------- ---------- ---------- ---------- --- ----------------          1          1          4          1 NO  CURRENT          3          1          3          1 YES INACTIVE          2          1          2          1 YES INACTIVE

        这里有必要说一下各种状态信息，对于status有6种不同的值

         unused：表示日志文件还没有被应用过，一般在数据库刚刚创建或者open resetlogs后

         current：表示当前日志

         active：表示活动的，即使不是当前的日志，也代表了正在被使用或者将要被使用

         clearing：表示日志正在被清空，在数据库执行：alter database clear logfile后，日志会                               成为这个状态，执行完成后会变为unused;

         clearing_current：表示日志正在被清空，但是由于清空出错，导致无法完成清空二报错。

         Inactive：表示不活动状态，日志已经被归档或者已经写入数据文件，日志文件已经可                               以被重用。

        查询到日志1号、2号日志状态当前为非活动。

2       模拟丢失日志文件

SQL>shutdown immediate; [oracle@dev206 oracle]$ rm -rf /oracle/u01/app/oracle/oradata/orcl/redo03.log

        启动数据库    

SQL>conn / as sysdba; SQL>startup; ORA-32004: obsolete and/or deprecated parameter(s) specified ORACLE instance started.   Total System Global Area 1224736768 bytes Fixed Size                  2020384 bytes Variable Size             352324576 bytes Database Buffers          855638016 bytes Redo Buffers               14753792 bytes Database mounted. ORA-00313: open failed for members of log group 3 of thread 1 ORA-00312: online log 3 thread 1: '/oracle/u01/app/oracle/oradata/orcl/redo03.log'

        启动失败，丢失找不到日志文件redo03.log，数据库启动到mount状态

3       修复丢失的联机重做日志文件

SQL>alter database clear logfile group 3;

        

4       启动数据库

SQL>alter database open;

 

5       检查日志文件

        通过查看V$log视图和查看文件，新的日志文件已经生成。

 

丢失当前联机日志

        如果丢失当前联机日志文件，即使有备份也肯能会丢失数据。并且数据库在open状态，丢失在线日志文件会造成数据库的崩溃。

1       查询日志文件状态

SQL> select group#,thread#,sequence#,members,archived,status from v$log;       GROUP#    THREAD#  SEQUENCE#    MEMBERS ARC STATUS ---------- ---------- ---------- ---------- --- ----------------          1          1         13          1 YES INACTIVE          2          1         15          1 NO  CURRENT          3          1         14          1 YES INACTIVE

        

2       模拟丢失日志文件

SQL>shutdown abort; SQL>startup mount; [oracle@dev206 oracle]$ rm -rf /oracle/u01/app/oracle/oradata/orcl/redo02.log

        启动数据库    

SQL> alter database open; alter database open * ERROR at line 1: ORA-00313: open failed for members of log group 2 of thread 1 ORA-00312: online log 2 thread 1: '/oracle/u01/app/oracle/oradata/orcl/redo02.log' ORA-27037: unable to obtain file status Linux-x86_64 Error: 2: No such file or directory Additional information: 3

        启动失败，丢失找不到日志文件redo02.log

3       尝试直接修复丢失的联机重做日志文件

SQL> alter database clear logfile group 2; alter database clear logfile group 2 * ERROR at line 1: ORA-01624: log 2 needed for crash recovery of instance orcl (thread 1) ORA-00312: online log 2 thread 1: '/oracle/u01/app/oracle/oradata/orcl/redo02.log'

        此时由于丢失信息，无法正常恢复。

4       执行不完全恢复

        如果数据库开启归档并有备份，可以利用备份进行不完全恢复，会丢失数据。

        如果没有备份的情况下，只能强制恢复了，需要利用oracle的内置函数跳过一致性检查。

SQL>alter system set "_allow_resetlogs_corruption"=true scope=spfile; SQL>shutdown immediate; SQL>startup mount;

 

5       恢复数据库

SQL>recover database until cancel; ORA-00279: change 6078001 generated at 03/11/2013 13:42:25 needed for thread 1 ORA-00289: suggestion : /oracle/u01/app/oracle/oradata/orcl/archive/1_15_809543188.dbf ORA-00280: change 6078001 for thread 1 is in sequence #15     Specify log: {=suggested | filename | AUTO | CANCEL} cancel ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below ORA-01194: file 1 needs more recovery to be consistent ORA-01110: data file 1: '/oracle/u01/app/oracle/oradata/orcl/system01.dbf'     ORA-01112: media recovery not started SQL>alter database open resetlogs;

        此时数据库启动恢复完成

6       善后处理

        此时数据库虽然恢复完成，但是通过查看alert日志后可能会出现ORA-600的错误，包括SCN混乱或者undo表空间的错误等，造成这种问题的原因有数据库在丢失日志文件时的数据不一致，包括提交的数据未写入数据文件，未提交的数据写入了数据文件等情况。此时我们可以通过export数据后新建库在import新库来解决。

        鉴于日志文件的重要性，但是又没有日志文件的备份，一定要做好联机日志文件的冗余。

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

转载于:http://blog.itpub.net/26243632/viewspace-755836/