丢失当前的联机重做日志文件(redo文件)

 

 

首先需要说明，如果当前的联机重做日志文件丢失，即使有备份，也肯定会丢失数据（运气好的话，也许不会丢失业务数据，不过这种机率非常非常小）。

1．模拟文件丢失

手动删除当前的联机重做日志文件（如何确定哪个重做日志文件才是当前状态，就不用再描述了吧），这里注意一点，数据库在打开状态时，丢失当前的联机重做日志文件会造成数据库崩溃，也就是数据库应该是处于不一致状态，为了尽可能贴近实际情况，这里在关闭数据库时通过SHUTDOWN ABORT方式关闭：

 
 
SQL> SHUTDOWN ABORT  
ORACLE instance shut down.  
SQL> STARTUP MOUNT;  
ORACLE instance started.  
Total System Global Area  167772160 bytes  
Fixed Size                  1295608 bytes  
Variable Size              83888904 bytes  
Database Buffers           75497472 bytes  
Redo Buffers                7090176 bytes  
Database mounted.  
SQL> host del F:\ORACLE\ORADATA\JSSBOOK\REDO03.LOG 

然后尝试启动数据库：

 
 
SQL> ALTER DATABASE OPEN;  
alter database open 
*  
ERROR at line 1:  
ORA-00313: open failed for members of log group 3 of thread 1  
ORA-00312: online log 3 thread 1: '  
F:\ORACLE\ORADATA\JSSBOOK\REDO03.LOG'  
ORA-27041: unable to open file  
OSD-04002: 无法打开文件  
O/S-Error: (OS 2) 系统找不到指定的文件。 

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

尝试通过ALTER DATABASE CLEAR LOGFILE命令修复丢失的重做日志文件：

 
 
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 3;  
alter database clear logfile group 3  
*  
ERROR at line 1:  
ORA-01624: log 3 needed for crash recovery of   
instance jssbook (thread 1)  
ORA-00312: online log 3 thread 1: 'F:\ORACLE\  
ORADATA\JSSBOOK\REDO03.LOG' 

根据错误信息可知，丢失的重做日志文件中包含必备的重做信息，无法被CLEAR。

3．执行不完全恢复

如果是归档模式并且有备份，建议通过备份进行不完全恢复，正常情况下只丢失当前联机重做日志文件中的数据。

如果没有备份，就只能强制恢复了。这里我们需要修改一个隐藏的初始化参数：

 
 
SQL> ALTER SYSTEM SET "_ALLOW_RESETLOGS_CORRUPTION"=  
TRUE SCOPE=SPFILE;  
System altered. 

_ALLOW_RESETLOGS_CORRUPTION是一个隐藏参数，设置该参数值为TRUE后，Oracle在OPEN时会跳过一些一致性的检查。

关闭并重新启动数据库到MOUNT状态：

 
 
SQL> SHUTDOWN IMMEDIATE  
ORA-01109: database not open 
Database dismounted.  
ORACLE instance shut down.  
SQL> startup mount  
ORACLE instance started.  
Total System Global Area  167772160 bytes  
Fixed Size                  1295608 bytes  
Variable Size              83888904 bytes  
Database Buffers           75497472 bytes  
Redo Buffers                7090176 bytes  
Database mounted. 

对数据库进行不完全恢复：

 
 
SQL> RECOVER DATABASE UNTIL CANCEL;  
ORA-00279: change 375734 generated at 05/04/2009   
15:41:22 needed for thread 1  
ORA-00289: suggestion : F:\ORACLE\ORADATA\JSSBOOK\ARCHIVE\  
ARC00039_0684946360.001  
ORA-00280: change 375734 for thread 1 is in sequence #39  
Specify log: {=suggested | filename | AUTO | CANCEL}  
cancel  
ORA-01547: warning: RECOVER succeeded but   
OPEN RESETLOGS would get error below  
ORA-01194: file 1 needs more recovery to be consistent  
ORA-01110: data file 1: 'F:\ORACLE\ORADATA\JSSBOOK\SYSTEM01.DBF' 
ORA-01112: media recovery not started  
通过OPEN RESETLOGS方式打开数据库：  
SQL> ALTER DATABASE OPEN RESETLOGS;  
Database altered. 

4．善后处理

这种恢复方式是没有办法中的办法，通过这种方式恢复，有可能会导致数据库中数据的不一致，如已提交的数据未写入数据文件，而未提交的数据倒是被写入了数据文件。即使数据库被打开，也能够访问其中的表和数据，也只是看起来正常，如果你注意关注数据库的Alert文件（默认路径在$ORACLE_BASE\admin\SID\bdump\alert_SID.log，注意替换上述路径中的SID为正确的SID），有可能其中已经报出了无数个ORA-00600的错误。因此，如果数据库能够顺利打开，强烈建议马上通过EXPORT逻辑导出的方式执行一次FULL EXPORT。然后新建数据库，再通过IMPORT导入之前导出的二进制文件。