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

跟Salesforce巧合的是，大家都是運(yùn)行在Exadata上，不幸的是Salesforce丟失了4個(gè)小時(shí)數(shù)據(jù)（后續(xù)沒(méi)看到新聞稿，是否又追回了部分）業(yè)務(wù)停頓，那我今天遇到的要麻煩更多。

近期Exadata故障比較多，比較重要的是硬件生命周期所致，X2從2010年9月開(kāi)始發(fā)布上線，到現(xiàn)在已經(jīng)將近6年，就算傳統(tǒng)“高端”小型機(jī)也到該下線的時(shí)候了。提醒使用Exadata的朋友們做好備份，否則，你可能也要經(jīng)歷一場(chǎng)難忘的救援經(jīng)歷。

問(wèn)題發(fā)生得很不可思議，又很理所當(dāng)然，細(xì)節(jié)就不說(shuō)了。總之比較糟糕：存放數(shù)據(jù)文件的diskgroup不能加載（mount），celldisk狀態(tài)是unknown，部分asm disk的header是invalid的，就連它自動(dòng)備份的塊也是invalid的，有磁盤(pán)物理?yè)p壞，物理?yè)p壞的磁盤(pán)沒(méi)有的mirror也失效了。接近10TB的數(shù)據(jù)，想想也頭疼吧。

再說(shuō)具體數(shù)據(jù)搶救工作之前，還是提醒下使用ASM/Exadata的朋友們，至少搭建個(gè)Data Guard吧，剛好建榮也做了這方面的分享，趕緊去讀讀。

鑒于問(wèn)題非常棘手，綜合各方信息，我們做了如下的方案：

???

將數(shù)據(jù)庫(kù)文件抽取出來(lái)

嘗試open

如失敗再DUL

??

要將數(shù)據(jù)庫(kù)文件（控制文件、數(shù)據(jù)文件、日志文件）從沒(méi)有加載的磁盤(pán)組中抽取出來(lái)，需要借助于AMDU。

AMDU: ORACLE針對(duì)ASM開(kāi)發(fā)的源數(shù)據(jù)轉(zhuǎn)儲(chǔ)工具，其全稱(chēng)為ASM Metadata Dump Utility

抽取的具體步驟：

• 從alert日志中找到啟動(dòng)參數(shù)（包括控制文件），編輯成新的參數(shù)文件/tmp/pfile

• 從pfile中找到控制文件的位置，并用amdu抽取

• 用抽取出來(lái)的控制文件，將數(shù)據(jù)庫(kù)mount起來(lái)

• 從mount庫(kù)把所有數(shù)據(jù)文件找出來(lái)，可能有2種格式

• OMF格式（數(shù)據(jù)文件帶Oracle自動(dòng)生成的數(shù)字）

• 自定義格式（手賤的），處理起來(lái)麻煩一些

• 日志文件同上處理

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

第一步：抽控制文件

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

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

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

amdu -diskstring '/o/*/?*' -extract data.266

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

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

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

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

select name from v$datafile;select member from v$logfile;

運(yùn)氣好，都是這樣的（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

運(yùn)氣不好，可能是有這樣的（自定義格式）：

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

對(duì)于OMF格式的，仿照抽取控制文件，一個(gè)個(gè)抽：

amdu -diskstring '/o/*/?*' -extract data.256

對(duì)于自定義格式的，要從.6去抽取元數(shù)據(jù)，然后找到其對(duì)應(yīng)的number

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ù)文件。

值得一說(shuō)的是，我們?cè)庥隽艘粋€(gè)3T的bigfile，extract消耗了將近24小時(shí)= =。--NFS掛過(guò)去的文件系統(tǒng)速度特別慢= =

最后對(duì)所有的文件用dbv做一次校驗(yàn)，有沒(méi)有物理壞塊。

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

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

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

event：

隱含參數(shù)：

這里比較討厭的是rollback segments不容易確定，因?yàn)槟闶莔ounted狀態(tài)的數(shù)據(jù)庫(kù)，連v$rollname都查詢不了。

有兩個(gè)辦法來(lái)解決：

辦法一，用strings去system文件里抓。

辦法二，用DUL/AUL/ODU/GDUL等類(lèi)似工具。相對(duì)來(lái)說(shuō)這種方法得到的準(zhǔn)確一些

?

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

open的時(shí)候可能還會(huì)報(bào)ORA-1555，需要推進(jìn)SCN，以u(píng)pgrade模式open。

推進(jìn)SCN的方法很多網(wǎng)友也有分享過(guò)，度娘或者谷哥都可以。這里需要重點(diǎn)提示后續(xù)有需要的小伙伴的是，搞了兩下沒(méi)起來(lái)也別灰心。

這次單就推進(jìn)SCN這塊，我們也折騰了好長(zhǎng)時(shí)間，甚至一度兩度打算放棄準(zhǔn)備DUL了。

先看看oradebug poke的描述：

?

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

?

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

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

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

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

終于，數(shù)據(jù)庫(kù)總算open了，數(shù)據(jù)回來(lái)了。

??DUL和AMDU

萬(wàn)幸的是，沒(méi)有走到最后一步，沒(méi)有用DUL來(lái)抽數(shù)據(jù)，不然，以這龜速，少說(shuō)也是一個(gè)星期的事情。

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

