重做日志文件（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参数强制打开数据库之前备份数据库，防止恢复失败，备份重于一切！！