【恢复】非归档模式下因误删除数据文件导致数据库无法OPEN的故障处理

scuess

　　模拟一下这个数据库故障，同时给出一个“简单”的恢复处理过程。
　　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>
　　Variable>　　Database Buffers           75497472 bytes
　　Redo Buffers                6316032 bytes
　　Database mounted.
　　ORA-01157: cannot>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@>>
　　Database>　　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@>>
　　Database>　　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'>　　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.