深度乾貨 | 如何藉助雲原生搞定Oracle備份快速恢復？

雲原生資料庫備份DBS新版本釋出

預約觀看直播

Oracle備份面臨的挑戰

在傳統企業裡，經常會用Oracle資料庫去承載業務重要核心資料，同時Oracle針對不同的恢復場景提供了靈活多樣的恢復操作方法，靈活的設計給備份和恢復帶來了更多的複雜性，因此Oracle的備份管理相比於MySQL而言，對DBA在專業性上有更高的要求。

比如說，Oracle環境有多種：

Standalone，Standalone+DataGuard，RAC，RAC+DataGuard，雙機Oracle等，其中DataGuard還有多種執行模式，不同的Oracle環境的備份有一些細微差別，一個備份指令碼很難同時滿足這些場景，如果業務系統有多套Oracle環境，備份將會非常複雜，例如如何確保全量備份集總是有效的(可恢復的)等等。我們現在以一個具體的案例來說明這個問題：一致性全量備份。

一致性全量備份

何為一致性全量備份

在我們這篇文章裡"一致性全量備份"的定義如下：

• 條件1：備份集中存在一個連續完整的歸檔日誌序列，其開始SCN和結束SCN能夠覆蓋備份開始時的最小的資料檔案checkpoint SCN和備份結束時最大資料檔案SCN（只讀和離線資料檔案除外）。

• 條件2：備份集中包含恢復所用的全部資料檔案，控制檔案和引數檔案。

• 條件3：備份集中包含儘可能新的歸檔日誌。

條件1和2確保全量備份集的完整性，使得備份集可以獨立的被恢復（恢復出一致的狀態）。條件3可以確保全量備份集始終是最新的，不會出現“丟資料”的場景。滿足上述條件的備份集叫做一致性全量備份集。

一致性全量備份的好處

一致性全量備份集有哪些好處呢？

• 方便轉儲：通常一個備份集是一個儲存目錄，簡單的打包就可以轉儲到磁帶，異地轉儲。

• 簡化恢復：恢復時不依賴其他備份集，例如定時歸檔日誌備份產生的備份集失效了不會影響全量備份集的有效性，一致性全量備份集總是可以獨立的恢復。

一致性全量備份的難點

圖1 一致性全量備份

下面我們看一下在哪些場景中，我們有可能得不到一致性全量備份集，圖1 中的case2-case5就是典型的非一致性全量備份。

• 在【case2】中缺失了部分的歸檔日誌，違反了【條件1】中連續完整的歸檔日誌序列這個條件。如 圖2 所示，如果Primary和Standby之間網路出現了異常，此時主庫可以正常地生成新的歸檔日誌，但是Standby上將無法生成新的歸檔日誌，當網路恢復後，DataGuard會從Primary上自動同步最新的歸檔日誌，同時也會同步這部分缺失的歸檔日誌，但是如果在執行全量備份期間，缺失的歸檔日誌還沒有被同步到Standby上，那麼此時的全量備份集中的歸檔日誌將會包含空洞，導致無法恢復。

• 在【case3】中歸檔日誌的的最小SCN和資料檔案最小SCN之間存在gap。圖2 中的所有執行模式都有可能出現這個問題，例如使用者在清理Standby上的歸檔日誌時執行了delete force就會導致RMAN將那些還沒有被應用的歸檔日誌刪除掉。

• 在【case4】中最新的歸檔日誌SCN和最大的資料檔案SCN存在gap。圖2 中的【模式三】有可能出現這個問題，因為它是先同步redo到Standby的redo log file中，當主庫執行Switch log之後，Standby上才會將redo log file歸檔到歸檔日誌。如果Primary和Standby之間網路出現了問題，那麼Primary依然能夠正常生成歸檔日誌，但是備庫卻不能執行redo log file的切換，不能生成新的歸檔日誌，導致歸檔日誌的SCN小於資料檔案的最大SCN。相反，【模式一】和【模式二】則一定不會出現這種case，因為他們是先產生歸檔日誌，然後再應用歸檔日誌到資料檔案，因此其歸檔日誌最大SCN一定是大於等於資料檔案最大SCN的。

