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

跟Salesforce巧合的是，大家都是運行在Exadata上，不幸的是Salesforce丟失了4個小時數據（后續沒看到新聞稿，是否又追回了部分）業務停頓，那我今天遇到的要麻煩更多。

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

問題發生得很不可思議，又很理所當然，細節就不說了。總之比較糟糕：存放數據文件的diskgroup不能加載（mount），celldisk狀態是unknown，部分asm disk的header是invalid的，就連它自動備份的塊也是invalid的，有磁盤物理損壞，物理損壞的磁盤沒有的mirror也失效了。接近10TB的數據，想想也頭疼吧。

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

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

???

將數據庫文件抽取出來

嘗試open

如失敗再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

對于自定義格式的，要從.6去抽取元數據，然后找到其對應的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格式抽取方式抽取出所有數據文件。

值得一說的是，我們遭遇了一個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了，數據回來了。

??DUL和AMDU

萬幸的是，沒有走到最后一步，沒有用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"，原文發布時間：2016-07-16

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。