【恢復】非歸檔模式下因誤刪除數據文件導致數據庫無法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.