《【力薦】Exadata火線救援：10TB級數據修復經典案例詳解！》要點：
本文介紹了【力薦】Exadata火線救援：10TB級數據修復經典案例詳解！，希望對您有用。如果有疑問，可以聯系我們。

凌晨1點半,朦朧中電話鈴狂響,某Exadata嚴重故障…….

離上一篇文章(5小時數據蒸發||24小時服務降級,Salesforce的遭遇只是個案?)不遠,我們又遇到了一次又一次數據救援工作.跟Salesforce巧合的是,大家都是運行在Exadata上,不幸的是Salesforce丟失了4個小時數據(后續沒看到新聞稿,是否又追回了部分)業務停頓,那我今天遇到的要麻煩更多.

近期Exadata故障比較多,比較重要的是硬件生命周期所致,X2從2010年9月開始發布上線,到現在已經將近6年,就算傳統“高端”小型機也到該下線的時候了.提醒使用Exadata的朋友們做好備份,否則,你可能也要經歷一場難忘的救援經歷.問題發生得很不可思議,又很理所當然,細節就不說了.總之比較糟糕：

存放數據文件的diskgroup不能加載(mount),celldisk狀態是unknown,部分asmdisk的header是invalid的,就連它自動備份的塊也是invalid的,有磁盤物理損壞,物理損壞的磁盤沒有的mirror也失效了.接近10TB的數據,想想也頭疼吧.再說具體數據搶救工作之前,還是提醒下使用ASM/Exadata的朋友們,至少搭建個DataGuard吧,剛好建榮也做了這方面的分享,趕緊去讀讀.

鑒于問題非常棘手,綜合各方信息,我們做了如下的方案：

1. 將數據庫文件抽取出來
2. 嘗試open
3. 如失敗再DUL

要將數據庫文件(控制文件、數據文件、日志文件)從沒有加載的磁盤組中抽取出來,需要借助于AMDU.

AMDU: ORACLE針對ASM開發的源數據轉儲工具,其全稱為ASM Metadata Dump Utility

抽取的具體步驟：

• 從alert日志中找到啟動參數(包括控制文件),編輯成新的參數文件/tmp/pfile
• 從pfile中找到控制文件的位置,并用amdu抽取
• 用抽取出來的控制文件,將數據庫mount起來
• 從mount庫把所有數據文件找出來,可能有2種格式
• OMF格式(數據文件帶Oracle自動生成的數字)
• 自定義格式(手賤的),處理起來麻煩一些
• 日志文件同上處理

抽取數據文件

第一步：抽控制文件

先從alert日志找到控制文件位置：

control_files string +DATA/exdb/controlfile/curren t.266.278946847955,

11g開始amdu不需要編譯可以直接使用.到/data文件系統,開始操作

amdu -diskstring ‘/o/*/?*’ -extract data.266

在當前目錄下會生成一個DATA_266.f的文件和一個report.txt文件,DATA_266.f就是控制文件了.

第二步：找數據文件和日志文件

如果你有備份的pfile最好,如果沒有,就從alert日志里去找啟動的時候的初始化參數,實在沒有,手工編輯一個也行,包含sga_max_size,db_name,control_file這幾個參數.

然后把數據庫啟動到mount狀態,查找數據文件和日志文件：

select name from v$datafile;

select member from v$logfile;

運氣好,都是這樣的(OMF格式)：

+DATA/exdb/datafile/system.256.278946847955 +DATA/exdb/datafile/sysaux.257.278946847955 +DATA/exdb/datafile/undotbs1.258.39804295139 +DATA/exdb/datafile/users.259.48049295141

運氣不好,可能是有這樣的(自定義格式)：

+DATA/exdb/datafile/users_2013084.dbf +DATA/exdb/datafile/tbs_jifen_cx_0123.dbf

對于OMF格式的,仿照抽取控制文件,一個個抽：

amdu -diskstring ‘/o/*/?*’ -extract data.256

對于自定義格式的,要從<diskgroup>.6去抽取元數據,然后找到其對應的number

