Linux下利用文件描述符恢復的成功失敗實驗

  

數據誤刪除是做爲初級運維人員經常遇到的「低級錯誤」，一些有經驗的老手有時也在疲勞、不冷靜的狀況下「馬失前蹄」。一旦誤刪除數據文件，儘快採用影響最小、最迅速的手段恢復數據庫是第一要務。

恢復數據的方法不少，好比冷熱備份、閃回數據庫等等，若是是直接從操做系統OS層面刪除數據文件，在Linux/Unix環境下，有一些優選手段可使用。其中之一就是文件描述符（File Description）。

 

一、聊聊File Description

 

不一樣的操做系統，在實現CPU管理、內存管理和存儲文件管理的時候，採用不一樣的方式手段。

在Linux和Unix裏面，採用文件描述符進行文件管理。一個進程要打開文件，是調用操做系統內核功能，內核返回一個文件描述符。對文件的讀寫操做也經過這個描述符進行操做。操做系統刪除一個文件的時候，是要肯定文件全部文件描述符都是釋放掉以後，纔會最後刪除。

咱們的誤操做，若是是發生在正在運行的數據庫系統中，文件雖然在操做系統上刪除不可見了。可是數據庫Oracle進程中還會保有一些存在的文件描述符，借用這些文件描述符，咱們是可能找到文件信息，來恢復數據文件的。

因此，一旦發生了誤刪除動做，切忌三點：心態冷靜、斷開應用、維護現場不關庫。

可是，在實際中，這種能夠快速恢復的技術，並非百分之百成功的。使用文件描述符恢復數據須要數據庫不能關閉、數據庫進程不能「自動剔除」數據文件等。本文從兩個實驗着手，介紹一下操做方法和前提。

 

二、實驗環境搭建

 

咱們選擇Linux 2.6內核和Oracle 11g進行試驗。注意：在生產環境下，絕對不能進行這樣的實驗。進行試驗的時候，也須要完備的備份。

 

[oracle@bspdev ~]$ uname -a

Linux bspdev.localdomain 2.6.18-308.el5 #1 SMP Tue Feb 21 20:05:41 EST 2012 i686 i686 i386 GNU/Linux

 

SQL> select * from v$version;

BANNER

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

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production

PL/SQL Release 11.2.0.1.0 - Production

CORE 11.2.0.1.0 Production

TNS for Linux: Version 11.2.0.1.0 - Production

NLSRTL Version 11.2.0.1.0 – Production

 

建立專門的表空間、用戶和數據表，用於進行試驗。

 

SQL> create tablespace rmdtest datafile '/u01/oradata/WILSON/datafile/rmdtest01.dbf' size 1000m

  2  extent management local uniform size 1m

  3  segment space management auto;

 

Tablespace created

 

SQL> create user rmtest identified by rmtest default tablespace rmdtest;

User created

 

SQL> grant resource, connect to rmtest;

Grant succeeded

 

SQL> grant select any dictionary to rmtest;

Grant succeeded

 

SQL> create table rm_tab as select * from dba_objects;

Table created

 

SQL> insert into rm_tab select * from rm_tab;

72731 rows inserted

 

SQL> commit;

Commit complete

 

數據表T，在實驗環境的表空間文件裏面。

 

SQL> select tablespace_name, bytes/1024/1024 M from dba_segments where owner='RMTEST' and segment_name='RM_TAB';

TABLESPACE_NAME                         M

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

RMDTEST                                17

 

確保有一份好的備份！

 

RMAN> list backup;

 

List of Backup Sets

===================

BS Key  Type LV Size       Device Type Elapsed Time Completion Time

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

135     Full    1.39G      DISK        00:03:13     02-FEB-14     

        BP Key: 135   Status: AVAILABLE  Compressed: NO  Tag: TAG20140202T012300

