[20151025]linux下刪除資料檔案的恢復細節3

[20151025]linux下刪除資料檔案的恢復細節3.txt

--以前曾經寫過一篇關於
--連結：http://blog.itpub.net/267265/viewspace-763969/

--裡面提到實際上這種方式對於生產系統不是很合適，而且生產系統情況非常複雜，不可能出現刪除資料檔案時沒有事務產生。
--這種方式僅僅適合no archivelog的模式(沒有辦法的選擇)，我當時還提到這種方式一定要快，因為我的測試執行 alter system
--checkpoint;,資料庫直接crash。

--正好別人問我一些檢查點的問題，讓我重新思考以前的解決思路。我喜歡透過例子詳細說明：


--前幾天重新思考這個問題，連結http://blog.itpub.net/267265/viewspace-1816212/，當時的思路有一些亂。恢復N次，測試N次。
--腦子有點亂。

--首先這種恢復是萬不得已，當然如果直接crash，還可以透過一些檔案恢復工具extundelete來恢復。
--連結：

1.前面的測試說明如果刪除了資料檔案，已經登入的會話實際上不受影響的，因為檔案控制程式碼已經開啟，雖然檔案刪除了，但是磁碟空間並
  沒有釋放。
2.另外的我的測試如果這個時候新登入的會話(也就是程式沒有開啟訪問檔案的控制程式碼)，如果執行
alter system flush buffer_cache;  (有可能，許多情況下應該不會)
alter tablespace mssm read only ; (報ORA-03135 10g)
alter system checkpoint;          (報ORA-03113 10g)

--說明1點：不知道10g與11g存在什麼不同，要等以後測試再下結論。

--因為這種方式要先開啟檔案控制程式碼，檢查資料檔案是否存在，具體寫髒塊應該有dbw程式完成。如果檔案不存在，直接影響dbw程式寫入。
--後臺直接crash。

--換一個思路，如果新開啟的程式看看是否要開啟檔案控制程式碼，也可以驗證我的判斷是否正確。繼續測試：

1.環境：
RMAN> report schema;

using target database control file instead of recovery catalog
Report of database schema

List of Permanent Datafiles
===========================
File Size(MB) Tablespace           RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1    510      SYSTEM               ***     /mnt/ramdisk/test/system01.dbf
2    350      UNDOTBS1             ***     /mnt/ramdisk/test/undotbs01.dbf
3    370      SYSAUX               ***     /mnt/ramdisk/test/sysaux01.dbf
4    100      USERS                ***     /mnt/ramdisk/test/users01.dbf
5    100      EXAMPLE              ***     /mnt/ramdisk/test/example01.dbf
6    15       MSSM                 ***     /mnt/ramdisk/test/mssm01.dbf

List of Temporary Files
=======================
File Size(MB) Tablespace           Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- --------------------
1    18       TEMP                 32767       /mnt/ramdisk/test/test01.dbf

SYS@test> @ver1
PORT_STRING                    VERSION        BANNER
------------------------------ -------------- ----------------------------------------------------------------
x86_64/Linux 2.4.xx            10.2.0.4.0     Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi

--保險期間我在關閉資料庫的情況下做了一個冷備份，當然僅僅備份mssm01.dbf檔案。
--注：我前面的測試是11g，這次是10g。

2.開始測試：
--session 1:
SCOTT@test> create table t tablespace mssm as select * from dba_objects ;
Table created.

SCOTT@test> select count(*) from t;
    COUNT(*)
------------
       50650

SCOTT@test> alter system checkpoint;
System altered.

SCOTT@test>col spid new_value v_spid
SCOTT@test> @spid
         SID      SERIAL# SPID   C50
------------ ------------ ------ --------------------------------------------------
         156           23 25554  alter system kill session '156,23' immediate;

SCOTT@test> host ls -l /proc/&v_spid/fd | grep mssm01.dbf
lrwx------ 1 oracle oinstall 64 Oct 26 08:55 12 -> /mnt/ramdisk/test/mssm01.dbf
lrwx------ 1 oracle oinstall 64 Oct 26 08:55 18 -> /mnt/ramdisk/test/mssm01.dbf

--先不做刪除資料檔案操作，看看會話在執行一些alter system flush buffer_cache;alter tablespace mssm read only ;alter
--system checkpoint;是否會開啟檔案控制程式碼。

