【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）联机日志状态通常有以下几种：

CURRENT - 当前正在被LGWR使用的group(同时是ACTIVE状态)，其中记载数据库中正在进行的更改，删除将导致恢复时数据丢失。
ACTIVE - 活动的日志文件状态，日志完成切换或等待检查点事件时都可能出于这种状态，不是CURRENT的日志但是实例恢复时是需要的，此时的日志有可能已经完成了归档，即将变成INACTIVE状态，或者日志文件在等待Checkpoint事件没有完成归档。
INACTIVE - 非活动的日志状态，此时的日志实例恢复时不再需要，可能已经归档。
UNUSED - 尚未记录change的空白日志组，一般会出现在add logfile， resetlogs打开数据库或者使用了clear logfile命令后。
CLEARING - 表示该组重做日志文件正在被ALTER DATABASE CLEAR LOGFILE语句重建中（重建后状态会变成unused）。
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 阅读(8002) 评论(0) 编辑收藏举报

刷新页面返回顶部

Beanbee

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