当我们在Linux系统中不小心rm了数据文件时，一定要冷静，不要做关闭数据库、重启操作系统等危险操作，因为在不了解数据库运行状态

引题：朋友一时兴起使用了rm**，删除了Oracle数据文件后找我帮忙，我在帮朋友恢复数据库时，遇到了当recover时，报错不能找到28739号归档日志，这样我就不能同步scn，更不能打开数据库了。这是归档日志不连续的典型案例，我最后告诉他要做好心理准备。事情还没有完，这个真实案例引发了我的思考，如果当时在朋友没有做rman拯救措施的情况下，可不可能不使用rman即可恢复数据文件呢！最后我找到了答案：）

案例
1.系统solaris SunOS TJLT-YDWG6 5.9 Generic_122300-25 sun4u sparc SUNW,Sun-Fire-V0
DB OracleDatabase 10g Enterprise Edition Release 10.2.0.1.0 - bi
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删除的数据文件，并最终顺利打开数据库的实验！我是一个比较严谨的人，所以一上来我先做个了“压缩全库备份”做到有备无患