3.檢查開啟控制程式碼情況：
--session 2:
SCOTT@test> col spid new_value v_spid
SCOTT@test> @spid

         SID      SERIAL# SPID   C50
------------ ------------ ------ --------------------------------------------------
         145            7 23851  alter system kill session '145,7' immediate;

SCOTT@test> host ls -l /proc/&v_spid/fd | grep mssm01.dbf
SCOTT@test> alter system flush buffer_cache;
System altered.

SCOTT@test> host ls -l /proc/&v_spid/fd | grep mssm01.dbf
--可以發現執行alter system flush buffer_cache;無需開啟/mnt/ramdisk/test/mssm01.dbf檔案控制程式碼。

SCOTT@test> alter tablespace mssm read only;
Tablespace altered.

SCOTT@test> host ls -l /proc/&v_spid/fd | grep mssm01.dbf
lrwx------ 1 oracle oinstall 64 Oct 26 09:07 16 -> /mnt/ramdisk/test/mssm01.dbf

--可以發現alter tablespace mssm read only;要先開啟/mnt/ramdisk/test/mssm01.dbf檔案控制程式碼,再寫涉及到的髒塊與檔案檢查點。

SCOTT@test> alter tablespace mssm read write;
Tablespace altered.

4.退出繼續測試，因為檔案控制程式碼已經開啟。

--session 2:
SCOTT@test> col spid new_value v_spid
SCOTT@test> @spid

         SID      SERIAL# SPID   C50
------------ ------------ ------ --------------------------------------------------
         145            9 23994  alter system kill session '145,9' immediate;

SCOTT@test> host ls -l /proc/&v_spid/fd | grep mssm01.dbf

SCOTT@test> alter system checkpoint;
System altered.

SCOTT@test> host ls -l /proc/&v_spid/fd | grep mssm01.dbf
--恩！alter system checkpoint;也不開啟嗎？為什麼執行這個前面的測試會崩潰呢？

--做1個跟蹤測試：
$  strace -f -p 23994 -e open,statfs
Process 23994 attached - interrupt to quit
open("/u01/app/oracle/admin/test/bdump/alert_test.log", O_WRONLY|O_CREAT|O_APPEND, 0660) = 6
open("/proc/23694/stat", O_RDONLY)      = 12

--下面我也做了刪除資料檔案，有時候執行！alter system checkpoint;可以不報錯有時候不行。包括alter tablespace mssm read
--only;有時候會崩潰，有時候不會。先放棄這部分的探究。

5.如果出現這種情況，要使用這種方式，如何恢復呢：

SYS@test> alter database datafile 6 offline ;
Database altered.

#  lsof | grep /mnt/ramdisk/test/mssm01.dbf
oracle    25554      oracle   12u      REG               0,29  16654336     355026 /mnt/ramdisk/test/mssm01.dbf (deleted)

#  ps -ef | grep 2555[4]
oracle   25554 25553  0 10:21 ?        00:00:00 oracletest (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))

--而這個程式是session 1的程式號，理論講不能保證在複製的過程中使用者退出會話的情況。
--也就是講先offline的方式是不行的。因為dbw等程式的檔案控制程式碼丟失了，而使用者會話保留的控制程式碼可能不會長久。
--而且實際上等1會，mmon程式也會清理無效的連結。
#  lsof | grep /mnt/ramdisk/test/mssm01.dbf
--無輸出。這個時候無法恢復了。

--換1句話還必須欺騙oracle保證這個檔案存在才行。

6.先恢復繼續測試，整個恢復過程僅僅按照連結的介紹才行：
--http://blog.itpub.net/267265/viewspace-1816212/

利用先透過dbw0程式指向的控制程式碼，建立連結使用ln命令。
登入會話，執行alter tablespace xxxx read only;
然後使用rm刪除原連結，cp /proc/xxx/fd/NN  delete_file.dbf。
這個時候不能執行alter tablespace xxxx read write;(切記!!!!!)
要執行
alter database datafie 6 offline drop;  --注:後面說明為什麼要使用drop引數。
recover datafile 6;
alter database datafie 6 online ;
alter tablespace xxxx read write;

--補充1點，不要drop也可以。測試有點亂。我估計我自己忘記
alter database datafie 6 offline
alter database datafie 6

--不放心可以
$  lsof | grep mssm01.dbf |grep delete
刪除標識deleted的程式。