第三种场景略微复杂。
如果存在备份，但是备份集出现了一些问题，或者出现了一些归档文件的缺失，restore可以顺利完成，但是在recover的时候会报出下面的错误来。
RMAN> recover database;
Starting recover at 02-AUG-15
using channel ORA_DISK_1
using channel ORA_DISK_2
starting media recovery
unable to find archived log
archived log thread=1 sequence=1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 08/02/2015 12:26:43
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 1 and starting SCN of 1094536
这种情况下采用基于sequence的不完全恢复也没有基础。
如果这个时候我们无招可用，看看resetlogs的方式能不能启动数据库，会有下面的错误。
RMAN> alter database open resetlogs;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of alter db command at 08/02/2015 12:28:06
ORA-01152: file 3 was not restored from a sufficiently old backup
ORA-01110: data file 3: '/u02/ora11g/oradata/TEST/undotbs01.dbf'
可见还是备份集出现一些问题，主要原因还是控制文件中记录的scn号和备份集中的scn出现了gap,尝试恢复的时候又没有相应的归档。
我们可以采用隐含参数来做，
在pfile中加入下面的三个隐含参数
_allow_resetlogs_corruption=true
_corrupted_rollback_segments=true
_offline_rollback_segments=true
然后，重新启动数据库到mount阶段之后，使用resetlogs的方式即可强制打开数据库。
这种方式存在着一定的风险，但是也是无奈的场景下的一种方式。毕竟数据库能够open是一个很重要的检查点，数据库都启动不了的话，整个恢复的意义就会大打折扣了。
所以通过上面的三个简单的例子，可以看到在数据的不完全恢复中，还是有很多的选择，不完全恢复相对于完全恢复来说，场景真是数不胜数，各种破坏各种坑。合理利用手中的备份是我们数据恢复的一个基础。
--------------------------------------推荐阅读 --------------------------------------
--------------------------------------分割线 --------------------------------------