数据库恢复之丢失联机重做日志文件的恢复

联机重做日志文件用来循环记录ORACLE数据库的所有操作，几乎时刻都在读写，因此单纯备份某个时间点的联机重做日志文件没有意义，恢复时根本用来上。RMAN的备份里根本就没有备份联机重做日志的功能，而且不止RMAN，所有的备份软件都没有备份联机重做日志文件的说法。因此，丢失联机重做日志后的数据库恢复也用不到RMAN。

如果ORACLE数据库在启动时发现丢失某一某一联机重做日志文件，则直接报错。ORACLE通过文件冗余的方式来确保联机重做日志文件的安全。即每组联机重做日志创建 
多个文件，至少两个，每个文件的路径可心各自独立。
运行中的ORACLE数据库对联机重做日志文件进行锁定，无法通过操作系统命令删除。因此丢失的文件大多数情况下是由于磁盘损坏造成的。
联机重做日志文件大致分为两种状态：当前正在写和当前没有在写的。
=================================
联机重做日志文件信息查询：

SQL> SELECT GROUP#,THREAD#,SEQUENCE#,MEMBERS,ARCHIVED,STATUS FROM V$LOG;

GROUP# THREAD# SEQUENCE# MEMBERS ARCHIVED STATUS

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

1 1 1 1 YES INACTIVE

2 1 2 1 NO CURRENT

3 1 0 1 YES UNUSED

4 1 0 1 YES UNUSED

联机重做日志文件的状态，从上面的SQL语句查询结果可看出。
其中STATUS共有6种可选值：
UNUSED:表示从未用过，一般刚创建或是OPEN RESETLOGS打开后，联机重做日志文件就是这种状态。
ACTIVE:表示活动的。虽然不是当前状态，但也有可能正在被使用或是要被使用。如CRASH RECOVERY时可能存在这种状态。
CLEARING:日志正在被清空。当执行ALTER DATABASE CLEAR LOGFILE语句时，就是这种状态。执行完后，状态变为UNUSED。
CLEARING_CURRENT:日志正在被清空。日志存在被清空，如果清空时出错，导致清空工作不能顺利完成，则该日志就会处于这种状态。
INACTIVE:不活动状态，表示该组日志中的内容已被归档或顺利写入数据文件，该组日志可被继续使用。

SQL> SELECT GROUP#,STATUS,TYPE,MEMBER FROM V$LOGFILE ORDER BY GROUP#;

GROUP# STATUS TYPE MEMBER

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

1 ONLINE D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO01.LOG

2 ONLINE D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO02.LOG

3 ONLINE D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO03.LOG

4 ONLINE D:\TESTADDLOG.LOG

从上面的查询结果可看出，当前ORACLE数据库共4组联机重做日志，每组才一个成员文件。
GROUP2为当前正在被使用。GROUP2对应的会员D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO02.LOG，就是当前的联机重做日志文件。其它3组为非当前的联机重做日志文件。
=================================
1、丢失非当前的联机重做日志文件
1.1 删除非当前的联机重做日志文件，并进行恢复。
SQL> shutdown immediate;--先shutdown数据库，再删除文件。
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> host del D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO01.LOG --删除非当前的联机重做日志文件GROUP1的成员文件。

1.2 startup启动数据库

SQL> startup

ORACLE 例程已经启动。



Total System Global Area 647204864 bytes

Fixed Size 2178536 bytes

Variable Size 478151192 bytes

Database Buffers 159383552 bytes

Redo Buffers 7491584 bytes

数据库装载完毕。

ORA-03113: 通信通道的文件结尾

进程 ID: 5896

会话 ID: 9 序列号: 3

------------有报错，未正常启动数据库。此时数据库处于mount状态。

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

SQL> startup mount;

SQL> conn sys/rusky1234@orcl as sysdba;

已连接。



SQL> alter database clear logfile group 1;--通过ALTER DATABASE CLEAR LOGFILE命令重建该组联机重做日志文件。



