【Oracle笔记】在线日志文件的恢复方法

重做日志文件(redo log file)是Oracle数据库中至关重要的事务日志,是数据库崩溃恢复的重要依据,通常用于以下几个方面:

  • 实例恢复。
  • 维护DATAGUARD中的备库(standby)。
  • 通过备份恢复介质故障。
  • 用于日志挖掘,可以将其复制或输出到流中。

重做日志文件可以分为在线(online)日志文件和归档(archived)日志文件两种类别,归档日志文件作为在线日志文件的一个备份,它的产生取决于数据库是否开启归档模式(archivelog);那么日志文件这么重要,要是出现介质故障怎么办呢?这里就来浅谈一下关于在线日志文件的恢复方法。

实验环境:linux 5.2 +  Oracle Database 11.2.0.1.0

 

首先来看看日志文件的几种状态,可以通过查询v$log视图的status字段获取状态信息:

SYS@db11g>select group#,members,thread#,sequence#,status,archived from v$log;

    GROUP#    MEMBERS    THREAD#  SEQUENCE# STATUS           ARC
---------- ---------- ---------- ---------- ---------------- ---
         1          2          1        226 INACTIVE         YES
         2          2          1        227 CURRENT          NO
         3          2          1        225 INACTIVE         YES

这里我开启了归档模式,有三个日志组,每组两个日志文件,可以看到现在的在线日志文件只有两种状态(INACTIVE,CURRENT)联机日志状态通常有以下几种:

  1. CURRENT - 当前正在被LGWR使用的group(同时是ACTIVE状态),其中记载数据库中正在进行的更改,删除将导致恢复时数据丢失。
  2. ACTIVE - 活动的日志文件状态,日志完成切换或等待检查点事件时都可能出于这种状态,不是CURRENT的日志但是实例恢复时是需要的,此时的日志有可能已经完成了归档,即将变成INACTIVE状态,或者日志文件在等待Checkpoint事件没有完成归档。
  3. INACTIVE - 非活动的日志状态,此时的日志实例恢复时不再需要,可能已经归档。
  4. UNUSED - 尚未记录change的空白日志组,一般会出现在add logfile, resetlogs打开数据库或者使用了clear logfile命令后。
  5. CLEARING - 表示该组重做日志文件正在被ALTER DATABASE CLEAR LOGFILE语句重建中(重建后状态会变成unused)。
  6. CLEARING_CURRENT - 表示该组重做日志文件重建时出现错误,出现对日志文件的I/O故障就会出现这种状态。

 

丢失某个日志组中的某个member

这种情况在日志多路复用的情况下是不影响数据库使用的,所以建议日志组的成员数至少2个。

 

归档模式丢失日志组(整个日志组):

    在归档模式下,如果丢失了非CURRENT日志组,这会在日志切换时因无法归档导致数据库hang住,这时需要使用 ALTER DATABASE CLEAR LOGFILE 语句重新创建组中的成员,这样不会影响任何事务处理。

    如果日志已经归档,一般只需要clear就可以重建该日志文件,但是如果该数据库处于归档状态但该日志组还没有归档,就需要使用alter database clear unarchived logfile强行clear,强制clear没有归档的日志组建议在操作后立即对数据库执行新的完全备份,因为日志已丢失,所有日志丢失之前的恢复将失效。

操作演示:

SYS@ORA10G>!rm -rf /u01/app/oracle/oradata/ORA11G/redo03*

SYS@db11g>startup mount;
ORACLE instance started.

Total System Global Area  521936896 bytes
Fixed Size                  2214936 bytes
Variable Size             423625704 bytes
Database Buffers           92274688 bytes
Redo Buffers                3821568 bytes
Database mounted.

SYS@db11g>alter database clear logfile group 3;
alter database clear logfile group 3
*
ERROR at line 1:
ORA-00350: log 3 of instance db11g (thread 1) needs to be archived
ORA-00312: online log 3 thread 1: '/u01/app/oracle/oradata/db11g/redo03.log'
ORA-00312: online log 3 thread 1: '/u01/app/oracle/oradata/db11g/redo03_b.log'

