Oracle SSC團隊的數(shù)據(jù)庫緊急故障救援流程

　　為滿足重大故障的緊急救援需求，SSC提供了如下的專業(yè)化、制度化的救援流程：

　　即一旦客戶IT系統(tǒng)出現(xiàn)1級或升級2級嚴(yán)重問題，客戶DBA可第一時間撥打Oracle公司專門為SSC客戶提供的7*24小時的值班電話，當(dāng)SSC值班工程師接到救援電話之后，會馬上聽取客戶的情況介紹，并判斷問題的嚴(yán)重程度和影響范圍。根據(jù)客戶需求和問題情況，SSC可確定是否可以通過電話或VPN登錄方式，進行遠程解決 。同時，客戶也可撥通服務(wù)實施經(jīng)理（SDM）電話。SDM可與SSC工程師溝通故障情況，并根據(jù)客戶需求確定是否需要安排工程師去現(xiàn)場。如果的確問題非常嚴(yán)重、難以遠程解決， SDM會果斷決定派出客戶當(dāng)?shù)爻鞘谢蜃罱鞘械墓こ處煟瑫r深圳的SSC團隊也會考慮派出工程師趕赴現(xiàn)場。當(dāng)工程師到達客戶現(xiàn)場后，會立即與客戶運維團隊、應(yīng)用開發(fā)商、 硬件等其它廠商進行會商，并根據(jù)問題癥狀分析出問題原因所在，最終提供問題解決方案并加以實施。在故障徹底解決并驗證之后，將提交故障處理分析報告。

　　以下就是Oracle最近在某移動公司出現(xiàn)重大故障時的響應(yīng)速度：

　　時間點操作內(nèi)容… …… …10月30日 21:58在節(jié)點2出現(xiàn)ORA-600 [qertbFetchByRowID]告警，緊接著節(jié)點1也出現(xiàn)ORA-600 [kclchkblk_3]告警10月30日 22:00業(yè)務(wù)方面反映20多張表不能插入10月30日 23:04重啟數(shù)據(jù)庫后，數(shù)據(jù)庫還是出現(xiàn)ORA-600 [kdsgrp1]告警10月31日 2:10SSC值班接到保障電話，開始對問題進行分析10月31日 3:00SSC工程師遠程登陸數(shù)據(jù)庫，對有問題的表的索引進行分析及重建，發(fā)現(xiàn)相關(guān)索引在重啟后恢復(fù)正常。10月31日 6:00發(fā)現(xiàn)大部分表恢復(fù)正常訪問，業(yè)務(wù)基本恢復(fù)，但后臺持續(xù)有報錯。10月31日 6:06容災(zāi)庫嘗試啟動但報錯ora-01172無法啟動10月31日 6：45華東區(qū)工程師從杭州出發(fā)趕往現(xiàn)場支持10月31日 7：00SSC工程師從深圳出發(fā)趕往現(xiàn)場支持，10月31日20:00現(xiàn)場多次checkpoint后，斷開同步后，容災(zāi)庫正常啟動成功… …… …

　　可見當(dāng)該移動客戶在10月31日21：58分發(fā)現(xiàn)Oracle出現(xiàn)故障之后，剛開始通過自身DBA和第三方運維公司技術(shù)人員進行自救。但23：04采取重啟數(shù)據(jù)庫之后，數(shù)據(jù)庫還是出現(xiàn)相關(guān)錯誤，不得已在凌晨2：10撥打了SSC值班電話， SSC一方面通過電話進行問題分析，另一方面在解決了遠程登陸問題之后，于3：00登陸至客戶系統(tǒng)進行分析，并采取了針對性的救援措施，緩解了部分問題。但仍然沒有徹底解決問題，于是，Oracle果斷決定派出工程師，本地工程師6：45從杭州開始趕頭班高鐵趕赴現(xiàn)場，深圳的SSC工程師趕7：00的頭個航班飛赴現(xiàn)場。這就是SSC服務(wù)包為客戶提供的最高級別響應(yīng)速度和服務(wù)級別了！浦東數(shù)據(jù)恢復(fù)

　　而且，就是為了解決該客戶的此次重大故障，盡管最終原因是硬件廠商的磁盤鏡像技術(shù)導(dǎo)致的數(shù)據(jù)損壞， Oracle其實是受害者，但Oracle不惜血本，從本地到遠程，從國內(nèi)到國外，Oracle投入了120多人天，而且還沒有包括管理層、銷售層面的大量投入。最終不僅是Oracle公司發(fā)現(xiàn)了問題根源，并有效解決了該問題，以及延伸的其它問題，而且在未來如何根治該類問題，從IT系統(tǒng)高可用性架構(gòu)、容災(zāi)建設(shè)等方面給予了客戶更廣泛和深遠的建議。

