这个实验是在有备份的情况下进行的，并且部分归档日志在备份后已经被删除掉了,那么先在服务器上执行一个全库的备份：

rman target  /
backup database format '/backup/db_%U.bak' current controlfile format '/backup/cf_%U.bak' plus archivelog format '/backup/ar_%U.bak' delete all input;


备份ok后,把数据文件.控制文件都删掉

cd /oracle/10/oradata/test10g
rm -rf *.dbf
rm -rf *.ctl


将数据库强制停下来

sqlplus /nolog
conn / as sysdba
shutdown abort


将数据库启到nomount状态

startup nomount;


先从备份集中还原控制文件

restore controlfile from '/backup/cf_0uokr5oj_1_1.bak';


将数据库启到mount状态

alter database mount;


还原数据文件

restore database;


恢复数据库

recover database;


这个时候会发现，rman会报出一个错误：

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 09/26/2013 16:19:48
RMAN-06054: media recovery requesting unknown log: thread 1 seq 46 lowscn 644796

在介质恢复的过程中无法找到序列为46的日志

也就是说，出现了日志丢失的情况，但是在实验的过程中并没有删除redo和没有备份的归档，那么问题就应该是出在归档的备份上

先来观察一下之前的备份命令执行时，rman进行备份的步骤:

1.备份现有的归档日志
2.备份数据
3.备份控制文件
4.进行日志切换
5.对日志切换后生成的归档进行备份


很明显，3.4.5步应该就是问题的关键，rman先对控制文件进行了备份，再进行日志的切换，在最后一步才对新生成的归档进行了备份

4.5两步操作的目的是为了对备份期间所产生的数据块变化也进行备份，来保证整个备份的完整性

但是由于先对控制文件进行了备份，后备份的归档，所以最后一次归档的备份信息，在控制文件的备份中是没有记录的

也就导致了rman无法找到这个归档的情况，解决这个问题有2种方法：

1.在备份之初，备份完成后再生成一个控制文件的备份

backup current controlfile format '/backup/cf_%U.bak';

2.让当前的控制文件再加载一次备份集信息

catalog start with '/backup/';


这时再重新做一次数据库恢复就可以顺利完成介质恢复了

recover database;


最后打开数据库即可

这个实验的关键点是备份之后没有手工再生成一个备份和catalog start with 的用法，在一些集成公司或第三方支持服务公司工作的dba，往往
在数据库备份上并不是自己制定的脚本，当故障突然来临时，需要用别人生成的备份来对数据库进行恢复，就有可能遇到这样的问题。