SYS@db11g>alter database clear unarchived logfile group 3;

Database altered.

SYS@db11g>alter database open;

Database altered.

 

非归档模式丢失CURRENT日志组

    无归档,无备份,一旦当前的重做日志文件损坏,Oracle是不允许数据库打开的,这是极端的故障,不过用户希望强制打开数据库挽回数据丢失,也就是忽略一致性打开数据库,针对这种情况可以使用_allow_resetlogs_corruption参数尝试修复,模拟一下环境:

1,mount状态下查看日志状态

SYS@db11g>startup mount;

ORACLE instance started.

 

Total System Global Area  521936896 bytes

Fixed Size                  2214936 bytes

Variable Size             423625704 bytes

Database Buffers           92274688 bytes

Redo Buffers                3821568 bytes

Database mounted.

 

SYS@db11g>select group#,members,thread#,sequence#,status,archived from v$log;

 

    GROUP#    MEMBERS    THREAD#  SEQUENCE# STATUS           ARC

---------- ---------- ---------- ---------- ---------------- ---

         1          2          1        244 CURRENT          NO

         3          2          1          0 UNUSED           NO

         2          2          1        243 INACTIVE         NO

 

2,这个时候干掉current日志组

SYS@db11g>! rm -rf /u01/app/oracle/oradata/db11g/redo01*

 

3,打开数据库报错

SYS@db11g>alter database open;

alter database open

*

ERROR at line 1:

ORA-03113: end-of-file on communication channel

Process ID: 31815

Session ID: 1 Serial number: 5

 

查看alert日志

Additional information: 3

ORA-00312: online log 1 thread 1: '/u01/app/oracle/oradata/db11g/redo01.log'

ORA-27037: unable to obtain file status

Linux-x86_64 Error: 2: No such file or directory

Additional information: 3

Errors in file /u01/app/oracle/diag/rdbms/db11g/db11g/trace/db11g_ora_31815.trc:

ORA-00313: open failed for members of log group 1 of thread

ORA-00312: online log 1 thread 1: '/u01/app/oracle/oradata/db11g/redo01.log'

ORA-00312: online log 1 thread 1: '/u01/app/oracle/oradata/db11g/redo01_b.log'

USER (ospid: 31815): terminating the instance due to error 313

Instance terminated by USER, pid = 31815

此时数据库实例已经down下来了。

 

设置_allow_resetlogs_corruption参数方式打开数据库:

1,创建参数文件

SYS@db11g>create pfile from spfile;

 

File created.

 

2,添加参数如下

*._allow_resetlogs_corruption=true

 

3,resetlog起库,之前需要执行recover动作

SYS@db11g>conn / as sysdba

Connected to an idle instance.

 

SYS@db11g>create pfile from spfile;

File created.

 

SYS@db11g>startup mount;

ORACLE instance started.

 

Total System Global Area  521936896 bytes

Fixed Size                  2214936 bytes

Variable Size             423625704 bytes

Database Buffers           92274688 bytes

Redo Buffers                3821568 bytes

Database mounted.

SYS@db11g>alter database open resetlogs;

alter database open resetlogs

*

ERROR at line 1:

ORA-01139: RESETLOGS option only valid after an incomplete database recovery

 

SYS@db11g>recover database until cancel;

Media recovery complete.

 

SYS@db11g>alter database open resetlogs;

Database altered.

 

通常这个起库过程都会伴随一系列的ora-600的,此时需要使用别的手段继续进行调整恢复,如导出数据,值得注意的是这种resetlogs打开数据库方式跳过了一致性检查,数据库可能已经损坏,所以建议在执行使用_allow_resetlogs_corruption参数强制打开数据库之前备份数据库,防止恢复失败,备份重于一切!!

posted @ 2012-10-31 21:21  beanbee  阅读(7899)  评论(0编辑  收藏  举报