　　這就是SSC緊急救援和主動服務(wù)相結(jié)合給客戶帶來的價值和回報！

　　A類和B類的緊急故障救援

　　SSC服務(wù)包是以系統(tǒng)套數(shù)進行計價的，但服務(wù)的系統(tǒng)又區(qū)分為A類和B類。故障緊急救援方面，針對A類系統(tǒng)的服務(wù)項目如下：

　　1級SR和升級2級SR故障7×24緊急救援

　　1級SR恢復(fù)階段的7*24跟進與分析

　　1級SR和升級2級SR的問題的根源分析跟進（5*8跟蹤）

　　問題的管理與跟蹤（報到SSC平臺的1級和升級2級問題）

　　同時，故障處理由Oracle資深專職組工程師負責(zé)，針對1級故障（SR1）一天兩次的主動通知，2級故障（SR2）每周匯報。根據(jù)oracle全球支持策略，1級故障為7*24跟蹤，1級以下故障為5*8跟蹤。 1級故障當(dāng)系統(tǒng)恢復(fù)正常后， 降級為2級故障進行根本原因定位分析。

　　針對B類系統(tǒng)的服務(wù)則是：僅對1級SR故障進行系統(tǒng)救援支持，系統(tǒng)恢復(fù)服務(wù)后，工程師離場并不再提供任何問題的持續(xù)跟進和原因分析。

　　總之，A類系統(tǒng)的故障救援服務(wù)更為全面，既救命又治病，而B類系統(tǒng)則只救命，并不負責(zé)根治所有疾病。當(dāng)然，A類系統(tǒng)的服務(wù)價格更昂貴。

　　如果客戶系統(tǒng)很多，又都需要緊急故障救援服務(wù)，如何在價格和服務(wù)價格之間進行平衡？建議就是將需要保障的系統(tǒng)都納入SSC服務(wù)范疇，但在A類和B類之間進行平衡，畢竟B類服務(wù)價格相對A類便宜很多。

　　詩檀軟件

　　詩檀軟件緊急響應(yīng)服務(wù)支援覆蓋中國本土地區(qū)，提供7*24小時漢語技術(shù)支持，涵蓋Oracle數(shù)據(jù)庫產(chǎn)品：ORACLE Database/ASM和MYSQL。

　　服務(wù)包括但不限于：

　　針對無法打開的ORACLE數(shù)據(jù)庫，實施特殊的手工修復(fù)

　　基于PRM-DUL專業(yè)oracle數(shù)據(jù)庫恢復(fù)工具恢復(fù)問題數(shù)據(jù)庫中的數(shù)據(jù)

　　修復(fù)數(shù)據(jù)庫中的壞塊

　　解決關(guān)鍵的ORA-00600(600錯誤)問題

　　實施ORACLE數(shù)據(jù)庫的崩潰恢復(fù)/修復(fù)

　　解決關(guān)鍵的ORACLE數(shù)據(jù)庫性能問題，解除性能瓶頸

　　針對ORACLE的致命BUG提供解決方案

　　實施ORACLE補丁安裝

　　協(xié)助解決緊急的ORACLE硬件產(chǎn)品故障

　　當(dāng)你遇到如下恢復(fù)需求時，都可以找我們恢復(fù)：

　　意外DROP了表：請第一時間關(guān)閉應(yīng)用和數(shù)據(jù)庫實例，并對所有數(shù)據(jù)文件做一個備份。

　　意外DROP了column字段

　　意外truncate了表：與drop表類似

　　意外drop tablespace: 不管是drop tablespace帶了including contents 還是including datafiles，都有機會恢復(fù)

　　丟失了system表空間數(shù)據(jù)文件：可以基于用戶數(shù)據(jù)表空間盡可能恢復(fù)數(shù)據(jù)

無錫數(shù)據(jù)恢復(fù)

　　只剩下部分?jǐn)?shù)據(jù)文件： 與丟失了system表空間類似，只要你要的數(shù)據(jù)在對應(yīng)數(shù)據(jù)文件里，我們就能挖掘出來

　　Oracle數(shù)據(jù)字典或啟動自舉對象bootstrap objects存在問題

　　數(shù)據(jù)庫只剩下部分備份文件，而且這些備份文件可能丟失歸檔日志archivelog、丟失增量備份，所以這些備份也是不一致的。

　　ASM diskgroup disk header/metadata存在損壞，導(dǎo)致ASM diskgroup 無法成功mount

　　數(shù)據(jù)島IT學(xué)院

　　http://www.dbdao.com 數(shù)據(jù)島IT學(xué)院是詩檀軟件旗下的IT教育品牌，提供 視頻、題庫、在線學(xué)習(xí)SQL/NOSQL模擬平臺。引導(dǎo)式IT在線教育，關(guān)注大數(shù)據(jù)科學(xué)。

陸家嘴數(shù)據(jù)恢復(fù)