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

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

1．模拟文件丢失

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

1. SQL>SHUTDOWNABORT
2. ORACLEinstanceshutdown.
3. SQL>STARTUPMOUNT;
4. ORACLEinstancestarted.
5. TotalSystemGlobalArea167772160bytes
6. FixedSize1295608bytes
7. VariableSize83888904bytes
8. DatabaseBuffers75497472bytes
9. RedoBuffers7090176bytes
10. Databasemounted.
11. SQL>hostdelF:\ORACLE\ORADATA\JSSBOOK\REDO03.LOG

然后尝试启动数据库：

1. SQL>ALTERDATABASEOPEN;
2. alterdatabaseopen
3. *
4. ERRORatline1:
5. ORA-00313:openfailedformembersofloggroup3ofthread1
6. ORA-00312:onlinelog3thread1:'
7. F:\ORACLE\ORADATA\JSSBOOK\REDO03.LOG'
8. ORA-27041:unabletoopenfile
9. OSD-04002:无法打开文件
10. O/S-Error:(OS2)系统找不到指定的文件。

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

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

1. SQL>ALTERDATABASECLEARLOGFILEGROUP3;
2. alterdatabaseclearlogfilegroup3
3. *
4. ERRORatline1:
5. ORA-01624:log3neededforcrashrecoveryof
6. instancejssbook(thread1)
7. ORA-00312:onlinelog3thread1:'F:\ORACLE\
8. ORADATA\JSSBOOK\REDO03.LOG'

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

3．执行不完全恢复

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

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

1. SQL>ALTERSYSTEMSET"_ALLOW_RESETLOGS_CORRUPTION"=
2. TRUESCOPE=SPFILE;
3. Systemaltered.

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

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

1. SQL>SHUTDOWNIMMEDIATE
2. ORA-01109:databasenotopen
3. Databasedismounted.
4. ORACLEinstanceshutdown.
5. SQL>startupmount
6. ORACLEinstancestarted.
7. TotalSystemGlobalArea167772160bytes
8. FixedSize1295608bytes
9. VariableSize83888904bytes
10. DatabaseBuffers75497472bytes
11. RedoBuffers7090176bytes
12. Databasemounted.

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

1. SQL>RECOVERDATABASEUNTILCANCEL;
2. ORA-00279:change375734generatedat05/04/2009
3. 15:41:22neededforthread1
4. ORA-00289:suggestion:F:\ORACLE\ORADATA\JSSBOOK\ARCHIVE\
5. ARC00039_0684946360.001
6. ORA-00280:change375734forthread1isinsequence#39
7. Specifylog:{=suggested|filename|AUTO|CANCEL}
8. cancel
9. ORA-01547:warning:RECOVERsucceededbut
10. OPENRESETLOGSwouldgeterrorbelow
11. ORA-01194:file1needsmorerecoverytobeconsistent
12. ORA-01110:datafile1:'F:\ORACLE\ORADATA\JSSBOOK\SYSTEM01.DBF'
13. ORA-01112:mediarecoverynotstarted
14. 通过OPENRESETLOGS方式打开数据库：
15. SQL>ALTERDATABASEOPENRESETLOGS;
16. Databasealtered.

4．善后处理

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