??關(guān)于exadata的維護(hù)

再好的東西，你不關(guān)心它，總會(huì)出問(wèn)題的，Exadata也不例外。

摘抄《Exadata專(zhuān)家工具箱》里的幾個(gè)工具，僅供參考：

sundiag

ExaWatcher

• Diskinfo

• IBCardino

• Iostat

• Netstat

• Ps

• Top

• Vmstat

Exachk

CheckHWnFWProfile

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

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

問(wèn)題發(fā)生在別人身上的時(shí)候，我們聽(tīng)起來(lái)不可思議，覺(jué)得別人是不是傻啊，還是懶啊，其實(shí)不是，有的時(shí)候真是太忙太忙，忙不過(guò)來(lái)，這時(shí)候需要一套工具來(lái)幫助大家。

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

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

• 數(shù)據(jù)庫(kù)多維度監(jiān)控

• 日常運(yùn)維場(chǎng)景化

• 數(shù)據(jù)庫(kù)實(shí)時(shí)性能分析

• 應(yīng)用性能追溯

這幾個(gè)方面互為補(bǔ)充，逐漸讓運(yùn)維變得信手拈來(lái)。

1、數(shù)據(jù)庫(kù)是一個(gè)非常專(zhuān)業(yè)的細(xì)分領(lǐng)域，傳統(tǒng)的ITOM工具集成的監(jiān)控功能往往太粗放，所以需要專(zhuān)業(yè)的數(shù)據(jù)庫(kù)多維度監(jiān)控，各項(xiàng)監(jiān)控指標(biāo)數(shù)據(jù)需要實(shí)時(shí)采集并存放，根據(jù)趨勢(shì)進(jìn)行告警。

就拿本案例來(lái)說(shuō)，如果有對(duì)Exadata服務(wù)存活的監(jiān)控，問(wèn)題至少在故障發(fā)生前一星期就能得到預(yù)警，并及時(shí)處理。

2、日常運(yùn)維場(chǎng)景化

太多的數(shù)據(jù)庫(kù)意味著任何一個(gè)點(diǎn)的維護(hù)，都需要大量的時(shí)間消耗，因此需要集成、封裝一些運(yùn)維場(chǎng)景。比如：

• 自動(dòng)化日常數(shù)據(jù)庫(kù)的巡檢

• 告警日志、跟蹤日志的壓縮和歸檔

• 比如定時(shí)作業(yè)的維護(hù)

• 容量趨勢(shì)提醒及半自動(dòng)擴(kuò)容

• 以及一些自定義的場(chǎng)景（一些客戶幾百套Data Guard的日志修復(fù)）

• 歷史數(shù)據(jù)自動(dòng)歸檔

• .......

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

3、數(shù)據(jù)庫(kù)實(shí)時(shí)性能分析

此功能意義很大，看下面兩個(gè)場(chǎng)景：

• 比如一個(gè)電話打過(guò)來(lái)，小張，剛才小王說(shuō)昨天下午2點(diǎn)22到2點(diǎn)30期間數(shù)據(jù)庫(kù)很慢，他們自己重啟了機(jī)器解決了，你分析下原因。這個(gè)時(shí)候你通常只能寄希望于dba_hist_sqlstat，但這個(gè)粒度太粗，結(jié)果就是往往沒(méi)有結(jié)果；

• 時(shí)間不要離這么久，數(shù)據(jù)庫(kù)發(fā)生大量TX鎖資源了，幫忙查看下源頭是誰(shuí)。你一去看源頭進(jìn)程是3456，不過(guò)人家是idle進(jìn)程，是一條select語(yǔ)句，顯然不是它鎖的。

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

4、應(yīng)用性能追溯

有些問(wèn)題，明顯是應(yīng)用的問(wèn)題，可是如果你不明確告訴他，是哪個(gè)應(yīng)用模塊，哪個(gè)用戶干的，你幾乎就說(shuō)不清楚是應(yīng)用的問(wèn)題。

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

那么，存在這樣的數(shù)據(jù)庫(kù)運(yùn)維管理工具么？

答案是yes。

作者介紹? 楊志洪

• 【DBAplus社群】聯(lián)合發(fā)起人，新炬網(wǎng)絡(luò)首席布道師。Oracle ACE、OCM、《Oracle核心技術(shù)》譯者。

• 數(shù)據(jù)管理專(zhuān)家，擁有十余年電信、銀行、保險(xiǎn)等大型行業(yè)核心系統(tǒng)Oracle數(shù)據(jù)庫(kù)運(yùn)維支持經(jīng)驗(yàn)，掌握ITIL運(yùn)維體系，擅長(zhǎng)端到端性能優(yōu)化、復(fù)雜問(wèn)題處理。現(xiàn)主要從事數(shù)據(jù)架構(gòu)、高可用及容災(zāi)咨詢服務(wù)。

本文來(lái)自云棲社區(qū)合作伙伴"DBAplus"，原文發(fā)布時(shí)間：2016-07-16

總結(jié)

以上是生活随笔為你收集整理的【力荐】Exadata火线救援：10TB级数据修复经典案例详解！的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。