Oracle数据恢复-慎用OEM误操作数据文件删除案例

最近有朋友遭遇到一则误删除的案例，由于使用OEM去管理数据库环境，未能正确理解OEM的功能，结果一个普通的维护操作，在后台却彻底的删除了数据文件。

我们可以看到，一个彻底的包含数据文件和内容的集联删除被发出，如果使用手工，恐怕DBA们都会极其慎重的拼写这样的命令：

Wed May 02 10:46:09 2012
/* OracleOEM */ DROP TABLESPACE "WNDT" INCLUDING CONTENTS  AND DATAFILES  CASCADE CONSTRAINTS
Wed May 02 10:46:23 2012
Errors in file d:\\oracle\\admin\\wndt\\udump\\wndt_ora_4816.trc:
ORA-01259: 无法删除数据文件 D:\\ORACLE\\ORADATA\\WNDT\\WNDT.ORA
ORA-27056: skgfrdel: 无法删除文件
OSD-04024: 无法删除文件。
O/S-Error: (OS 32) 另一个程序正在使用此文件，进程无法访问。

似乎幸运的是，初始的删除遇到错误，显示文件被其他进程持有，无法删除。

但是遗憾的是，进一步的提示显示，文件最终被成功操作删除：

Wed May 02 10:46:23 2012
Completed: /* OracleOEM */ DROP TABLESPACE "WNDT" INCLUDI

这则案例警示我们：尽量少用OEM等图形工具进行数据库重要的管理和维护操作，如果你不清楚前台的一个操作在后台会如何执行，那么一定要谨慎使用这样的工具。

对于这样的案例，如果用户能够及时的保护现场，通过存储级别的恢复是可以找回数据文件的。

在Linux、Unix之上，对于误操作删除，还有文件句柄可以考虑使用，参考：

• Oracle数据恢复 - Linux / Unix 误删除的文件恢复
  
  
• Oracle数据恢复 - 使用 lsof 查看进程打开的文件列表

DBA们应当谨慎！