（篇幅緣由，有省略……）

        Piece Name:

        Piece Name: /u01/flash_recovery_area/WILSON/autobackup/2014_02_02/o1_mf_s_838430779_9gtckx4s_.bkp

  SPFILE Included: Modification time: 02-FEB-14

  SPFILE db_unique_name: WILSON

  Control File Included: Ckp SCN: 5370719      Ckp time: 02-FEB-14

 

下面進行兩次實驗過程，模擬運行狀態下數據文件被刪除的場景。注意：因爲操做系統差別性，Windows下是不會出現「運行打開的文件被刪除」的場景的。因此，在Linux/AIX中，更容易出現誤刪除的狀況。

 

三、一次「不成功」的實驗

 

首先是一次不成功的實驗。運維生產環境中，咱們的原則永遠是穩定。危險不肯定的事情場景，必定要避免。哪怕不作、不修、不優化，也不要讓業務系統的可用性去冒險。

實驗環境中，咱們總可以發現不少知識和現象。首先，咱們嘗試刪除數據文件，確認文件位置。

 

[oracle@bspdev ~]$ cd /u01/oradata/WILSON/datafile/

[oracle@bspdev datafile]$ ls -l | grep rmdtest01.dbf

-rw-r----- 1 oracle oinstall 1048584192 Feb  2 02:14 rmdtest01.dbf

 

刪除文件。

 

[oracle@bspdev datafile]$ rm rmdtest01.dbf

[oracle@bspdev datafile]$ ls -l

total 8121892

-rw-r----- 1 oracle oinstall   10493952 Feb  2 02:14 mvtbltest01.dbf

（篇幅緣由，有省略……）

-rw-r--r-- 1 oracle oinstall   10493952 Feb  2 02:14 tts_simple01.dbf

 

注意：此時數據文件雖然從OS中刪除，可是咱們依然能夠查詢到數據！

 

SQL> select count(*) from rmtest.rm_tab;

  COUNT(*)

----------

    145462

 

對於這種現象，筆者認爲兩種可能性，一是buffer cache中的緩存數據信息，能夠支持這種查詢動做。另外一種可能性，就是因爲文件描述符的存在，讓數據文件沒有被真正刪除，還以某種方式存在於系統中，支持dbwr查詢。

 

證實兩種猜測，對buffer cache進行清理。

 

SQL> alter system flush buffer_cache;

System altered

 

SQL> alter system flush shared_pool;

System altered

 

--依然能夠查詢結果

SQL> select count(*) from rmtest.rm_tab;

  COUNT(*)

----------

    145462

 

可是，若是數據庫以某種方式，發現了文件被刪除，好比check point動做，就會引發不少自動化動做出現。

 

SQL> alter system checkpoint;

System altered

 

--alert log中信息以下：

Sun Feb 02 02:27:51 2014

Beginning global checkpoint up to RBA [0x1ef.2532.10], SCN: 5374358

Errors in file /u01/diag/rdbms/wilson/wilson/trace/wilson_ckpt_4814.trc:

ORA-01171: datafile 11 going offline due to error advancing checkpoint

ORA-01116: error in opening database file 11

ORA-01110: data file 11: '/u01/oradata/WILSON/datafile/rmdtest01.dbf'

ORA-27041: unable to open file

Linux Error: 2: No such file or directory

Additional information: 3

Completed checkpoint up to RBA [0x1ef.2532.10], SCN: 5374358

Sun Feb 02 02:27:52 2014

Checker run found 1 new persistent data failures

 

Check Point是Oracle內部控制的一件大事。通過check point，Oracle要保證全部數據文件、控制文件SCN信息保持一致，和日誌文件在恢復時間點（RBA+SCN）達成一致。這個過程就強制回去訪問到數據文件，結果文件丟失被發現。

此後，查詢出錯。

 

SQL> select count(*) from rmtest.rm_tab;

select count(*) from rmtest.rm_tab

 

ORA-00376: 此時沒法讀取文件 11

