模拟一下这个数据库故障，同时给出一个“简单”的恢复处理过程。
1.查询获得TBS_SEC_D表空间对应的数据文件信息
sys@ora10g> col FILE_NAME for a40
sys@ora10g> select FILE_NAME,FILE_ID,STATUS from dba_data_files where TABLESPACE_NAME='TBS_SEC_D';
FILE_NAME FILE_ID STATUS
---------------------------------------- ---------- ---------
/oracle/oradata/ora10g/tbs_sec_d_01.dbf 5 AVAILABLE
/oracle/oradata/ora10g/hou.dbf 13 AVAILABLE
2.非归档模式下模拟误删除数据文件
1）确认数据库的归档模式
sys@ora10g> archive log list;
Database log mode No Archive Mode
Automatic archival Disabled
Archive destination /oracle/arch/ora10g
Oldest online log sequence 1541
Current log sequence 1543
2）模拟误删除hou.dbf数据文件
sys@ora10g> !rm -f /oracle/oradata/ora10g/hou.dbf
3）此时的数据库状态没有异样
sys@ora10g> select FILE_NAME,FILE_ID,STATUS from dba_data_files where TABLESPACE_NAME='TBS_SEC_D';
FILE_NAME FILE_ID STATUS
---------------------------------------- ---------- ---------
/oracle/oradata/ora10g/tbs_sec_d_01.dbf 5 AVAILABLE
/oracle/oradata/ora10g/hou.dbf 13 AVAILABLE
3.重启数据库观察一系列的报错信息
1）关闭数据库过程中的报错信息
sys@ora10g> shutdown immediate;
ORA-03113: end-of-file on communication channel
2）启动数据过程中的报错信息
NotConnected@> startup;
ORACLE instance started.
Total System Global Area 209715200 bytes
Fixed Size 2071640 bytes
Variable Size 125830056 bytes
Database Buffers 75497472 bytes
Redo Buffers 6316032 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 13 - see DBWR trace file
ORA-01110: data file 13: '/oracle/oradata/ora10g/hou.dbf'
这里提示无法定位13号数据文件。
此时数据库仅处于mount状态。
NotConnected@> select open_mode from v$database;
OPEN_MODE
----------
MOUNTED
4.恢复方法
既然数据文件被误删除了，而且我们又没有有效的备份可用，同时数据库又处于非归档的状态（“杯具”到了），那我们只能容忍数据的丢失（如果13号数据文件存有数据的情况下）。
1）在mount状态下使用offline drop命令将数据文件与表空间之间的关系隔断。
NotConnected@> col name for a50
NotConnected@> select FILE#,STATUS,ENABLED,NAME from v$datafile where name like '%hou%';
FILE# STATUS ENABLED NAME
---------- ------- ---------- ---------------------------------------
13 ONLINE READ WRITE /oracle/oradata/ora10g/hou.dbf
NotConnected@> alter database datafile '/oracle/oradata/ora10g/hou.dbf' offline drop;
Database altered.
NotConnected@> select FILE#,STATUS,ENABLED,NAME from v$datafile where name like '%hou%';
FILE# STATUS ENABLED NAME
---------- ------- ---------- ----------------------------------------
13 RECOVER READ WRITE /oracle/oradata/ora10g/hou.dbf
2）此时我们便可以顺利的OPEN数据库
NotConnected@> alter database open;
Database altered.
5.收尾工作
即便按照上述的方法简单处理了这个故障，但是在数据库中还是遗留了一下“垃圾”信息。
sys@ora10g> select FILE_NAME,FILE_ID,STATUS from dba_data_files where TABLESPACE_NAME='TBS_SEC_D';
FILE_NAME FILE_ID STATUS
---------------------------------------- ---------- ---------
/oracle/oradata/ora10g/tbs_sec_d_01.dbf 5 AVAILABLE
/oracle/oradata/ora10g/hou.dbf 13 AVAILABLE
此时表明物理上已经不存在的“/oracle/oradata/ora10g/hou.dbf”文件还是归属于表空间TBS_SEC_D。如何彻底的断绝这样的无意义的关系？
这里给出“简单粗暴”的重建表空间方法。
大体步骤如下：
1）想办法逻辑备份表空间中包含的数据
2）删除表空间
sys@ora10g> drop tablespace TBS_SEC_D including contents and datafiles;
Tablespace dropped.
sys@ora10g> select FILE_NAME,FILE_ID,STATUS from dba_data_files where TABLESPACE_NAME='TBS_SEC_D';
no rows selected
3）重建表空间
sys@ora10g> create tablespace TBS_SEC_D datafile '/oracle/oradata/ora10g/tbs_sec_d_01.dbf' size 10m;
Tablespace created.
sys@ora10g> select FILE_NAME,FILE_ID,STATUS from dba_data_files where TABLESPACE_NAME='TBS_SEC_D';
FILE_NAME FILE_ID STATUS
---------------------------------------- ---------- ---------
/oracle/oradata/ora10g/tbs_sec_d_01.dbf 5 AVAILABLE
4）使用逻辑备份恢复表空间的内容
6.小结
又一次实践证明，【无备份、非归档】是DBA界可怕的场景。
假设这个故障发生之前存在有效的备份，恢复的过程将会非常的简便，也不会冒着丢失数据的风险。
珍爱DBA生命，请及时完善备份策略并定期安排备份介质有效性验证等常规“枯燥”任务，只有“她们”才是美丽的！
Good luck.
secooler
10.06.02
-- The End --
【恢复】非归档模式下因误删除数据文件导致数据库无法OPEN的故障处理
分享好友
分享这个小栈给你的朋友们，一起进步吧。
订阅须知
• 所有用户可根据关注领域订阅专区或所有专区
• 付费订阅：虚拟交易，一经交易不退款；若特殊情况，可3日内客服咨询
• 专区发布评论属默认订阅所评论专区（除付费小栈外）