久久精品人人爽,华人av在线,亚洲性视频网站,欧美专区一二三

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

193次閱讀
沒有評論

共計 10232 個字符，預計需要花費 26 分鐘才能閱讀完成。

這篇文章將為大家詳細講解有關 Linux 下如何利用文件描述符恢復的成功失敗實驗，丸趣 TV 小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

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

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

1、聊聊 File Description

不同的操作系統，在實現 CPU 管理、內存管理和存儲文件管理的時候，采用不同的方式手段。

在 Linux 和 Unix 里面，采用文件描述符進行文件管理。一個進程要打開文件，是調用操作系統內核功能，內核返回一個文件描述符。對文件的讀寫操作也通過這個描述符進行操作。操作系統刪除一個文件的時候，是要確定文件所有文件描述符都是釋放掉之后，才會最后刪除。

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

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

但是，在實際中，這種可以快速恢復的技術，并不是百分之百成功的。使用文件描述符恢復數據需要數據庫不能關閉、數據庫進程不能“自動剔除”數據文件等。本文從兩個實驗著手，介紹一下操作方法和前提。

2、實驗環境搭建

我們選擇 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

CORE11.2.0.1.0Production

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 中，更容易出現誤刪除的情況。

3、一次“不成功”的實驗

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

實驗環境中，我們總能夠發現很多知識和現象。首先，我們嘗試刪除數據文件，確認文件位置。

[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% 有效。如果時間很長，或者進行過很多特殊操作，這個微弱的文件描述符是會消失的！

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

4、一次“成功”的實驗

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

[root@bspdevdatafile]# 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 下如何利用文件描述符恢復的成功失敗實驗”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。

正文完
發表至： 數據庫
2023-07-24
 
丸趣
版權聲明：本站原創文章，由 丸趣 2023-07-24發表，共計10232字。
轉載說明：除特殊說明外本站除技術相關以外文章皆由網絡搜集發布，轉載請注明出處。
評論（沒有評論）
主站蜘蛛池模板： 萍乡市| 澄迈县| 金阳县| 军事| 内江市| 绥德县| 常州市| 吕梁市| 怀来县| 临潭县| 楚雄市| 京山县| 双江| 西和县| 汝南县| 裕民县| 萍乡市| 安多县| 二连浩特市| 多伦县| 罗甸县| 西乌珠穆沁旗| 防城港市| 富川| 根河市| 招远市| 乐昌市| 仙桃市| 楚雄市| 铜梁县| 桑植县| 乐业县| 清镇市| 嘉祥县| 虞城县| 汪清县| 岐山县| 肥西县| 周至县| 阿城市| 襄樊市|