【案例討論】災難與拯救 資料安全精彩案例大討論！歡迎大家踴躍參與！

本期活動特邀幾位社群版主，oracle資料庫專家與大家共同交流探討：
eygle—中國地區Oracle ACE總監，也是中國地區首位Oracle ACE，雲和恩墨創始人,ITPUB論壇超級版主
secooler—Oracle ACE,國際航空運輸協會（IATA）任高階資料架構師,OCM聯盟（www.ocmu.org）創始人、ITPUB Oracle專題深入討論版版主
yxyup—現任職知名網路招聘公司系統運維負責人,曾在多家培訓中心進行Oracle教學,為企業單位提供了高質量的技術培訓,ITPUB Oracle資料庫管理版版主
kelsoncong—現任Oracle Fusion HCM Release Team運維成員，多年資料庫運維和開發經驗,ITPUB Oracle資料庫管理版版主

討論話題：

1.保護業務資料有哪些方法？

2.威脅到資料安全的因素有哪些？

3.通過以下這份案例，給您帶來哪些警示？

本期活動精彩案例分享：
【資料安全】
一次驚心動魄的ASM磁碟頭損壞故障處理過程帶來的深思
  資料通常比喻為企業的血液和生命，資料安全一直是大家非常重視的話題。
  Oracle資料庫，為了防止資料丟失以及構建高可用環境給出了多種架構方式。例如，為了防止Oracle例項級別的單點故障提供了RAC技術（Real Application Clusters，真正的應用叢集），RAC以Share Everything的架構方式使多個主機例項可以共享一套儲存上的資料，從而避免了由於個別例項出現故障導致資料庫不可用；RAC技術僅僅給出了例項層面的高可用解決方案，為了防止儲存層面的單點故障，Oracle又提出了Data Guard（資料衛士）技術，無論是邏輯Data Guard還是物理Data Guard都從儲存層面解決了單點故障，同時也是災備技術的最佳選擇。基於RAC和Data Guard技術，Oracle進一步又推出了MAA架構方式，即主站點是RAC架構方式，備用站點也是RAC架構方式，主備站點之間通過Data Guard技術使用redo傳輸變化的資料，確保備站點與主站點之間達到實時或者準實時的資料一致。
  除此之外，Oracle還提供了各種備份恢復工具，比如物理備份恢復工具RMAN、邏輯備份恢復工具EXP/IMP EXPDP/IMPDP。基於這些工具便可以定製一套有效的備份恢復策略，以便防止資料丟失。
  以上技術手段都是確保資料不丟失的必要條件，絕非充分條件！這些技術固然重要，但是與之相比，更加重要的是“人”的因素。再優秀的技術，如果沒有人來定期做健康檢查並排查潛在問題的話，這些都是“浮雲”。這裡給大家分享一個最近剛剛為客戶處理完的一個Case。起到警示的作用。

【資料庫環境描述】：
資料庫型別：    某政府核心生產系統
影響範圍：      全國性
資料量：        8T
主機型別：      IBM 570
資料庫版本：    10.2.0.4.0
ASM版本：       10.2.0.4.0
資料庫架構方式：兩節點RAC架構方式；儲存使用ASM技術，並且ASM磁碟頭沒有備份；未部署Data Guard災備站點；歸檔模式，使用RMAN做全庫及增量備份。

【故障現象】：
在手工為表空間新增資料檔案的時候，觸發ASM磁碟頭損壞，ASM的alert日誌中記錄瞭如下資訊：
Sat Jun  9 01:45:51 2012
WARNING: cache read a corrupted block gn=1 dsk=39 blk=18 from disk 39
NOTE: a corrupted block was dumped to the trace file
ERROR: cache failed to read dsk=39 blk=18 from disk(s): 39
ORA-15196: invalid ASM block header [kfc.c:8033] [check_kfbh] [2147483687] [18] [2154781313 != 2634714205]
System State dumped to trace file /home/oracle/admin/+ASM/bdump/+asm1_arb0_602136.trc
NOTE: cache initiating offline of disk 39  group 1
WARNING: offlining disk 39.3734428818 (BDC_DATA_0039) with mask 0x3
NOTE: PST update: grp = 1, dsk = 39, mode = 0x6

【艱難的資料恢復過程】：
  第一次嘗試：直接恢復ASM磁碟頭資料
  嘗試使用Oracle KFED（Kernel Files Editor）工具修改ASM磁碟頭，如果這種方式能夠順利的恢復ASM磁碟頭的話，將是一種完美的結局，然而事與願違，此時的ASM磁碟頭損壞非一般型別的損壞（故障原因中給出分析），使用KFED無法完成恢復。第一次夢魘不期而遇。
  第二次嘗試：使用RMAN進行資料恢復
  既然每天都做RMAN的備份，正常情況下便可以使用RMAN進行資料恢復。因此，找來裝置上嘗試資料恢復（提醒：千萬不要在生產環境上嘗試恢復，保留現場很重要！），8T的資料拷貝以及恢復時間都是不可想象的，經過漫長的17小時的恢復，夢魘再一次來襲，在嘗試恢復的過程中突然發現，RAC的第二節點上的歸檔日誌不完整，僅剩半個月之前的歸檔日誌，這是不可饒恕的，這也就意味著，使用RMAN工具最多隻能恢復到15天前的資料，最近半個月的資料將蕩然無存。這便是典型的“無人值守”導致的災難。
  第三次嘗試：盡最大努力挽回資料
  由於RAC第二節點歸檔日誌的丟失導致最多可以恢復到15天前的資料，但也不要放棄希望，盡一切努力進行資料恢復。再次嘗試使用RMAN恢復資料到15天前。正如小說中常見的情景，此時，夢魘又一次降臨到這套可憐的資料庫！即便恢復到了15天前的資料，發現資料庫依然無法正常open。嘗試各種手段，啟用隱含引數等方法，亦不奏效。使用各種手段強制open資料庫後alert日誌中頻現ORA-00600錯誤，即使在邏輯匯出資料的過程中，都在頻繁的丟擲ORA-00600錯誤。最終以備份介質無效無法完美恢復而終止。
  第四次終極處理方法：使用工具直接抽取ASM磁碟組中的資料
  在客戶幾近崩潰的時候，最終選擇了直接資料抽取方法進行恢復，直接抽取ASM磁碟組中的資料，構造出資料檔案的全貌，又是一個10多小時的漫長資料抽取恢復時間。經過漫長的等待之後，經驗證，資料完美恢復完畢，沒有讓客戶丟失任何一條重要資料！