• 在【case5】中備份集中丟失了部分的資料檔案，例如，使用者開啟了（backup optimization）配置，此時RMAN會開啟備份最佳化功能，如果某些檔案或者歸檔日誌被其他人備份過了，那麼將不會再次備份。

• 在【條件2】中， 如果Primary上的歸檔日誌或者Redo長時間無法同步到Standby上，此時可能能夠得到滿足【case1】的全量備份，既此時的備份是成功的，也能夠獨立的恢復，但是該全量備份沒有包含主庫最新的歸檔日誌，導致我們的備份不是最新有效的全量備份。

圖2 DataGuard執行模式

由於Primary和Standby的執行原理不一樣，在實際業務實現時，會遇到更多的穩定性問題，實現一致性全量備份需要解決如下幾個問題：

• 如何防止Standby上的備份獲取不到最新的Primary的Redo日誌。

• 當Primary和Standby之間網路延遲較大或者出現網路分割槽，導致Redo傳輸太慢或者長時間無法傳輸時，備份如何解決。

• 如何發現Primary或者Standby上的歸檔日誌出現了gap，以及如何解決gap。

• 如何避免備份的資料檔案或者歸檔日誌出現損壞的資料塊。

此外，在備份的過程中，您可能還要考慮如下一些問題：

• 定時的清理已經備份過的歸檔日誌。

• 防止備份資料中毒/惡意刪除，確保任何時候都至少有一個可用的備份集用來做恢復。

• 為了滿足監管要求，實現備份資料的多地域儲存。

DBS Oracle 備份

上述的兩個舉例展示了Oracle備份的複雜性和較高的技術難度。而對於以上提出的問題，DBS結合阿里巴巴之前多年的Oracle生產和運維經驗透過完全自主研發，打造了DBS Oracle備份產品，幫助阿里雲客戶方便低成本地備份和保護Oracle資料資產。

圖3 DBS Oracle備份示意圖

如圖3，DBS Oracle 備份與恢復採用 Oracle 內建的 RMAN 技術，實現 Oracle 資料庫的熱備份和恢復。備份管理員在 DBS控制檯 簡單配置備份策略，系統會根據使用者配置的備份策略自動地建立資料備份任務，DBS系統向Oracle宿主機DBS備份客戶端傳送備份命令，DBS備份客戶端執行RMAN備份指令碼，流式無入侵地讀取備份資料，並對資料執行壓縮/加密等處理，最後將備份資料寫入到雲上加密的備份儲存。整個備份過程不侵佔使用者本地磁碟空間和IO，對資料庫完全無入侵。而對於資料恢復任務，備份管理員在 DBS控制檯 點選發起恢復任務，此時DBS排程會向在Oracle宿主機上的 DBS備份客戶端 傳送恢復命令，DBS備份客戶端 執行對應的RMAN指令碼進行資料恢復。

基礎能力
它在當前版本具備的技術特點如下：

• 完全自研：阿里巴巴之前是Oracle的使用大戶，結合之前阿里集團對Oracle生產運維的經驗完全自研打造Oracle備份恢復產品，以幫助使用者實現低成本探索資料庫及資料庫備份國產化演進路徑。
• 相容的平臺：支援Linux平臺下的Oracle保護。
• 支援的資料庫版本：10g/11g/12c/18c/19c。
• 支援的備份型別：全量備份和事務日誌備份。
• 支援的備份粒度：例項。
• 備份物件：日誌檔案，控制檔案，引數檔案，資料檔案。
• 加密情況：傳輸過程支援HTTPS加密，儲存支援AES256，BYOK加密
• 支援的恢復粒度：Oracle單機恢復粒度包括：資料庫例項（全庫恢復）。
• 支援的恢復方式：支援原機異例項，異機原位置的指定任意時間點的恢復。
• RAC 恢復到單機：當 Oracle RAC 環境損壞時，支援將 Oracle RAC 恢復到單機環境中。
• 歸檔日誌刪除策略：基於備份成功次數，支援自動刪除指定時間段內已備份的Oracle 歸檔日誌，避免因歸檔日誌過滿影響資料庫執行。
• 多通道：開啟多通道備份可提高備份效率。使用者可為根據資料檔案和日誌檔案的儲存量以及業務壓力情況分別自定義通道數量，並行讀取傳輸資料，從而充分利用磁碟 I/O。
• 資料庫高階壓縮：開啟資料庫高階壓縮後，可以在備份過程中對備份資料進行壓縮， 節省磁碟空間，提升傳輸效率。
• 無入侵：整個備份恢復過程，對源庫無入侵，不依賴本地磁碟做中轉。
• 它還在持續迭代中，歡迎持續關注。

