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

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

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

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

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

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

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

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

AMDU: ORACLE針對ASM開發(fā)的源數(shù)據(jù)轉(zhuǎn)儲工具,其全稱為ASM Metadata Dump Utility

抽取的具體步驟：

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

抽取數(shù)據(jù)文件

第一步：抽控制文件

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

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

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

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

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

第二步：找數(shù)據(jù)文件和日志文件

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

然后把數(shù)據(jù)庫啟動到mount狀態(tài),查找數(shù)據(jù)文件和日志文件：

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去抽取元數(shù)據(jù),然后找到其對應(yīng)的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格式抽取方式抽取出所有數(shù)據(jù)文件.

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

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

嘗試Open數(shù)據(jù)庫

當(dāng)?shù)搅诉@一步的時候,其實就跟尋常的數(shù)據(jù)庫恢復(fù)類似了. 我們同樣在open的時候遇到了ORA-1555、ORA-704錯誤.

記錄下我們用到的參數(shù)和事件.

event：

隱含參數(shù)：

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

有兩個辦法來解決：

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

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

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

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

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

先看看oradebug poke的描述：

那首先是找到SCN的內(nèi)存地址：

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

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

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

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

終于,數(shù)據(jù)庫總算open了,數(shù)據(jù)回來了.

關(guān)于更詳細(xì)的細(xì)節(jié),歡迎關(guān)注后續(xù)DBA+技術(shù)沙龍主題.

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

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

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

關(guān)于exadata的維護

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

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

sundiag

ExaWatcher

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

Exachk

CheckHWnFWProfile

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

關(guān)于數(shù)據(jù)庫運維管理工具

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

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

那么什么樣的數(shù)據(jù)庫運維管理工具是合適的呢?

• 數(shù)據(jù)庫多維度監(jiān)控
• 日常運維場景化
• 數(shù)據(jù)庫實時性能分析
• 應(yīng)用性能追溯

這幾個方面互為補充,逐漸讓運維變得信手拈來.
1、數(shù)據(jù)庫是一個非常專業(yè)的細(xì)分領(lǐng)域,傳統(tǒng)的ITOM工具集成的監(jiān)控功能往往太粗放,所以需要專業(yè)的數(shù)據(jù)庫多維度監(jiān)控,各項監(jiān)控指標(biāo)數(shù)據(jù)需要實時采集并存放,根據(jù)趨勢進行告警.

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

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

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

有了這些功能,你是不是可以省下好多時間鉆研新技術(shù),為企業(yè)核心技能的更新?lián)Q代貢獻(xiàn)自己的能量,而不需要整天想著逃離苦海了呢.

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

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

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

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

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

那么,存在這樣的數(shù)據(jù)庫運維管理工具么?

答案是yes.

作者介紹? 楊志洪

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

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/4474.html