【故障原因】：
  此次故障推測是由於底層磁碟的對映混亂導致的，比如主機重啟後導致disk number變化，導致Oracle認為ASM磁碟組的某塊盤是voting disk，進而錯誤的寫入了心跳資訊，覆蓋了原來位置上的ASM後設資料ALT，這樣一旦有大規模的reblance操作需要改上述ALT時，ASM便出現了上述故障。這種故障是無法通過簡單的KFED工具進行恢復的。

【資料安全故障總結】：
  這個Case中的故障本身並不可怕，可怕的是這個過程中出現的各種險情，發人深思。我們經常提到“備份重於一切”、“有備無患”等DBA職業操守。我認為最佳的詮釋應該再加一條：在可信的架構方式下，定期對備份介質進行有效性驗證，及災備環境DRP演練的前提下！
  針對此次故障的前因後果，給出以下建議：
  1.給出高可用解決方案；建議使用Data Guard技術做遠端災備；
  2.RMAN物理備份以及邏輯備份介質，要定期做備份介質有效性驗證；
  3.“人”的因素，制定嚴格的備份恢復檢查機制，對備份以及災備環境進行日常檢查；
  4.前期的架構設計很重要；
  5.……

注：特別感謝secooler版主為大家提供的精彩案例！！歡迎大家踴躍討論

我的回覆：

1.保護業務資料有哪些方法？
我首先從硬手段上講
（1）常規的冷備份，如果允許shutdown的話，可以使用最原始的冷備份
（2）物理備份恢復工具RMAN，熱備份
（3）邏輯備份恢復工具EXPDP，資料泵
（4）Data Guard 主備庫模式，即專用備份節點
（5）Golden Gate 高階複製軟體
（6）Exadata 軟硬體一體機備份
（7）啟用專用冗餘伺服器，把資料備份到多個地方，當某一份資料出現故障時我們還有其他備份可用
我在從軟手段上講
（1）全方位的資料監控：一個好的監控軟體可以讓你事半功倍，舉例 我們公司在運維資料庫中就採用了quest 公司spotlight監控軟體，它可以提前預示一些警告，把災難抹殺在搖籃裡
（2）對高風險操作，需要安全測試和評估，例如 RM 操作是危險的，在不確定的情況下，可以先重新命名測試，沒有問題後在刪除
（3）制定高規範許可權和登陸制度，對不同級別的人員只給予夠用的許可權或者臨時許可權，監控登陸記錄，對不符合要求的人員給予登陸拒絕
（4）制定審計策略，可以審計 delete  truncate drop 等危險操作，例如 誰  哪張表  什麼時候  做了哪些動作  可以追溯到源頭，認定責任  評估事態
（5）備份介質有效性驗證，對備份介質的有效性經常驗證，並保證在恢復時是可信的，可依靠的
（6）高可用架構設計，例如現在流行的 大規模分散式儲存叢集架構，採用這種架構我們可以有效的避免單點故障，從而有效的保護我們的資料
2.威脅到資料安全的因素有哪些？
常見因素
（1）病毒發作
（2）黑客入侵
（3）儲存裝置損壞
（4）資訊盜取
（5）說白了最主要的還是人的因素，由於人為盲目操作導致的資料丟失 例  我前幾天就幫助同事恢復了資料檔案丟失問題，他在不瞭解.dbf檔案情況下 使用了 rm -rf *.dbf
非常見因素
（1）不可抗力自然災害
（2）電源故障
（3）機箱風扇故障，案例 我們公司的新疆專案由於機箱風扇停止，溫度升高導致主機當機，資料丟失
（4）bug問題，也威脅著資料安全，例如 oracle-00600錯誤  在上面的“ASM磁碟頭損壞案例”中表現的淋漓盡致
3.通過以下這份案例，給您帶來哪些警示？
（1）給我第一個警示：千萬不能在生產庫上嘗試沒有把握的恢復，保留現場定位問題很重要
（2）給我第二個警示：做了備份也不能高枕無憂，完全放心下來，需要定期做備份有效性驗證，保證我們的備份是實時可用有效的
（3）給我第三個警示：crosscheck  歸檔檔案，使其完整有效，也成我們高度重視內容之一
（4）給我第四個警示：高可用HA架構，是保證業務續航能力首要平臺
（5）給我第五個警示：定期進行災備演練，增強容災意識
leonarding
2012.8.3
天津&早