在NOCATALOG模式下，RMAN创建的备份信息都将保存在目标数据库的控制文件中，所以一旦控制文件丢失，不仅目标数据库崩溃，连RMAN的备份信息也尽数丢失，这种情况下，如果您有控制文件备份，那还有救（没有备份的话，也并非完全没有希望，如果DBA对自己的Oracle数据库非常了解，可以通过写脚本的方式重建控制文件。）
以下是归档模式下，控制文件丢失时的恢复，当然仍利用前面实验时的备份：
实验前首先需记下数据库的DBID：
1、模拟文件丢失，正在操作数据中：
跟之前实验一样，还是直接删除，当然删除之前仍要关闭数据库：
2、由于控制文件丢失，数据库不能打开，只能处于mount状态：
3、恢复控制文件，这里需要用到前面所记录的DBID了：
目标数据库控制文件丢失，无法启动到MOUNT状态，此处需首先设置指定DBID：
4、前面创建备份时都是在NOCATALOG模式下进行的，因此备份信息、备份设置等都是存储在目标数据库的控制文件中，现在控制文件丢失，相当于前面的一些配置也丢失了，用show all 命令查看，可见所有配置均恢复成了默认值：
5、此时恢复控制文件，不能直接使用RESTORE CONTROLFILE FROM AUTOBACKUP 命令，因为自动备份的设置也丢失了，并且此时也是在NOCATALOG模式下，无法配置CONTROLFILE AUTOBACKUP 的相关属性，因此选择显式指定控制文件备份集的方式恢复控制文件：
注意：指定控制文件时，最好找一个新一点的备份集。
6、有了控制文件，就可以将数据库置为MOUNT状态了：
7、由于只是控制文件丢失，数据文件仍在，因此并不需要对整个数据库进行修复操作，只需要执行RECOVER命令，重新应用备份的控制文件后生成的那些重做日志即可，执行RECOVER DATABASE 命令，再执行：ALTER DATABASE OPEN RESETLOGS
8、数据库可以打开了，查看一下数据是否还在：
OK，原来的数据又回来了！
通过上述实验，可知控制文件的重要性，所以做好备份是很有必要的！！'''''''''
本文转自pimg200551CTO博客，原文链接： http://blog.51cto.com/pimg2005/842310，如需转载请自行联系原作者
