編輯手記：一個6T的資料庫，使用ASM磁碟儲存。在新增磁碟的過程中導致資料檔案offline，但可悲的是，資料庫沒有備份，在發現問題的時候歸檔也已經被清除，此時此刻，作為DBA的你，會選擇什麼辦法處理？

作者簡介：

韓朝陽 超過10年的專業資料庫運維管理服務經驗，服務的產品主要包括Oracle Database，Oracle EBS，Oracle MiddleWare，Oracle Exadata。熟悉Oracle資料庫高可用架構，擅長Oracle 資料庫架構規劃、優化、故障診斷及異常恢復。曾長期服務於Oracle公司美國資料中心。喜歡做有挑戰性的事情。個人網站http://ohsdba.cn

我們首先回顧事件：

經瞭解，目前此資料庫的容量為6T，ASM磁碟組空間幾乎用盡，在向磁碟組增加磁碟時，由於種種原因最終導致2個數據檔案offline（一個bigfile，一個smallfile）。由於資料庫比較大，資料庫沒有備份，可憐的是，歸檔日誌是定期清除的，當發現這個問題時，所需的歸檔日誌已被清除，想通過常規手段使檔案online已不可能，幸運的時，通過BBED最終使檔案online成功，雖然後續還要一些問題，最終得以解決。

檢視alert日誌內容

恢復思路：

A.安裝BBED(由於是10.2.0.4的庫，自身就有bbed編譯所需的檔案) B.找出2個Offline檔案在磁碟上的位置 C.通過dd生成備份/恢復這兩個資料檔案頭的命令 D.正常關閉資料庫 E.用dd複製出2個正常的資料檔案頭部和2個Offline的資料檔案頭部 注意：這2個offline的檔案頭部備份2份，因為後面要修改。複製出2個正常的資料檔案頭部用作參考。 F.用bbed檢視正常檔案的頭部在偏移量484到512的數值 G.用bbed修改2個offline檔案頭部在偏移量484到512的數值，確保Offline檔案和正常檔案頭部的數值是一致的 H.用sqlplus連線其中一節點並啟動資料庫到mount I.恢復資料檔案 recover datafile 67; recover datafile 11; J.已只讀模式開啟資料庫 alter database open read only; alter database datafile 11 online; alter database datafile 67 online; select distinct status from v$datafile; select * from v$recover_file; K.關閉資料庫，以正常模式開啟資料庫 shutdown immediate startup L.經過一段時間觀察，沒有出現ora-600等異常情況 M.關閉資料庫，用srvctl start database

注意：在操作前，注意備份system表空間，offline的檔案，當前的控制檔案，線上日誌檔案

備份資料檔案頭部

dd if=/dev/rhdisk5 of=/home/oracle/backup/1_1_264.FH bs=1048576 skip=283 count=1

dd if=/dev/rhdisk8 of=/home/oracle/backup/1_2_262.FH bs=1048576 skip=116 count=1

dd if=/dev/rhdisk17 of=/home/oracle/backup/2_8_261.FH bs=1048576 skip=53055 count=1

dd if=/dev/rhdisk12 of=/home/oracle/backup/2_2_264.FH bs=1048576 skip=3616 count=1
 

BBED（通過比較發現壞的檔案）

為了方便檢視，後面部分省略

為了方便檢視，後面部分省略

為了方便檢視，後面部分省略

為了方便檢視，後面部分省略

從上面我們可以看到，檔案1,2頭部是一樣的，這2個檔案是正常的，後面2個檔案是Offline的檔案，我們需要做的就是修改checkpoint的資訊以及RBA的資訊

BBED（檢視Checkpoint、RBA的資訊）

注意：AIX是大端，修改時順序無需調換

先檢視偏移量484到508的相信資訊

修改Checkpoint、RBA的資訊

修改檔案3,4在偏移量484到508的相關資訊，修改完成後，確認1,2,3,4偏移量在484到508的資訊是一致的

