Backup&Recovery
2012-05-07
Oracle数据恢复-慎用OEM误操作数据文件删除案例
最近有朋友遭遇到一则误删除的案例,由于使用OEM去管理数据库环境,未能正确理解OEM的功能,结果一个普通的维护操作,在后台却彻底的删除了数据文件。
我们可以看到,一个彻底的包含数据文件和内容的集联删除被发出,如果使用手工,恐怕DBA们都会极其慎重的拼写这样的命令:
似乎幸运的是,初始的删除遇到错误,显示文件被其他进程持有,无法删除。
但是遗憾的是,进一步的提示显示,文件最终被成功操作删除:
这则案例警示我们:尽量少用OEM等图形工具进行数据库重要的管理和维护操作,如果你不清楚前台的一个操作在后台会如何执行,那么一定要谨慎使用这样的工具。
对于这样的案例,如果用户能够及时的保护现场,通过存储级别的恢复是可以找回数据文件的。
在Linux、Unix之上,对于误操作删除,还有文件句柄可以考虑使用,参考:
我们可以看到,一个彻底的包含数据文件和内容的集联删除被发出,如果使用手工,恐怕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之上,对于误操作删除,还有文件句柄可以考虑使用,参考:
DBA们应当谨慎!
历史上的今天
- 2015-05-07 Oracle 的 enq: TT - contention 等待事件
- 2009-05-07 ORA-02097 标准版里Resource Manager的Bug
- 2008-05-07 Oracle Logfile的常见不同状态
- 2006-05-07 繁华,不过是一掬细沙
- 2006-05-07 节日过后 几点关注
- 2005-05-07 Google的新玩具:Webaccelerator
- 2005-05-07 2005.05.03司马台之行
- 2005-05-07 Using DBMS_SYS_SQL Package to grant Privilege