ORA-01110: 數據文件 11: '/u01/oradata/WILSON/datafile/rmdtest01.dbf'

 

注意：若是聽任無論，Oracle自動的incremental checkpoint也會有相似的效果。同時，週期性的Global Check也會發現「文件丟失了」。

這個時候，咱們進行修復操做。使用文件描述符恢復文件的方法，第一步找到一個Oracle後臺進程，最典型的就是dbwr。

 

[oracle@bspdev datafile]$ ps -ef | grep dbw

oracle    4806     1  0 02:12 ?        00:00:00 ora_dbw0_wilson

oracle    9076  4491  0 02:29 pts/0    00:00:00 grep dbw

 

使用lsof –p命令，找出dbwr進程對應的文件描述符信息。

 

[root@bspdev datafile]# lsof -p 4806

COMMAND  PID   USER   FD   TYPE DEVICE   SIZE/OFF      NODE NAME

oracle  4806 oracle  cwd    DIR  253,0       4096  10574090 /u01/oracle/dbs

oracle  4806 oracle  rtd    DIR  253,0       4096         2 /

oracle  4806 oracle  txt    REG  253,0  173515991  10579756 /u01/oracle/bin/oracle

（篇幅緣由，有省略……）

racle  4806 oracle   33uW  REG  253,0   10493952   2978999 /u01/oradata/WILSON/datafile/mvtbltest01.dbf

oracle  4806 oracle   34uW  REG  253,0   30416896    524875 /u01/oradata/WILSON/datafile/o1_mf_temp_7xt46489_.tmp

oracle  4806 oracle   35r   REG  253,0    1074176  10595009 /u01/oracle/rdbms/mesg/oraus.msb

 

裏面包括了dbwr打開的全部文件描述符，咱們沒有能看到刪除的文件rmdtest01.dbf。文件描述符目錄也沒有相應的FD內容。說明：因爲一些狀況，Oracle進程將文件描述符刪除了！

 

此時，咱們檢查文件狀態。

 

SQL> select online_status from dba_data_files where file_id=11;

 

ONLINE_STATUS

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

RECOVER

 

文件已經被offline，強制剔除文件體系了。仔細想起來，這個過程是check point的一個結果。

Check Point的最終效果，是全部數據文件在文件頭標註相同的SCN記錄，以前髒塊被寫入到數據文件中。若是一個數據文件實體不存在了，這個操做必定不能完成。Oracle選擇了一種方法，就是強制將這個文件「剔除」。因此咱們在日誌中，看到了下面一段內容。

 

ORA-01171: datafile 11 going offline due to error advancing checkpoint

 

被剔除的文件，Oracle關閉文件描述符也是能夠理解的了。

這個實驗失敗，告訴咱們一個道理：使用文件描述符進行數據恢復，並非100%有效。若是時間很長，或者進行過不少特殊操做，這個微弱的文件描述符是會消失的！

下面咱們進行一次成功的實驗。

 

四、一次「成功」的實驗

 

咱們藉助RMAN備份，恢復到實驗前的狀態。

 

[root@bspdev datafile]# ls

mvtbltest01.dbf               o1_mf_temp_7xt46489_.tmp

o1_mf_example_7xt46m9x_.dbf   o1_mf_undotbs1_7xt3yzl5_.dbf.bak

o1_mf_jpatest_87y6v8qc_.dbf   o1_mf_undotbs1_92l5b0v4_.dbf

o1_mf_nbscommo_820frtg1_.dbf  o1_mf_users_805nxydh_.dbf

o1_mf_nbscommo_820ft5y5_.dbf  rmdtest01.dbf

o1_mf_sysaux_7xt3yzkb_.dbf    tts_simple01.dbf

o1_mf_system_7xt3yzhj_.dbf

 

刪除數據文件。

 

[root@bspdev datafile]# rm rmdtest01.dbf