用dd還原修改後的資料檔案頭部

dd if=/home/oracle/backup/2_8_261.FH of=/dev/rhdisk17 bs=1048576 seek=53055 count=1 conv=notrunc dd if=/home/oracle/backup/2_2_264.FH of=/dev/rhdisk12 bs=1048576 seek=3616 count=1 conv=notrunc

檢視正常開啟後資料庫alert日誌

ALTER DATABASE RECOVER datafile 11 Tue Jul 5 23:03:43 2016 Media Recovery Start Tue Jul 5 23:03:43 2016 SUCCESS: diskgroup ASM_DG02 was mounted Tue Jul 5 23:03:45 2016 parallel recovery started with 15 processes Tue Jul 5 23:03:45 2016 Media Recovery Complete (abdd1) Tue Jul 5 23:03:45 2016 SUCCESS: diskgroup ASM_DG02 was dismounted Tue Jul 5 23:03:45 2016 Completed: ALTER DATABASE RECOVER datafile 11 Tue Jul 5 23:03:54 2016 ALTER DATABASE RECOVER datafile 67 Media Recovery Start Tue Jul 5 23:03:54 2016 SUCCESS: diskgroup ASM_DG02 was mounted Tue Jul 5 23:03:54 2016 parallel recovery started with 15 processes Tue Jul 5 23:03:54 2016 Media Recovery Complete (abdd1) Tue Jul 5 23:03:54 2016 SUCCESS: diskgroup ASM_DG02 was dismounted Tue Jul 5 23:03:54 2016 Completed: ALTER DATABASE RECOVER datafile 67 Tue Jul 5 23:04:16 2016 alter database open read only Tue Jul 5 23:04:16 2016 This instance was first to open Tue Jul 5 23:04:16 2016 SUCCESS: diskgroup ASM_DG02 was mounted Tue Jul 5 23:04:24 2016 Picked broadcast on commit scheme to generate SCNs Tue Jul 5 23:04:32 2016 SMON: enabling cache recovery Tue Jul 5 23:04:32 2016 Database Characterset is ZHS16GBK Opening with internal Resource Manager plan where NUMA PG = 1, CPUs = 16 replication_dependency_tracking turned off (no async multimaster replication found) Completed: alter database open read only Tue Jul 5 23:04:34 2016 Errors in file /u01/oracle/admin/abdd/udump/abdd1_ora_5571420.trc: ORA-00604: error occurred at recursive SQL level 1 ORA-16000: database open for read-only access ORA-06512: at line 2 alter database datafile 11 online Tue Jul 5 23:08:05 2016 Starting control autobackup Control autobackup written to DISK device handle '+ASM_DG01/abdd/autobackup/2016_07_05/s_916434663.16892.916441687' Completed: alter database datafile 11 online Tue Jul 5 23:08:17 2016 alter database datafile 67 online

解決後續錯誤

ORA-00600: internal error code, arguments: [ktsplbfmb-sync], [], [], [], [], [], [], []

通過dbv校驗資料檔案，發現之前有壞塊，根據file id,block id可以查到，壞塊涉及的物件有2個：一個為Lob Index(一個塊)，一個為Lob Segment(多個塊)

嘗試通過expdp匯出這2個表，Lob Index損壞的表可以正常匯出，然後通過move table，應用程式端出現的錯誤消失，Lob Segment損壞的表，無法通過expdp匯出。最終通過找到損壞的表的rowid，忍痛割愛通過empty_blob()重新初始化，好在損壞的行不多，只有2行，至此問題圓滿解決。

小結

• 在資料庫上不論做什麼操作，都要認真去分析調查，小心無大錯。
• 如何修改RBA的值是關鍵，需要停庫，參考正常的資料檔案RBA資訊，然後去修改Offline檔案的RBA資訊，確保他們都是一致的。
• 使用BBED時一定要注意大端小端的問題，本文僅供參考