RMAN說，我能備份(18)--制訂備份策略

塗抹ORACLE試閱章節：第8章-Rman說，我能備份

===========================================================================

8.8 制訂備份策略

　　作為一名嚴謹的DBA，必須在資料庫正式上線之前就考慮到，資料由於各種原因導致出錯的可能。出現錯誤本身並不可怕，但如果沒有對應的機制進行處理，那就有可能演變成災難了，對於Oracle資料庫來說，是否存在適當的備份，是能否最終修復資料的關鍵因素之一，因此，如何制訂資料庫的備份策略，就成了很多初學者最常提及的問題。

　　有很多技術書籍在談到策略之類話題時，往往是以非常全面、嚴肅的方式，詳盡闡述涉及這一話題的方方面面，恨不得把伺服器前蓋兒螺絲是否上緊都要扯進來漫談一通。當然不能說人家介紹的方式不對，但是我想，對於真正的應用者來說，並不是所有的知識點都具有很大的意義，而且由於文字枯燥，看得雲山霧罩，特別是初學者，可能看了幾頁也不知道究竟應該做什麼以及怎麼做。

　　針對這一問題，在此我想換一種表達的方式。你想知道究竟需要什麼樣的備份策略，以及當前制訂的備份策略是否合理？很簡單，只需要回答幾個問題就行了。

1．備份的資料庫有可能進行恢復嗎

　　如果答案為否，請響應國家號召，自覺進行至少7天以上隔離。開玩笑，資料庫既然都不準備進行恢復操作，那還談什麼備份策略，甚至都不需要建立備份。

　　如答案為是，那麼請繼續回答下一個問題。

提示：

　　本題是讓大家認識到，備份的目的就是為了恢復，所有為建立備份而進行的準備、設計的方案、建立的策略等都是為了滿足恢復的需要。如果看到這裡，你終於恍然大悟、豁然開朗，恭喜，你已經開竅了，後面的問題不過是提醒你認識到這一點，既然你已大 － 徹 － 大 － 悟，修 － 得 － 圓 － 滿（注，一定要一個字一個字的讀），為師已經沒什麼可以再教你的了，你就下山去吧。O，錯了錯了，俺是說本小節三思該說的都說了，你就看下一章去吧。

2．最早希望恢復到什麼時間點

　　對於某些業務型別，使用者只關注資料庫當前狀態是否正常，至於資料曾經做過什麼操作，什麼時間做的並不重要；也有些業務型別可能會由於特殊的需求，希望看到之前曾經做過的操作，甚至要將資料庫恢復到之前的某個時間點。這兩種需求主要與備份的保留策略有關。對於前者，一般建議選擇基於冗餘數量的備份保留策略，如果只希望保證資料庫穩定執行，那麼可視資料規模的大小，適當儲存幾份最近的備份即可。例如，配置當前備份集的保留策略為保留最近的3份，執行語句如下：

　　對於後者，如果希望能夠看到之前曾經做過的操作，那麼至少歸檔檔案的儲存時間需要適當的延長，因為在對使用者所做的操作進行分析時，LogMiner是最為常用的工具，而LogMiner分析的正是目標資料庫生成的歸檔檔案。

　　如果不僅要看到，還要能將資料恢復到之前的某個時間點，那麼就必須要保證存在目標時間點（或之前）建立的備份，以及相關的歸檔檔案。基於這類需求建議選擇基於冗餘時間的備份保留策略，備份的保留時間設定為最早恢復到的時間即可。例如，設定備份集至少保留7天，執行語句如下：

　　由於備份集也是要佔用儲存空間（往往還不小），因此基於時間的備份保留策略，必須要考慮到儲存裝置空閒空間的問題。

3．系統什麼時間比較空閒

　　由於系統需要涉及大量資料的讀寫，這期間必然會佔用較多的系統資源，如果在資料庫繁忙時段執行備份任務，那麼不僅僅備份需要花費較長時間，還有可能對正常執行的業務系統造成影響。

　　目前通常的做法都是將備份的任務放到凌晨時段執行，對於大多數業務，這個時間系統的訪問量最少，當然DBA在設計備份任務執行時間時，還是要根據自身實際情況而定。

4．資料庫的資料規模有多大

　　三選一：超大（>1TB）、一般（<1TB and >200GB）、小（<200GB）。

　　雖然前面說不考慮硬體因素，不過備份操作本身，考慮到執行效率的因素，想完全跳過硬體是不可能的，上述選項是建立在使用者使用獨立儲存（或磁碟陣列的讀寫效能不低於100M/s）的基礎上的。按照磁碟讀寫大概每秒百M的速率計算，200GB左右資料執行備份僅僅寫操作需要半個小時左右（對應的恢復操作也差不多是這個時間，一般會更長，因此恢復時還需要應用重做日誌），就備份操作來說，每天在系統不繁忙的時間分配幾個小時專門執行，這個時間對於大多數應用都還可以接受。如果當前使用儲存的效能很好，如讀寫效率超過百兆/秒，甚至能達到千兆/秒，或者可以接受更長的備份/恢復時間，那麼資料規模稍大也可以，本例中列舉的選項僅供參考。

