一.丢失inactive日志文件组的恢复：

由于inactive日志文件组表示已经完成了检查点（dirty数据已经被写入数据文件）。数据库本身不会发生数据库丢失，
如果在这个时候redo丢失，可以通过clear重建日志文件组恢复。
通过命令:
alter database clear logfile group n
如果数据库模式是archived的，则需要强制清除
alter database clear unarchived logfile group n

二.丢失active或current日志文件组的恢复：

丢失情况分两种，一个是正常关闭数据库(如shutdown immediate)，另一个是异常关闭数据库(如shutdown abort)

1.在损失当前日志时，数据库是正常关闭状态。
shutdown immediate会执行全面的checkpoint，所以当前日志在实例恢复时可以不需要redo
在Oracle 8i中我们完全可以通过alter database clear logfile group n来进行恢复
但是在Oracle 9i中，则可能无法对current的redo日志进行clear,需要通过recover database until cancel恢复后，用resetlogs选项打开。
比如：
alter database clear logfile group n
recover database until cancel;
alter database open resetlogs;

2.在损失当前日志时，数据库是异常关闭的：
这种情况下，由于没有在执行全面检查点时，数据库就已经关闭了，那么Oracle在进行实例恢复的时候必须要求当前的日志，否则Oracle数据库将无法open.
这样的情况下，我们通常需要从备份中恢复数据文件，通过应用归档日志进行向前推演。直到最后一个完好的日志文件，然后可以通过resetlogs启动数据库完成恢复。那么丢失的数据则是被损坏的日志文件中的数据。
注意：_allow_resetlogs_corruption是Oracle中的一个隐含参数，如果系统实在不能resetlogs方式打开的后只能出此下策，在pfile进行相应设置打开数据库。该函数的含义是，允许在破坏一致性的情况下强制重置日志，打开数据库。_allow_resetlogs_corruption将使用所有数据文件最旧的SCN打开数据库，所以通常来讲需要保证SYSTEM表空间拥有最旧的SCN。在强制打开数据库之后，可能因为各种原因会有ora-600错误的出现，因此Oracle公司不对此设置负任何责任：）

使用另外一个隐含参数_allow_resetlogs_corruption强制启动数据库，设置此参数之后，在数据库Open过程中，Oracle会跳过某些一致性检查，从而使数据库可能跳过不一致状态，Open打开:
SQL> alter system set "_allow_resetlogs_corruption"=true scope=spfile;

System altered.

SQL> shutdown immediate;
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.

Total System Global Area   97588504 bytes
Fixed Size                   451864 bytes
Variable Size              33554432 bytes
Database Buffers           62914560 bytes
Redo Buffers                 667648 bytes
Database mounted.
SQL> recover database using backup controlfile until cancel;
ORA-00279: change 897612315 generated at 10/19/2005 16:54:18 needed for thread 1
ORA-00289: suggestion : /opt/oracle/oradata/conner/archive/1_160.dbf
ORA-00280: change 897612315 for thread 1 is in sequence #160

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: '/opt/oracle/oradata/conner/system01.dbf'

ORA-01112: media recovery not started

SQL> alter database open resetlogs;

Database altered.

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area   97588504 bytes
Fixed Size                   451864 bytes
Variable Size              33554432 bytes
Database Buffers           62914560 bytes
Redo Buffers                 667648 bytes
Database mounted.
Database opened.
 

幸运的时候数据库就可以成功Open，如果不幸可能会遇到一系列的Ora-600错误（最常见的是2662错误）此时就需要使用多种手段继续进行调整恢复。
如果注意观察alert日志，我们可能会发现类似以下日志:
Fri Jun 10 16:30:25 2005
alter database open resetlogs
Fri Jun 10 16:30:25 2005
RESETLOGS is being done without consistancy checks. This may result
in a corrupted database. The database should be recreated.
RESETLOGS after incomplete recovery UNTIL CHANGE 240677200
Resetting resetlogs activation ID 3171937922 (0xbd0fee82)
 

Oracle告诉我们，强制resetlogs跳过了一致性检查，可能导致数据库损坏，数据库应当重建。
不一致恢复最后恢复到的Change号是：240677200

通常使用此方法Open数据库之后，应该立即通过导出、导入重建数据库。