模擬一下這個資料庫故障，同時給出一個“簡單”的恢復處理過程。

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的故障處理

相關文章