1  問題描述

之前寫過一篇刪除oracle home目錄的blog，參考：

本篇是這邊的引深，本來應該是年前整理的，拖到年後了。

模擬現狀：

    資料庫在正常執行，誤操作，直接rm 掉了資料檔案。

測試環境：

[[email protected] trace]$ cat /etc/redhat-release

Red Hat Enterprise Linux Server release 6.1(Santiago)

Oracle 11.2.0.3 單例項。

[[email protected] ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production onWed Aug 27 18:36:32 2014

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:

Oracle Database 11g Enterprise EditionRelease 11.2.0.3.0 - 64bit Production

With the Partitioning, OLAP, Data Miningand Real Application Testing options

SQL>

這個問題也要分2種情況，一種是歸檔模式，一種是非歸檔模式，歸檔模式處理就容易很多了。但現在很多由開發人員管理的庫是非歸檔，並且也缺乏專業的運維技能，誤操作的概率也會增加很多。

2  建立測試資料

SQL> create tablespace dropspacedatafile '/u01/dropspace01.dbf' size 100m;

Tablespace created.

User created.

Grant succeeded.

SQL> conn ahzhixin/ahzhixin

Connected.

SQL> create table test1 as select * fromall_users;

Table created.

SQL> create table test2 as select * fromall_users;

Table created.

SQL> create table test3 as select * fromall_users;

Table created.

3  歸檔模式處理

3.1            模擬故障

SQL> archive log list;

Database log mode        Archive Mode

Automatic archival          Enabled

Archive destination         /u01/archivelog

Oldest online log sequence     83

Next log sequence to archive   85

Current log sequence        85

SQL>

在作業系統上直接刪除資料檔案：

此時資料庫還是正常執行，我們查詢我們之前建立的幾張表：

SQL> select count(1) from test1;

 COUNT(1)

----------

    31

SQL> select count(1) from test2;

 COUNT(1)

----------

    31

SQL> select count(1) from test3;

 COUNT(1)

----------

    31

--insert 也沒有問題：

SQL> insert into test1 select * fromall_users;

31 rows created.

SQL> commit;

Commit complete.

SQL> select count(1) from test1;

 COUNT(1)

----------

    62

至少從目前看，一切都是正常。  這裡正常也是因為我們的作業系統是Linux，當資料檔案從作業系統級別被rm掉，但之前開啟該檔案的程序仍然持有相應的檔案控制代碼，所以指向的檔案仍然可以讀寫，並且該檔案的檔案描述符可以從/proc目錄中獲得，也可以利用這個控制代碼恢復檔案。

    如果在這個時候，重啟了資料庫或者作業系統，那麼控制代碼就會消失，也就只能通過掃描磁碟進行檔案恢復。

3.2            恢復

dbwr程序會開啟所有資料檔案的控制代碼，在proc目錄中可以查到這些資料檔案的資訊，目錄名是程序PID，fd表示檔案描述符。

檢查dbwr的程序PID：

oracle   9964     1  0 00:49 ?        00:00:03 ora_dbw0_dave

[[email protected] trace]$ cd /proc/9964/fd

[[email protected] fd]$ ls -l

這裡的259 就是我們刪掉的資料檔案。

//直接cp該控制代碼檔名回原位置：

[[email protected] fd]$ cp 259/u01/dropspace01.dbf

[[email protected] fd]$

因為資料庫一直是open的，那麼SCN也會不斷的變化，我們cp出來的資料檔案和資料庫當前的資訊不一致，所以我們需要進行recover：

SQL> alter database datafile'/u01/dropspace01.dbf' offline;

Database altered.

SQL> recover datafile'/u01/dropspace01.dbf';

Media recovery complete.

Database altered.

SQL>

恢復正常。

//檔案存在：

[[email protected] u01]$ ls -la/u01/dropspace01.dbf

-rw-r----- 1 oracle oinstall 104865792 Aug27 21:41 /u01/dropspace01.dbf

//重啟資料庫：

SQL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup

ORACLE instance started.

Total System Global Area  814227456 bytes

Fixed Size        2232760 bytes

Variable Size       490737224 bytes

Database Buffers    318767104 bytes

Redo Buffers          2490368 bytes

Database mounted.

Database opened.

SQL>

也正常。 這裡有2個注意的問題：資料庫是歸檔模式，資料庫或者作業系統沒有重啟。這2點非常關鍵。 也正式如此，才讓操作比較簡單。

如果是非歸檔模式，那就要複雜很多了。

在非歸檔模式下，如果刪除了資料檔案，並且又觸發了CKPT，那麼CKPT 會直接把整個例項中斷掉，也就是說，如果是比較繁忙的資料庫，如果誤刪除資料檔案，例項可能會中斷，一旦例項中斷，那麼用之前講的通過控制代碼恢復就沒有可能性了。

當然也有另一種可能性，就是刪除資料檔案之後，可以先通過控制代碼恢復，然後用expdp匯出資料，儘可能的挽救部分資料。 這個動作就是與時間賽跑的過程了。

總之生產環境，操作一定要小心，還有要開歸檔，除非資料允許丟失。

--------------------------------------------------------------------------------------------

AboutDave:

QQ:492913789

Email:[email protected]

Dave 的QQ群：

--------------------------------------------------------------------------------------------

注意:加群必須註明表空間和資料檔案關係 | 不要重複加群

CNDBA_1: 62697850 (空)    CNDBA_2: 62697716 (滿)  CNDBA_3: 283816689

CNDBA_4: 391125754   CNDBA_5:104207940    CNDBA_6: 62697977   CNDBA_7: 142216823（滿）