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

模拟一下这个数据库故障，同时给出一个“简单”的恢复处理过程。

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 --

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/519536/viewspace-664275/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/519536/viewspace-664275/