1. amdu -extract DATA.6 -diskstring ‘o/*/DATA‘?,生成DATA_6.f 文件

for (( i=1; i<15; i++ ))
do
kfed read DATA_6.f blknum=$i |egrep ‘name|fnum’>>aa.out
done

再依照OMF格式抽取方式抽取出所有數據文件.

值得一說的是,我們遭遇了一個3T的bigfile,extract消耗了將近24小時= =.–NFS掛過去的文件系統速度特別慢= =

最后對所有的文件用dbv做一次校驗,有沒有物理壞塊.

嘗試Open數據庫

當到了這一步的時候,其實就跟尋常的數據庫恢復類似了. 我們同樣在open的時候遇到了ORA-1555、ORA-704錯誤.

記錄下我們用到的參數和事件.

event：

隱含參數：

這里比較討厭的是rollback segments不容易確定,因為你是mounted狀態的數據庫,連v$rollname都查詢不了.

有兩個辦法來解決：

辦法一,用strings去system文件里抓.

辦法二,用DUL/AUL/ODU/GDUL等類似工具.相對來說這種方法得到的準確一些

把得出的SYS_UNDO.dmp導入普通用戶,去除status為1和2的回滾段(還原段)后放入到上述空著的2個參數.

open的時候可能還會報ORA-1555,需要推進SCN,以upgrade模式open.

推進SCN的方法很多網友也有分享過,度娘或者谷哥都可以.這里需要重點提示后續有需要的小伙伴的是,搞了兩下沒起來也別灰心.
這次單就推進SCN這塊,我們也折騰了好長時間,甚至一度兩度打算放棄準備DUL了.

先看看oradebug poke的描述：

那首先是找到SCN的內存地址：

等號后面的值,就是當前顯示的SCN了,不過,由于是mount狀態,所以顯示為0. 將當前的SCN(從v$datafile_header#查)隨手加上100萬,轉為十六進制,推一把看看：

再次查看就能看到SCN的值了：

然后“alter database open uprade”, 不斷重復嘗試…….

此外還用了bbed修改塊,還去刪除數據字典記錄…….

終于,數據庫總算open了,數據回來了.

關于更詳細的細節,歡迎關注后續DBA+技術沙龍主題.

DUL和Ahttp://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=2650756087&idx=2&sn=126b19493ff2a87130bc9c80c2dd8112&scene=21#wechat_redirectMDU

萬幸的是,沒有走到最后一步,沒有用DUL來抽數據,不然,以這龜速,少說也是一個星期的事情.

DUL和AMDU都是救命的稻草,我們有能力使用,不代表我們一定要去用.而且我們從不在這個時候跟客戶談收費,作為服務商我們堅持救急如救火!而這些救命工具就如同山洞里的核武器,我們希望每個客戶都能做好前期規劃、維護、備份和容災,讓它們靜靜地躺著,作為一種威懾手段就好了.

關于exadata的維護

再好的東西,你不關心它,總會出問題的,Exadata也不例外.

摘抄《Exadata專家工具箱》里的幾個工具,僅供參考：

sundiag

ExaWatcher

• Diskinfo
• IBCardino
• Iostat
• Netstat
• Ps
• Top
• Vmstat

Exachk

CheckHWnFWProfile

這些命令兩周做一次檢查還是必要的.

關于數據庫運維管理工具

問題發生在別人身上的時候,我們聽起來不可思議,覺得別人是不是傻啊,還是懶啊,其實不是,有的時候真是太忙太忙,忙不過來,這時候需要一套工具來幫助大家.

是的,說的就是你.還記得我們昨天的聊天么,你說,他們是不是傻啊,不做監控么,平時不去看么?我說,你要是管理幾千個數據庫,而你又沒有合適的管理工具,一個邊緣系統發生這種情況,是在所難免的.

那么什么樣的數據庫運維管理工具是合適的呢?

• 數據庫多維度監控
• 日常運維場景化
• 數據庫實時性能分析
• 應用性能追溯

這幾個方面互為補充,逐漸讓運維變得信手拈來.
1、數據庫是一個非常專業的細分領域,傳統的ITOM工具集成的監控功能往往太粗放,所以需要專業的數據庫多維度監控,各項監控指標數據需要實時采集并存放,根據趨勢進行告警.

就拿本案例來說,如果有對Exadata服務存活的監控,問題至少在故障發生前一星期就能得到預警,并及時處理.

2、日常運維場景化
太多的數據庫意味著任何一個點的維護,都需要大量的時間消耗,因此需要集成、封裝一些運維場景.比如：

• 自動化日常數據庫的巡檢
• 告警日志、跟蹤日志的壓縮和歸檔
• 比如定時作業的維護
• 容量趨勢提醒及半自動擴容
• 以及一些自定義的場景(一些客戶幾百套Data Guard的日志修復)
• 歷史數據自動歸檔
• …….

有了這些功能,你是不是可以省下好多時間鉆研新技術,為企業核心技能的更新換代貢獻自己的能量,而不需要整天想著逃離苦海了呢.

3、數據庫實時性能分析
此功能意義很大,看下面兩個場景：

• 比如一個電話打過來,小張,剛才小王說昨天下午2點22到2點30期間數據庫很慢,他們自己重啟了機器解決了,你分析下原因.這個時候你通常只能寄希望于dba_hist_sqlstat,但這個粒度太粗,結果就是往往沒有結果；
• 時間不要離這么久,數據庫發生大量TX鎖資源了,幫忙查看下源頭是誰.你一去看源頭進程是3456,不過人家是idle進程,是一條select語句,顯然不是它鎖的.

如果有一個工具,能幫你實時記錄數據庫的這些信息,而且不用查詢數據庫,而是直接讀取SGA,那這一些問題都能夠分分鐘解決,是不是很爽?

4、應用性能追溯
有些問題,明顯是應用的問題,可是如果你不明確告訴他,是哪個應用模塊,哪個用戶干的,你幾乎就說不清楚是應用的問題.

如果運維管理工具不僅僅能夠幫你發現是哪個SQL語句導致,說出program,而且能告訴你是從哪個路徑爬過來的,是由哪個jar包發起,那是不是一切就顯而易見了呢.讓背鍋的日子見鬼去吧.

那么,存在這樣的數據庫運維管理工具么?

答案是yes.

作者介紹? 楊志洪

• 【DBAplus社群】聯合發起人,新炬網絡首席布道師.Oracle ACE、OCM、《Oracle核心技術》譯者.
• 數據管理專家,擁有十余年電信、銀行、保險等大型行業核心系統Oracle數據庫運維支持經驗,掌握ITIL運維體系,擅長端到端性能優化、復雜問題處理.現主要從事數據架構、高可用及容災咨詢服務
• 文章出處：DBAplus社群(微信公眾號ID：dbaplus)

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4474.html