========================== RMAN-03002: failure of recover command at 09/19/2014 15:22:07 RMAN-06054: media recovery requesting unknown log: thread 1 seq 5 lowscn 1001295
使用的是最新的控制文件恢复的数据库文件，首先会把所有可以获得的归档日志文件扫一遍，然后用归档日志对数据库文件进行前滚，一直到最后提示要求一个位置归档日志文件，实际上这个归档是不存在的，而Oracle以为还会有下一个，因为是之前是abort关闭数据库的，如果在我们把刚才的3号日志组文件刷到归档后，数据库又有别的操作，而这些操作还没有写到归档日志的话，那么这部分数据就只能丢失了，相当于做了一个不完全恢复
--打开数据库 RMAN> alter database open;
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of alter db command at 09/19/2014 15:22:41 ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
可以看到，由于是执行了不完全恢复，必须用resetlogs来打开数据库
RMAN> alter database open resetlogs;
database opened
RMAN> exit
Recovery Manager complete. [oracle@ora10g backupsets]$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.1.0 - Production on 9 15:23:56 2014
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production With the Partitioning, OLAP and Data Mining options
--检验测试数据 SQL> set lin 130 pages 130
SQL> col name for a15 SQL> select * from zlm.test2;
ID NAME ---------- --------------- 20 ICOL$ 44 I_USER1 28 CON$
可以看到，之前的测试数据由于被人为地写入了归档，因此并未丢失，而那些未归档的部分，无奈只能丢失，这个测试也再一次证明了归档日志文件的重要性，有了数据库全备+全部归档日志，即使把数据库的数据库文件、控制文件、online日志文件全删除，还是可以恢复回来的，如果能保证online日志未丢失，仅仅删除控制文件和数据文件，那么是会有一定几率零数据丢失的（内存中的数据及时写入到online日志的情况下）
|