非常規方法，輕鬆應對Oracle資料庫危急異常

作者：唐小丹（浙江移動資料庫管理員）

周 凱（上海新炬資料庫工程師）

相信很多Oracle DBA在職業生涯中或多或少都遇到過這樣的情況：資料檔案被誤刪了，儲存壞了無法識別資料檔案，最糟糕的是，竟然rman備份也是壞的…… 遇到問題凌亂慌張是沒用的，而貿然動手也是非常危險的，當遇到緊急問題，最重要的就是冷靜分析，臨危不亂。

下面我通過幾個實戰案例，給大家介紹幾例資料檔案異常可採用的非常規恢復方法。

一、資料檔案被刪除的恢復

實驗場景：由於維護人員的誤操作，導致資料庫部分資料檔案被刪除，資料庫報錯。

>>>>故障模擬

10點59分，誤操作刪除檔案。

 

11點20分資料庫alert日誌顯示出現ora－01116等錯誤，根據後臺日誌顯示此時ts_test01.dbf檔案已經無法正常開啟。

 

 

但是資料庫沒有因此關閉，還處於read write狀態。

>>>>問題分析

資料檔案被誤刪，資料庫仍然處於open狀態。對於此問題可以通過linux系統的“檔案描述符”找回丟失的資料檔案。在Linux系統中一切皆可以看成是檔案，檔案描述符（file descriptor）是核心為了高效管理已被開啟的檔案所建立的索引，所有執行I/O操作的系統呼叫都通過檔案描述符。檔案描述符開啟的檔案控制程式碼以及i-node的關係如圖：

 

在linux 系統中，資料檔案被刪除後，其檔案控制程式碼還被相關資料庫程式所開啟使用，可以通過該控制程式碼資訊直接複製將其恢復。需要注意的是，在此期間資料庫不能關閉。否則相關控制程式碼將被釋放，檔案就無法找回。

>>>>恢復步驟

嘗試通過oracle dbwr程式找到被誤刪除的檔案控制程式碼。

 

 

當前的oracle dbwr程式的spid是3293 可以通過該程式找到丟失的ts_test01.dbf 檔案控制程式碼。

含一些數字命名的目錄，它們是程式目錄，其下的fd子目錄包含程式相關的所有的檔案描述符。子本例中oracle的dbwr 程式的fd目錄下正有已經被刪除的ts_test01.dbf檔案的描述符（注：檔案描述符為25，當前的狀態是deleted）。

通過copy的方式恢復已刪除的資料檔案，並設定正確的屬組許可權。

通過將offline相關表空間並重置檔案路徑的方式完成檔案重定向。

由於前期資料檔案無法open的問題，部分已更改的資料無法寫入資料檔案，導致datafile header 上的checkpoint＃和controlfile檔案的checkpoint_change#不一致，需要對資料檔案進行介質恢復。

進行介質恢復之後，表空間可以正常online，故障處理也算完成。

>>>>總結感悟

作為系統維護人員rm，mv均屬於高危操作，在執行之前一定要反覆思考，確定影響，做到“寧停3分，不搶1秒”。當遇到資料庫問題時，應維持故障現狀，在沒有清楚的瞭解問題原因以及解決方案之前，草率的行動將使問題複雜化，造成不可估量的損失。對於此案例，如果貿然的關閉資料庫，只能使用rman備份進行恢復，如果備份失效，資料丟失將不可避免。總之做到，臨危不亂！三思而行！

二、使用bbed跳過歸檔檔案的完全恢復

實驗場景：儲存損壞導致部分資料檔案損壞，需要使用備份進行還原，在資料庫恢復階段發現缺失部分歸檔，導致資料庫無法恢復，正常啟動。

>>>>實驗環境準備

使用rman 為資料庫做一個全備。

對test表執行insert操作，每三次insert後執行一次switch logfile，保證生成的34，35，36三個歸檔各包含3條insert的操作日誌。

>>>>故障模擬

通過abort方式停庫後，刪除ts_test01.dbf 檔案模擬儲存故障。

人為刪除sequence 35的歸檔日誌。至此，故障已經重現。

當再次使用startup命令啟動時，資料庫在mount之後由於無法識別到datafile 6(ts_test01.dbf)，最終只能停留在mount階段。

通過rman 的方式進行資料檔案還原。在介質恢復階段rman報錯：no backup of archived log for thread 1 with sequence 35 and startingscn of…….。正是因為缺失了35號歸檔導致還原無法完成（35號歸檔已經被人為刪除）。

歸檔日誌按時間順序記錄著資料庫上的各類操作（包括insert，delete，update，create 等等）。歸檔的丟失意味著部分操作的缺失，oracle將無法繼續後續的歸檔檔案的恢復。

在此情況下使用常規手段顯然無法正常open資料庫。需要通過bbed跳過缺失的歸檔使其繼續完成介質恢復。

>>>>恢復步驟

通過rman的crosscheck archivelog all命令校驗歸檔日誌發現，缺少35號歸檔。

跳過缺失的歸檔需要將6號檔案的scn向前推進至少大於等於36號歸檔的first change＃1243371

資料檔案的scn被記錄在檔案1號block偏移量484位元組開始的四個位元組中。當前6號檔案的scn經過大小端轉換之後十進位制的數值為1243327（dump的原值為bff81200經大小端轉換後的十六進位制為0012f8bf）。該值正好是35號歸檔的first change＃

使用bbed更改資料檔案頭的scn號，使其變為1243381（注意更改的scn需要大於36號歸檔的first change＃，在這次實驗中使用36號歸檔的first change＃10作為新的scn號，經過十六進位制以及大小端轉換後資料為f5f812）, 並使用sum apply 命令重新計算校驗和。

要想跳過歸檔還需要資料檔案頭塊的rba。它由seq#、log block#、偏移量(固定為16)組成，決定了資料檔案從哪個歸檔日誌的哪個位置開始應用歸檔。Rba位於資料檔案頭塊偏移量500處開始連續的12個位元組(如圖從23開始到0000ffff結束，前4個位元組是日誌的序列號，中間4個位元組是日誌塊號，最後4個位元組是偏移量)。

將rba修改為接下去的歸檔日誌.log block#.offset#(這次試驗rba被修改為24000000.02000000.10000000即36.2.16)

再次執行資料檔案6的介質恢復後資料庫可以正常開啟。由於跳過了部分日誌，免不了存在資料丟失或者不一致的問題。對於採用此方法恢復的資料庫建議在合適的時候停機重建。

>>>>總結感悟

備份作為保障資料安全的最後一道防線，備份檔案的有效性應該得到充分的驗證。校驗發現備份集異常，丟失等問題時，應該及時發起新的資料庫備份。

Oracle資料庫好比一個龐大而精密的機器，關鍵檔案好比機器中的傳動齒輪，任何的缺失都會導致整個系統的停滯崩潰。作為一個合格的DBA，我們既要會用機器，也要會修機器，更要膽大心細，臨危不亂，為資料庫的持久穩定執行保駕續航。

 

About Me

....................................................................................................................................................

本文來自於微信公眾號轉載文章，若有侵權，請聯絡小麥苗及時刪除

ITPUB BLOG：http://blog.itpub.net/26736162

QQ：642808185 若加QQ請註明您所正在讀的文章標題

【版權所有，文章允許轉載，但須以連結方式註明源地址，否則追究法律責任】

....................................................................................................................................................

 

 

 

 

 

 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/26736162/viewspace-2080698/，如需轉載，請註明出處，否則將追究法律責任。