首先连上数据库,查看控制文件所在路径
然后查看两个控制文件的详细信息
可以看到,两个数据库控制文件的详细信息一致,包括大小,用户组,读写权限等。
修改其中一个控制文件的名字,模拟控制文件丢失
这里发现一个有意思的现象,在控制文件破坏之前已经建立的连接在操作时不受影响,即使是从控制文件查询数据库信息:
但是,用sqlplus重新建立的连接,操作就直接报错了:
当然,数据库还在提供服务,做一些和控制文件无关的操作都是可以支持的:
但是查看alert日志,也是可以看到已经有报错信息输出了
这种控制文件丢失的情况并不是很严重,按照下面操作步骤就能完美恢复控制文件:
1.关闭数据库实例
2.将正常的控制文件拷贝至丢失的控制文件所在位置
3.启动数据库实例
4.执行语句检查数据库是否恢复正常
至此,数据库恢复正常。如果数据库做了控制文件多路复用,然后出现其中部分控制文件丢失的情况,都可以用该方法进行恢复。简单的总结,就是在数据库关闭的情况下,用正常的控制文件去替换丢失的控制文件,然后启动即可。
首先关闭数据库
然后将其中一个控制文件重命名,模拟控制文件丢失
启动数据库,发现报错
查看trace日志文件
然后可以打开trace日志文件,找到数据库启动时候的参数信息:
根据数据库启动时的参数信息,可以进行控制文件恢复。处理故障的方法就和第一种情况类似,先关闭数据库,然后用正常的控制文件去替换丢失的控制文件,然后启动数据库后进行验证即可。
将所有控制文件都重命名,模拟全部控制文件丢失
用sqlplus打开一个新的连接,从控制文件查看数据库信息,做一些结构化变更,包括:
l 添加,删除或重命名数据文件
l 添加或删除表空间,或更改表空间的读/写状态
l 添加或删除重做日志文件或重做日志组
这里为了操作简单,修改表空间的读/写状态:
在进行结构化变更操作之后,数据库连接被自行断开了,不过如果再建立一个连接,还是可以进行数据库的增删改查操作的:
不只是增删改查操作,只要不要涉及到控制文件的读写,还可以进行其他操作,比如drop table之后从recyclebin恢复删除的表:
Oracle数据库在控制文件全部丢失的情况下,还能提供那么多服务,已经很了不起了。现在,我们最重要的事情就是恢复控制文件,保证数据库所有功能都可以正常运行,操作步骤如下:
1.列出数据库的所有数据文件和重做日志文件。
首先尝试用数据库视图查看:
用不了V$LOGFILE和V$DATAFILE视图,这里选择去服务器上查找数据库的所有数据文件和重做日志文件,如果没有调整过的话,数据文件和控制文件在路径$ORACLE_BASE/oradata/$ORACLE_SID下面:
对于表空间,为了防止落下,先查看有哪些表空间:
将获取到的数据文件和重做日志文件整理成列表:
2.关闭数据库。
3.备份数据库的所有数据文件和重做日志文件。
4.启动一个新的实例,但不要挂载或打开数据库:
5.使用CREATE CONTROLFILE语句为数据库创建一个新的控制文件。
提示错误:
这里去掉CREATE CONTROLFILE语句里面的临时表空间
看到提示“Control file created.”
查看数据库的状态,可以看到数据库成功切换为mount状态
5.正常打开数据库,必要时进行数据库恢复,然后再打开数据库。
6.进行简单的数据库检查,修复一些未处理的问题。
检查trace日志文件
发现ORA-25153错误,查看临时表空间视图:
为数据库添加临时表空间,文件已经存在,使用reuse语句复用即可:
数据库现已打开并可用。
这种情况下的处理方法和第三种情况基本一致,只是如果控制文件没有恢复好,数据库是不能对外提供服务的。但是第三种情况下,数据库还能提供和控制文件无关的增删改查等服务。
最后总结
控制文件的多路复用以及控制文件的备份是很重要的,使用ALTER DATABASE BACKUP CONTROLFILE语句备份你的控制文件。你有两个选择:
l 使用下列语句将控制文件备份到二进制文件(现有控制文件的副本):
ALTER DATABASE BACKUP CONTROLFILE TO '/u01/app/oracle/oradata/cams/control.bkp';
l 生成可以用于重新创建控制文件的SQL语句:
ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
此命令将SQL脚本写入trace文件,可以对其进行抓取和编辑以重现控制文件。通过查看告警日志可以确定跟踪文件的名称和位置。