差異點

為什麼要備份上雲？
DBS Oracle備份是雲技術和備份技術的結合，它不僅實現了傳統的Oracle備份的能力（如上所述），而且在使用DBS雲備份時：

• 天然實現6個9的備份儲存穩定性：備份資料儲存在阿里雲OSS物件儲存上，SLA達到6個9
• 天然實現同地域多機房容災：備份資料按照多機房高可用容災
• 低成本實現異地備份：
• 網路頻寬：阿里雲內部網路更高的頻寬，更低的網路延遲，費用更低，可以實現更低的異地災備RPO
• 恢復機器：相比於傳統的資料備份保護方案，需要提前額外購買恢復用的機器資源。在DBS只需要在恢復時只需要按量付費透過DBS一鍵恢復到RDS，或者是透過DBS沙箱例項秒級拉齊臨時恢復例項即可

雲備份帶來更多

上雲之後，DBS和雲上眾多雲產品深度結合，提供了以下等能力，幫使用者盤活沉寂的備份資料，降低使用者TCO：

• 資料湖分析：相比於傳統備份備份資料只能在恢復時使用而言，DBS與雲上產品DLA（資料湖分析）深度結合，無需恢復則能提供邏輯備份資料的資料湖分析能力；

• 副本資料管理CDM：DBS與DAS、DMS，RDS等資料庫產品深度整合，對 備份資料 提供 CDM(副本資料管理)能力，可以實現對物理備份秒級恢復，可以讓使用者基於備份資料實現devops及分析能力，大大提高資料資產的使用效率，降低TCO。

Oracle副本資料管理（CDM）

傳統的資料恢復時間主要取決於資料的下載時間以及歸檔日誌應用時間。恢復時間通常在小時級別。DBS Oracle 備份利用DBS儲存的快照克隆掛載等技術，以及雲例項的彈性生產能力，可以實現Oracle副本資料管理，讓使用者可以在幾秒鐘之內恢復出一個1TB的Oracle例項，幫助使用者快速實現應急容災，恢復演練，DevOps等需求。

為實現Oracle CDM能力，需要以下的技術能力，如圖4：

全量備份+映象複製：DBS用流式掛載備份的方式，結合RMAN Image Copy備份方式實現byte by byte的資料檔案無入侵複製。在恢復時，透過流式掛載恢復的方式，可以直接用這份備份資料拉起Oracle資料庫，無需再做大量的資料複製。

快照+克隆：DBS備份儲存的快速打快照的能力，幫助使用者打造不同時間點的Oracle備份資料的黃金副本。基於這些黃金副本以及對黃金副本的秒級克隆能力，可以幫助使用者在非常短的時間內（秒級）建立同一個時間點的Oracle沙箱例項，不同沙箱例項之間無干擾，幫助使用者實現DevOps，比如在Oracle沙箱例項上實現業務變更驗證，業務壓測，業務釋出測試等等。

圖4 DBS Oracle副本複製管理

總結

DBS Oracle備份產品是阿里雲自研的，結合阿里集團之前多年Oracle資料庫的生產使用經驗打造的雲備份產品。它不僅提供了傳統備份所提供的Oracle備份能力外，還實現了無入侵流式備份能力，同時和雲以及眾多雲產品深度結合，在備份資料上提供資料湖分析，並透過副本資料管理（CDM）技術提供Oracle秒級恢復及devops能力。現DBS Oracle備份已經上線，歡迎大家來試用：

https://help.aliyun.com/document_detail/149339.html