首页 > 代码库 > 数据库恢复之丢失联机重做日志文件的恢复
数据库恢复之丢失联机重做日志文件的恢复
联机重做日志文件用来循环记录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 INACTIVE2 1 2 1 NO CURRENT3 1 0 1 YES UNUSED4 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.LOG2 ONLINE D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO02.LOG3 ONLINE D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO03.LOG4 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> startupORACLE 例程已经启动。Total System Global Area 647204864 bytesFixed Size 2178536 bytesVariable Size 478151192 bytesDatabase Buffers 159383552 bytesRedo 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> startupORACLE 例程已经启动。Total System Global Area 647204864 bytesFixed Size 2178536 bytesVariable Size 478151192 bytesDatabase Buffers 159383552 bytesRedo Buffers 7491584 bytes数据库装载完毕。ORA-03113: 通信通道的文件结尾进程 ID: 1008会话 ID: 162 序列号: 5SQL> startup mount;ORACLE 例程已经启动。Total System Global Area 647204864 bytesFixed Size 2178536 bytesVariable Size 478151192 bytesDatabase Buffers 159383552 bytesRedo 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------------MOUNTEDSQL> recover database until cancel;完成介质恢复。SQL> alter database open resetlogs;数据库已更改。
2.4 善后处理
如果没有备份，上述的处理方法也是最可行的一种方法。通过这种修复，也很可能导致数据库的数据不一致。如已提交的数据未写到到数据文件，而未提交的数据
倒是被写入到了数据文件。即使数据库能正常打开，并能正常访问，但是其告警日志文件也有很多报错信息。此时最好EXPORT逻辑导出的方式执行一次FULL EXPORT
，然后新建数据库，再IMPORT之前导出的文件内容。
数据库恢复之丢失联机重做日志文件的恢复