細數基於ORACLE 資料庫環境的常見資料災難解決方式

一、故障描述：基於 ORACLE 資料庫環境的常見資料災難

故障表現：

1 、 ORACLE 資料庫無法啟動或無法正常工作。

2 、 ORACLE ASM 儲存破壞。

3 、 ORACLE 資料檔案丟失。

4 、 ORACLE 資料檔案部分損壞。  

5 、 ORACLE DUMP 檔案損壞。    

二、解決方案

◆ 檢測      

1 、檢測是否存在硬體故障，如硬體故障，轉硬體處理

2 、以只讀方式檢測故障表現是否與使用者描述相同

◆ 恢復

1 、備份：以只讀方式對故障儲存做完整映象 ( 參考附錄 )

2 、在備份中進行資料分析及恢復操作。

3 、通常，恢復後的資料會暫存在另一個儲存體上

◆ 驗收

對恢復好的資料進行驗證，確認其正確性。如確認，交費 –> 移交原介質及已恢復資料 –> 出具發票 ( 收據 ) 及報告。

如無法認可資料恢復結果，交回原介質，不收服務費，可免費出具報告。

 

三、資料恢復的可能性

★  ORACLE 資料庫無法啟動或無法正常工作：

如果突發性的出現上述故障，通常可恢復性極高。從技術底層上看，如果 SYSTEM 表未損壞，資料較容易恢復；如果 SYSTEM 表損壞，資料需要人工核對表結構，恢復時較為耗時。

     

★  ORACLE ASM 儲存破壞：

如 ASM 重置，或組成 ASM 的部分裝置成員故障，出錯後無大量新資料寫入，資料通常可以很好的恢復。

 

★  ORACLE 資料檔案丟失：

不論 ORACLE 資料檔案是刪除、格式化還是未知原因丟失，只要沒有新的資料寫入，不管是什麼作業系統，都可以透過 ORACLE 內部的資料組織規則將資料檔案恢復出來，但資料檔案的名稱可能需要人工核對。

 

★  ORACLE 資料檔案部分損壞：

如 ORACLE 資料檔案部分損壞 ( 如覆蓋 ) ，透過複雜的資料提取和重組，通常可以將未損壞部分的資料記錄恢復出來，並可新建表追加進去，但會相當耗時。

★  ORACLE  DUMP 檔案損壞：

ORACLE DUMP 檔案損壞，將損壞部分去除，其餘部分均可正常追加至資料表。

 

四、時間

1TB 以下的儲存空間 ( 不是要恢復的資料容量 ) ，通常 2 個工作日內可完成； 1TB 以上的隨儲存容量的增加，恢復週期通常也會增加。

資料表如果很大，提取資料、整理資料也會花費大量時間，具體時間需據具體情況而定。

 

[ 小貼士 ]

★  針對軟體故障，在資料丟失後，應儘可能減少對儲存的操作，有時候，即使是開著機，什麼都不做，也可能導致災難進一步加劇。條件允許的話，最好損壞後，對磁碟或儲存卷做完整備份

★  針對硬體故障，在裝置無法正常工作後，應儘可能少的加電，以避免裝置的進一步損壞。

   

如何避免    

做好備份方案，儘可能避免單儲存備份，如資料非常重要，可考慮異地備份。