rm: remove regular file `rmdtest01.dbf'? y

[root@bspdev datafile]# ls

mvtbltest01.dbf               o1_mf_system_7xt3yzhj_.dbf

o1_mf_example_7xt46m9x_.dbf   o1_mf_temp_7xt46489_.tmp

o1_mf_jpatest_87y6v8qc_.dbf   o1_mf_undotbs1_7xt3yzl5_.dbf.bak

o1_mf_nbscommo_820frtg1_.dbf  o1_mf_undotbs1_92l5b0v4_.dbf

o1_mf_nbscommo_820ft5y5_.dbf  o1_mf_users_805nxydh_.dbf

o1_mf_sysaux_7xt3yzkb_.dbf    tts_simple01.dbf

 

刪除以後，藉助文件描述符，咱們仍是能夠查詢的。

 

SQL> select count(*) from rmtest.rm_tab;

 

  COUNT(*)

----------

    145462

 

查找dbwr進程，肯定進程編號。

 

[root@bspdev datafile]# ps -ef | grep dbw

oracle    9405     1  0 02:45 ?        00:00:00 ora_dbw0_wilson

root      9716  4466  0 02:56 pts/0    00:00:00 grep dbw

 

使用lsof –p肯定文件描述符信息。

 

[root@bspdev datafile]# lsof -p 9405

COMMAND  PID   USER   FD   TYPE DEVICE   SIZE/OFF      NODE NAME

oracle  9405 oracle  cwd    DIR  253,0       4096  10574090 /u01/oracle/dbs

（篇幅緣由，有省略……）

oracle  9405 oracle   29uW  REG  253,0  209723392    525165 /u01/oradata/WILSON/datafile/o1_mf_nbscommo_820frtg1_.dbf

oracle  9405 oracle   30uW  REG  253,0  104865792    525166 /u01/oradata/WILSON/datafile/o1_mf_nbscommo_820ft5y5_.dbf

oracle  9405 oracle   31uW  REG  253,0  104865792    525484 /u01/oradata/WILSON/datafile/o1_mf_jpatest_87y6v8qc_.dbf

oracle  9405 oracle   32uW  REG  253,0   10493952    525541 /u01/oradata/WILSON/datafile/tts_simple01.dbf

oracle  9405 oracle   33uW  REG  253,0   10493952   2978999 /u01/oradata/WILSON/datafile/mvtbltest01.dbf

oracle  9405 oracle   34uW  REG  253,0   30416896    524875 /u01/oradata/WILSON/datafile/o1_mf_temp_7xt46489_.tmp

oracle  9405 oracle   35r   REG  253,0    1074176  10595009 /u01/oracle/rdbms/mesg/oraus.msb

oracle  9405 oracle   36uW  REG  253,0 1048584192   2979001 /u01/oradata/WILSON/datafile/rmdtest01.dbf (deleted)

 

注意：lsof是描述文件描述符最好的工具，其中包括FD列。咱們從dbwr的鏈接中，找到了rmdtest01.dbf的信息行。其中FD=36uw。這個36就表示了鏈接文件的名稱。

 

聯合dbwr的進程編號9405，咱們在目錄/proc/9405/fd中找到全部的文件符。

 

 

[root@bspdev datafile]# cd /proc/9405/fd

[root@bspdev fd]# ls

0  10  12  14  16  18  2   21  23  25  27  29  30  32  34  36  5  7  9

1  11  13  15  17  19  20  22  24  26  28  3   31  33  35  4   6  8

 

Ls命令也能夠列出信息。

 

 

[root@bspdev fd]# ls -l

total 0

lr-x------ 1 oracle oinstall 64 Feb  2 02:56 0 -> /dev/null

l-wx------ 1 oracle oinstall 64 Feb  2 02:56 1 -> /dev/null

lrwx------ 1 oracle oinstall 64 Feb  2 02:56 10 -> /u01/oracle/dbs/lkinstwilson (deleted)

lrwx------ 1 oracle oinstall 64 Feb  2 02:56 34 -> /u01/oradata/WILSON/datafile/o1_mf_temp_7xt46489_.tmp

lr-x------ 1 oracle oinstall 64 Feb  2 02:56 35 -> /u01/oracle/rdbms/mesg/oraus.msb

lrwx------ 1 oracle oinstall 64 Feb  2 02:56 36 -> /u01/oradata/WILSON/datafile/rmdtest01.dbf (deleted)

l-wx------ 1 oracle oinstall 64 Feb  2 02:56 9 -> /home/oracle/oradiag_oracle/diag/clients/user_oracle/host_1437849207_76/trace/ora_9293_3085993664.trm

 

這個36對應的文件還存在，就是已經被刪除的那個rmdtest01.dbf文件。進行拷貝出來。

 

[root@bspdev fd]# cp 36 /u01/oradata/WILSON/datafile/rmdtest01res.dbf

[root@bspdev fd]#

 

拷貝出來以後，最好進行必定轉換。先將其offline，以後進行控制文件中的rename動做，最後recover和online操做。具體流程常見筆者專門的文章（http://blog.itpub.net/17203031/viewspace-773628/）。

 

SQL> alter database datafile 11 offline;

Database altered

 

Rename操做。

 

--報錯

SQL> alter database rename file '/u01/oradata/WILSON/datafile/rmdtest01.dbf' to '/u01/oradata/WILSON/datafile/rmdtest01res.dbf';

 

alter database rename file '/u01/oradata/WILSON/datafile/rmdtest01.dbf' to '/u01/oradata/WILSON/datafile/rmdtest01res.dbf'

 

ORA-01511: 重命名日誌/數據文件時出錯

ORA-01141: 重命名數據文件 11 時出錯 - 未找到新文件 '/u01/oradata/WILSON/datafile/rmdtest01res.dbf'

ORA-01110: 數據文件 11: '/u01/oradata/WILSON/datafile/rmdtest01.dbf'

ORA-27041: 沒法打開文件

Linux Error: 13: Permission denied

Additional information: 9

 

究其緣由，是拷貝權限爲root，須要手工修改全部權信息。

 

[root@bspdev datafile]# ls -l | grep rmd

-rw-r----- 1 root   root     1048584192 Feb  2 03:01 rmdtest01res.dbf

[root@bspdev datafile]# chown oracle:oinstall rmdtest01res.dbf

[root@bspdev datafile]# ls -l | grep rmd

-rw-r----- 1 oracle oinstall 1048584192 Feb  2 03:01 rmdtest01res.dbf

 

Rename文件。

 

 

SQL> alter database rename file '/u01/oradata/WILSON/datafile/rmdtest01.dbf' to '/u01/oradata/WILSON/datafile/rmdtest01res.dbf';

Database altered

 

SQL> recover datafile 11;

Media recovery complete.

SQL> alter database datafile 11 online;

 

Database altered.

 

使用rman中的recovery advisor工具，來判斷錯誤是否存在。

 

[oracle@bspdev ~]$ rman nocatalog

 

Recovery Manager: Release 11.2.0.1.0 - Production on Sun Feb 2 03:06:43 2014

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

RMAN> connect target /

 

connected to target database: WILSON (DBID=3906514064)

using target database control file instead of recovery catalog

 

RMAN> list failure;

no failures found that match specification

 

恢復完成，實驗成功。

 

五、結論

 

本篇文章的書寫，有一半目的是揭示文件內部的運行機制，另外一半是記錄下Linux下使用文件描述符FD來恢復數據的方法。咱們說，從運維角度看，直接繞過數據庫對OS進行文件操做是很是不成熟的作法，不管是出於什麼目的。不少致命的錯誤都是一系列的rm形成的。願文章描述的場景永不會在全部運維生產系統中出現！