rm -rf誤刪Oracle數據庫恢復---惜分飛

聯繫:手機/微信(+86 17813235971) QQ(107644445)QQ諮詢惜分飛

標題:rm -rf誤刪Oracle數據庫恢復

作者:惜分飛©版權所有[未經本人同意,不得以任何形式轉載,否則有進一步追究法律責任的權利.]

有客戶把虛擬化環境中裝有oracle數據庫的linux操作系統,由於操作失誤在/下面執行了rm -rf *,導致所有文件被刪除,系統無法啓動.客戶希望要求恢復出其中的Oracle數據庫.由於是虛擬化環境,然後客戶直接從虛擬化平臺下載下來磁盤文件,通過工具加載和分析確認是一個xfs的文件系統
20240516190746


使用工具進一步掃描分析,找到部分數據文件
20240516190505

這裏可以獲取到兩個信息:
1. 嘗試恢復oracle的control01.ctl文件,然後通過該文件嘗試分析其他數據文件位置,運氣不錯該文件恢復出來是好的,直接加載到新庫查詢v$datafile,分析出來所有數據文件信息
2. 這裏有一個非常不幸的信息,oracle最核心的system01.dbf文件大小明顯異常,進一步分析該文件信息,結論是該文件無法通過反刪除方式進行恢復
20240515223607

先把可以os層面可以恢復的數據恢復出來,並且檢查壞塊情況
20240516191836

對於異常的system文件,有兩個處理方法:
1. 通過閱覽被刪除的文件,發現客戶有5月14日1點左右的rman備份,通過恢復軟件中完整度提示,大概率應該沒有什麼問題,但是分析發現部分歸檔日誌損壞無法完整恢復
2. 通過對磁盤做碎片,恢復出來該數據文件,參考以往文章:
dbca刪除庫和rm刪庫恢復
Oracle 數據文件大小爲0kb或者文件丟失恢復
通過這個方法運氣不錯,恢復出來該庫的system01.dbf文件非常完整0丟失

 

[oracle@localhost oradata]$ dbv file=system01.dbf
 
DBVERIFY: Release 19.0.0.0.0 - Production on Thu May 15 23:26:57 2024
 
Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.
 
DBVERIFY - Verification starting : FILE = /u01/oradata/system01.dbf
 
 
DBVERIFY - Verification complete
 
Total Pages Examined         : 199680
Total Pages Processed (Data) : 113988
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 26869
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 40253
Total Pages Processed (Seg)  : 1
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 18570
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Total Pages Encrypted        : 0
Highest block SCN            : 658228557 (0.658228557)

完成上述恢復工作之後,目前確認只有sysaux01.dbf有8026個block損壞,但是該表空間不涉及業務數據,嘗試在新的系統中直接修改路徑並open庫

SQL> recover database;
ORA-00283: recovery session canceled due to errors
ORA-38760: This database instance failed to turn on flashback database
 
 
SQL> alter database flashback off;
 
Database altered.
 
SQL> recover database;
Media recovery complete.
SQL> alter database open;
 
Database altered.

運氣不錯,數據庫直接open成功,現在處理sysaux01.dbf中的損壞文件:
1. 確認該文件具體壞塊開始位置:
20240516193650


2. 由於壞塊在文件中比較靠後,分析實際存儲數據最後的位置

 

SQL> select max(block_id+blocks) from dba_extents where file_id=3;
 
MAX(BLOCK_ID+BLOCKS)
--------------------
             3493120

最後存儲數據的位置小於壞塊的位置,證明壞塊部分是沒有存儲數據的,直接resize掉壞塊部分

SQL> alter database datafile '/u01/oradata/sysaux01.dbf' resize 27290m;
 
Database altered.

然後dbv該數據文件,確認沒有任何問題

[oracle@localhost trace]$ dbv file=/u01/oradata/sysaux01.dbf
 
DBVERIFY: Release 19.0.0.0.0 - Production on Wed May 15 22:43:00 2024
 
Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.
 
DBVERIFY - Verification starting : FILE = /u01/oradata/sysaux01.dbf
 
 
DBVERIFY - Verification complete
 
Total Pages Examined         : 3493120
Total Pages Processed (Data) : 1516833
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 1868832
Total Pages Failing   (Index): 0
Total Pages Processed (Lob)  : 56577
Total Pages Failing   (Lob)  : 0
Total Pages Processed (Other): 32107
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 18771
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Total Pages Encrypted        : 0
Highest block SCN            : 658223915 (0.658223915)

使用rman檢測全庫,也確定沒有任何問題

[oracle@localhost trace]$ rman target /
 
Recovery Manager: Release 19.0.0.0.0 - Production on Wed May 15 22:43:58 2024
Version 19.15.0.0.0
 
Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.
 
connected to target database: XIFENFEI (DBID=2912535091)
 
RMAN>
 
RMAN>
 
RMAN> backup validate check logical database skip inaccessible;
 
Starting backup at 15-MAY-24
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=43 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=278 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
………………
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
32   OK     0              6273         6400            370625094
  File Name: /u01/oradata/xff_com.dbf
  Block Type Blocks Failing Blocks Processed
  ---------- -------------- ----------------
  Data       0              0              
  Index      0              0              
  Other      0              127            
 
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
33   OK     0              163752       832000          627920639
  File Name: /u01/oradata/XFF_DATA_202312231.dbf
  Block Type Blocks Failing Blocks Processed
  ---------- -------------- ----------------
  Data       0              374296         
  Index      0              285002         
  Other      0              8950           
 
Finished backup at 15-MAY-24
 
[oracle@localhost trace]$ sqlplus / as sysdba
 
SQL*Plus: Release 19.0.0.0.0 - Production on Wed May 15 22:47:44 2024
Version 19.15.0.0.0
 
Copyright (c) 1982, 2022, Oracle.  All rights reserved.
 
 
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.15.0.0.0
 
SQL> select * from v$database_block_corruption ;
 
no rows selected
 
SQL>

至此對於這次rm -rf /*的故障實現了Oracle數據庫完美恢復,數據0丟失.

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章