oracle error 1552,ORACLE基础学习-RMAN应用-控制文件恢复

在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，原来的数据又回来了！

通过上述实验，可知控制文件的重要性，所以做好备份是很有必要的！！