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
歡迎大家加入DBS釘釘群
直播預告
11月18日 14:00-15:00
邀您一起見證
雲原生數據庫備份DBS新版本發佈
掃描下圖二維碼
預約觀看直播發佈會