　　三個選項中，後兩個選項可以每次都進行全備份，請接著看第6條，而對於第一個選項，也許增量備份更適合，請繼續看第5個問題。

5．資料是否被頻繁修改

　　還是三選一：

　　（1）是：每天資料量中都有超過10%以上的資料修改。

　　（2）否：每天資料基本沒變化，只偶爾有極少量修改。

　　（3）一般：每天資料都在變，但量並不大。

　　對於選項（1），基本上不建議使用增量備份，除非管理的資料庫規模非常非常大。

　　對於選項（2），強烈建議使用增量備份，除非管理的資料庫規模非常非常小。

　　對於選項（3） ，都行啊，建議根據資料庫的規模，再結合問題3來定是否啟用增量吧。

6．能否預估可能給予的恢復操作時間

　　一般情況下正常的系統不會執行恢復操作，當需要對資料庫系統做恢復操作時就代表著系統中出現了問題，雖然說出現的問題可能是偶發性的，但處理問題所需要的時間有可能是確定的，比如資料量確定的情況下，恢復資料檔案和應用日誌的時間是可以估算出來的。

　　對於某些核心的業務系統，任何無公告通知的短暫停止服務甚至都是災難，那麼這種情況下，一旦出現重大問題，僅依靠RMAN想做到快速恢復是不可能的（前面討論過磁碟讀寫速率與資料庫規模的關係），DBA需要通過其他途徑確保系統的高可用性，而不能僅僅是依靠備份。

　　而有些非核心的業務系統，可能每週甚至每個月只有某個時段需要用到（如員工薪資系統），對於這類資料庫系統，由於其執行恢復的時間非常富裕，相對來說制訂備份策略時也就可以更寬鬆。比如並不需要每天都建立備份，而僅在有資料修改發生時執行備份任務。

7 ．是什麼原因導致的錯誤

　　所謂的恢復其實就是根據可能出現的問題制訂的一個計劃，出現什麼樣的問題採用什麼樣的方式處理，這中間還要兼顧恢復技術的可靠性及恢復的成本。

• 使用者誤操作導致的錯誤。使用者被動造成的也好，應用程式不嚴謹導致的也好，總之就是前面的操作導致資料不正確（或者誤刪了資料，或者更新了錯誤的資料），為了應付這種問題，Oracle自身提供了多種修復方式，包括：
  • 使用Flashback進行快速恢復。
  • 通過之前建立的備份，恢復到錯誤產生之前的時間點。
  • 邏輯匯入正確的資料。
• 介質操作導致的錯誤。如果是磁碟損壞（代表硬體），或是誤刪檔案（代表人為）。如果是前者，能否聯絡廠商進行快速維修，對於大型資料庫來說，有可能廠商修復硬體的時間會比執行恢復要快得多；如果是後者，首先檢查是否有作業系統級的檔案冗餘（如聯機重做日誌檔案、控制檔案這類檔案，Oracle自身都提供了冗餘），如果有，則首推使用冗餘的檔案恢復，如果沒有，再考慮使用備份的方式進行恢復。
• 資料塊損壞導致的錯誤。在這種情況下可以使用RMAN的備份進行塊級的修復，效率高並且速度快。

　　備份和恢復之間絕對不是各自孤立存在，恢復依賴於備份，備份策略基本上也就決定了恢復方式、能恢復的資料及恢復的效率等。因此備份策略的制訂要視你的恢復需求，以及恢復策略而定（當然同時還受限於軟硬體的實際情況）。

　　在制訂恢復策略時，根據假定可能遇到的那些問題，羅列出的能夠幫助我們修復錯誤的解決方案（通常都不會只有一種選擇），以及實際情況（在建立備份策略的時候需要具體問題具體分析，如作業系統的資源配置，資料庫系統的執行要求等都會對備份策略產生重要影響），來實施具體的恢復方案了。

　　最後一個問題，當備份策略設計完成，並且也按照該備份策略建立了備份，但如何確保該備份策略可靠、有效呢？方式只有一個，實踐測試，因此當備份建立完成之後工作並不算完，最後也是最重要的環節，就是測試建立的備份是否能夠真正滿足需求。

=================================================

• 前往"塗抹ORACLE"專區
• 下載書中原始碼|豆瓣評論
• 購買 |China-Pub|噹噹|卓越|淘寶

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7607759/viewspace-629308/，如需轉載，請註明出處，否則將追究法律責任。