Maison > Article > base de données > 不使用rman工具就能恢复被rm删除的数据文件案例
当我们在Linux系统中不小心rm了数据文件时,一定要冷静,不要做关闭数据库、重启操作系统等危险操作,因为在不了解数据库运行状态
引题:朋友一时兴起使用了rm**,删除了Oracle数据文件后找我帮忙,我在帮朋友恢复数据库时,遇到了当recover时,报错不能找到28739号归档日志,这样我就不能同步scn,更不能打开数据库了。这是归档日志不连续的典型案例,我最后告诉他要做好心理准备。事情还没有完,这个真实案例引发了我的思考,如果当时在朋友没有做rman拯救措施的情况下,可不可能不使用rman即可恢复数据文件呢!最后我找到了答案:)
案例
1.系统solaris SunOS TJLT-YDWG6 5.9 Generic_122300-25 sun4u sparc SUNW,Sun-Fire-V890
DB OracleDatabase 10g Enterprise Edition Release 10.2.0.1.0 - 64bi
2.案情描述
现场工程师使用了rm -rf *.dbf命令把所有的数据文件全部删除了
现在有5月4日的备份
restore database until time "to_date('2012-05-04 12:00:00','yyyy-mm-dd hh24:mi:ss')"; 进行恢复显示finish restore complete没有问题已经把文件 复制回来了
进行同步
RMAN> recover database until time "to_date('2012-05-04 11:00:00','yyyy-mm-dd hh24:mi:ss')";
Starting recover at 2012-07-26 14:02:42
using channel ORA_DISK_1
starting media recovery
unable to find archive log
archive log thread=1 sequence=28739 缺少28739号的归档日志,导致undotbs01.dbf文件不一致
Oracle Error:
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 2 needs more recovery to be consistent
ORA-01110: data file 2: '/opt/oradata/kpidb/undotbs01.dbf'
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 07/26/2012 14:02:51
RMAN-06054: media recovery requesting unknown log: thread 1 seq 28739 lowscn 1513525474
Leonarding
2012.7.26
在我们工作中可能会经常发生这样类似的突发状况,在遇到此情况下首先要做的就是冷静,上面发生的问题到了我这里之后,我就发现数据库已经变成了mount状态,在使用文件句柄方式恢复数据文件已经为时已晚,所以我采用了常规的恢复方式,没想到啊没想到,,归档日志还不全,立马我整个人都“斯巴达”了,最后告诉朋友做DBA是需要勇气的。
下面我用自己的测试库演示一下操作系统rm级别的删除数据文件后,数据库仍然处于open状态的时候使用文件句柄来恢复被rm删除的数据文件,并最终顺利打开数据库的实验!我是一个比较严谨的人,所以一上来我先做个了“压缩全库备份”做到有备无患