模拟一个数据库非归档模式中控制文件丢失如何恢复(数据库备份与恢复的初学者）...

下面我们模拟一个数据库非归档模式中控制文件丢失如何恢复的过程

我们现在模拟数据库在非归档模式下丢失control文件（只丢失一个控制文件的解决方法）

现在我们删除控制文件

控制文件已经删除 下面我们启动数据库 看数据库报什么错误。

数据库启动报错 error in identifying control file check alert log for more info 数据库控制文件错误 检查警告日志文件 我们打开警告日志文件（这点很重要对于数据库管理员来讲 必须清楚的指导 alter警告日志的位置）

这是我的警告日志文件位置 不通版本的数据库 警告日志位置不通注意区分 我们打开alter_orcl.log （警告日志文件）用vi 编辑器打开查看即可（在下面可以看到我的警告日志是5124行 直接键入：5124到5124行可以看到）

很明显报错 error ora-00210 00202是无法打开指定的控制文件ol_mf_7m0w7cfm_.ctl文件 我们查看目录

确实不存在改控制文件 但是我们数据库一般而言 并不是只有一个控制文件存在的 （作为一名合格的数据库管理员应该知道 在一个数据库中应该最少有三个或者以上的控制文件存在于数据库中

在笔者的数据库中就有三个控制文件  还有两个幸存的控制文件 那么我们就复制一份其他的控制文件到 缺少的控制文件试试看能不能恢复。

用备用的控制文件拷贝到丢失的控制文件 然后我们试着启动数据到mount状态我们先强制关闭数据库;

OK我们已经成功的启动到mount状态了 这说明我们的控制文件已经可以用了，然后我们直接open一下试试看;

好我们的数据库正常启动起来了 数据也可以正常查询 为此我们化解了这次数据库的危机（我们在此讲得只是数据库启运行时或者启动时 某一个控制文件丢失 但是幸运的是我们还有其他的控制文件 我们通过查看警告日志来读取数据库究竟报了什么错误，然后根据警告日志来恢复，笔者认为在通常的生产数据库中 数据库必须处于归档模式才能保证数据的正常工作。如果该数据库中的控制文件只有一个的话 我们就只能重建控制文件了，如果重建控制文件我们必须知道我们的数据文件名字 和位置 及其重做日志组和成员的位置 控制文件的位置及其大小。所以笔者建议无论是练习 还是实际的生产库中 应该经常的对数据文件，日志文件，控制文件等等做全集的物理备份 （当然在错误出现以后一定先要进行全局的物理备份无论是冷备份 还是rman都应该先给予备份才能做resore 和recovery的工作）