数据库已更改。



SQL> alter database open;



数据库已更改。

----------------------------------------
说明：对于非当前的联机重做日志文件损坏，修复过程非常简单，并且操作安全，不会造成数据丢失。
在数据库运行过程中，非当前的联机重做日志文件丢失或损坏并不一定会导致数据库崩溃，因为非当前的文件并未被用到，数据库还能够正常运行。如果数据库切
换到损坏的联机重做日志文件，就会报错。
========================================

2、丢失当前的联机重做日志文件
丢失当前的联机重做日志文件，即使有备份，也肯定会丢失数据。
2.1 删除当前的联机重做日志文件，并启动到Mount状态。

SQL> shutdown immediate;

SQL> host del D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO02.LOG --删除当前的联机重做日志文件GROUP2的成员文件。

SQL> startup

ORACLE 例程已经启动。



Total System Global Area 647204864 bytes

Fixed Size 2178536 bytes

Variable Size 478151192 bytes

Database Buffers 159383552 bytes

Redo Buffers 7491584 bytes

数据库装载完毕。

ORA-03113: 通信通道的文件结尾

进程 ID: 1008

会话 ID: 162 序列号: 5



SQL> startup mount;

ORACLE 例程已经启动。



Total System Global Area 647204864 bytes

Fixed Size 2178536 bytes

Variable Size 478151192 bytes

Database Buffers 159383552 bytes

Redo Buffers 7491584 bytes

数据库装载完毕。



SQL> conn sys/rusky1234@orcl as sysdba;

已连接。

2.2 尝试直接修复联机重做日志文件

SQL> alter database clear logfile group 2;

alter database clear logfile group 2

*

第 1 行出现错误:

ORA-00350: 日志 2 (实例 orcl 的日志, 线程 1) 需要归档

ORA-00312: 联机日志 2 线程 1: 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO02.LOG'

---------------有报错，丢失的重做日志文件包含必备的重做信息，无法被CLEAR.

2.3 执行不完全恢复
如果是归档模式并且有备份，可通过备份进行不完全恢复，正常情况下只丢失当前联机重做日志文件中的数据。
如果没有备份，只能强制恢复。必须修改一个隐藏的初始化参数：

SQL> ALTER SYSTEM SET "_ALLOW_RESETLOGS_CORRUPTION"=TRUE SCOPE=SPFILE; --设置该参数值为TRUE后，ORACLE在OPEN时会跳过一些一致性的检查。

系统已更改。

SQL> select status from v$instance;



STATUS

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

MOUNTED



SQL> recover database until cancel;

完成介质恢复。



SQL> alter database open resetlogs;

数据库已更改。

2.4 善后处理
如果没有备份，上述的处理方法也是最可行的一种方法。通过这种修复，也很可能导致数据库的数据不一致。如已提交的数据未写到到数据文件，而未提交的数据
倒是被写入到了数据文件。即使数据库能正常打开，并能正常访问，但是其告警日志文件也有很多报错信息。此时最好EXPORT逻辑导出的方式执行一次FULL EXPORT ，然后新建数据库，再IMPORT之前导出的文件内容。

Recovering After Losing All Members of an Online Redo Log Group If a media failure damages all members of an online redo log group, then different scenarios can occur depending on the type of online redo log group affected by the failure and the archiving mode of the database. If the damaged online redo log group is current and active, then it is needed for crash recovery; otherwise, it is not.
Recovering After the Loss of an Online Redo Log Group Inactive
It is not needed for crash recovery Clear the archived or unarchived group.
Active
It is needed for crash recovery Attempt to issue a checkpoint and clear the log; if impossible, then you must either use Flashback Database or restore a backup and perform incomplete recovery up to the most recent available redo log.
Current
It is the redo log that the database is currently writing to Attempt to clear the log; if impossible, then you must either use Flashback Database or restore a backup and perform incomplete recovery up to the most recent available redo log.