摘要
至今為止我們完成了SQL Server備份還原專題系列六篇月報分享：三種常見的資料庫備份、備份政策的制定、查找備份鍊、資料庫的三種恢複模式與備份之間的關系、利用檔案組實作冷熱資料隔離備份方案以及如何監控備份還原進度，本期我們分享阿裡雲是如何基于SQL Server備份還原理論來設計RDS SQL自動化遷移上雲方案的。
适用場景
RDS資料庫遷移上雲是指将使用者線下資料庫搬遷到阿裡雲RDS上并完成應用切換到RDS上的工作過程。資料庫遷移上雲的重點和難點在于：如何保證使用者資料庫的完整性的同時，還要保證使用者應用停機切換時間足夠短（起碼要達到分鐘級）。通常使用的方法有邏輯遷移和實體遷移兩種。
邏輯遷移
邏輯遷移，是指将使用者線下資料庫對象和資料轉化為DDL和DML語句，然後在RDS上執行的遷移上雲方式。這些資料庫的對象包含但不僅限于：
表：資料庫的表對象，是資料庫存儲資料的單元。如果表與表之間有建立主、外鍵關系，在表對象建立之前，必須找出多表之間的主、外鍵關系，先建立主表，再建立外表。
限制：表與表之間的主、外鍵限制；預設限制；唯一限制；Check限制等。
視圖：視圖之間很可能存在引用關系，必須先建立被引用的視圖，然後再建立引用視圖。
函數：函數之間也可能存在互相引用關系。
存儲過程：建立存儲過程不需要嚴格按照引用關系來建立，但很有可能存在跨庫通路的情況。
同義詞：同義詞類似于對象别名，這個是很多人容易忽略的地方。
邏輯遷移這種方式的好處是：應用切換時間很短，可以控制在秒級别。但是缺點也是顯而易見的。
對象建立過程十分複雜，需要首先找出對象間互相依賴關系，才能成功建立所有對象。
表與表主外鍵限制，進而導緻了資料插入操作必須先主表，再外表的順序；資料删除則相反。
将資料轉化為DML語句，然後在RDS上執行的方式，效率低下，尤其是大表的情況。
頻繁的DML操作語句，非常容易導緻RDS上Blocking發生，甚至嚴重時會産生死鎖。
頻繁的DML操作，會導緻資料日志檔案在短時間内暴漲，消耗IOPS資源。
最為嚴重的缺點是，頻繁的DML操作，會導緻表索引碎片率在短時間内大幅增加和統計資訊的過時，進而導緻執行計劃評估不準确，進行影響RDS資料庫的性能。
實體遷移
為了消除邏輯遷移的種種痛點，實體遷移是指，RDS SQL基于使用者的實體備份檔案，直接遷移上雲還原到RDS SQL上。既然RDS SQL上的資料是基于使用者線下資料庫備份檔案（既可以是完全備份檔案，也可以是完全備份檔案 + 差異備份或者日志備份檔案）直接遷移上雲還原到RDS SQL上，那麼，我們就可以100%的保證RDS SQL上的資料庫和使用者線下資料庫是100%一緻的。就不會存在以上邏輯遷移的種種痛點，而最大的有點展現在解決了索引碎片和統計資訊的不一緻，導緻使用者資料庫性能的問題，保證了使用者線下資料庫和RDS SQL資料庫行為時一緻性。
兩者對比
邏輯遷移和實體遷移兩者的優缺點對比如下所示：
從對比的結果來看，實體遷移唯一的弱勢在于應用切換的時間稍長，控制在分鐘級别，但是我相信對于起碼95%以上的企業來講分鐘級别的遷移上雲應用停止的時間還是可以接受的。
方案解析
在前一個章節，我們詳細分析了線下SQL Server資料庫遷移上雲阿裡雲RDS SQL的兩種方式：邏輯遷移和實體遷移，從對比結果來看，實體遷移具有更多的優點并且複雜度可控，是實作自動化遷移上雲的最佳方案。以下兩個小節是基于實體遷移上雲方案的分析和流程圖設計。
方案分析
從整個遷移上雲的過程分析來看，主要牽扯到四個方面的參與者，我們隻需要把這四個參與者之間關系及用途分析清楚，方案就一目了然了。
使用者線下資料庫：使用者在自己線下環境的SQL Server執行個體中的資料庫。使用者需要線上下資料庫中完成準備工作、資料庫備份及備份檔案上傳到OSS。
OSS（阿裡雲對象存儲服務）：暫存使用者的備份檔案，供RDS SQL執行個體下載下傳備份檔案。
RDS控制台：承載着與使用者界面互動的功能，使用者需要通過RDS控制台告訴阿裡雲RDS SQL，将哪一個備份檔案恢複到哪一個執行個體的哪一個資料庫下。
RDS SQL執行個體：從OSS下載下傳使用者的備份檔案，然後還原到RDS執行個體中。
流程圖設計
從“方案分析”中，我們很清楚的了解到遷移上雲方案四方參與者，各司其職，各盡所能，就可以很完美的實作使用者遷移上雲的功能。将整個過程做成流程圖，如下所示：
這個流程圖，很清楚的描繪了四方參與者之間的職責以及他們的資料流走向。
一個案例
參照上面的“方案解析”部分的介紹，我們舉一個特定的案例，來看看阿裡雲RDS SQL自動遷移上雲的案例。
時間軸
首先，從時間次元來看一個典型的上雲案例，參照下圖所示：
橫軸：表示時間，從左往右
數字1 - 9：表示操作步驟先後順序，和時間對應
數字右邊文字：表示操作步驟名稱
數字下方文字：表示操作步驟的較長的描述資訊
案例描述
根據上圖增量上雲案例，按時間次元，解釋如下：
Step1. Before 00:00：完成準備工作，包括完成DBCC CheckDB檢查；關閉本地環境備份系統；修改資料庫為FULL恢複模式；
Step2. 00:01：使用者備份線下資料庫開始FULL Backup；
Step3. 02:00：完成FULL Backup，耗時近1小時，開始上傳備份檔案到OSS Bucket；
Step4. 03:00：完成備份檔案上傳，耗時1小時，開始在RDS控制台恢複FULL Backup檔案；
Step5. 22:00：完成FULL Backup上雲，耗時19小時，開始資料庫Backup LOG；
Step6. 22:20：完成LOG Backup，耗時20分鐘，RDS控制台恢複LOG Backup檔案；
Step7. 22:30：完成LOG Backup上雲，耗時10分鐘，重複步驟5 – 6，不斷Backup LOG、上傳到OSS、增量上雲LOG備份檔案，確定最後一個Backup LOG檔案盡量小（500MB以下），然後停止本地應用對資料庫的寫入操作，最後再做一個LOG Backup，最後一次增量上雲。
Step8. 22:34：完成了最後一個LOG Backup檔案增量上雲操作，耗時4分鐘，開始将資料庫待上線；
Step9. 22:35：資料庫上線完畢，如果選擇異步執行DBCC操作，上線動作很快，耗時1分鐘。
從整個的動作流程和時間軸來看，使用者需要停止應用的時間非常的短，僅僅是在最後一個LOG Backup之前停止應用寫入即可。在本例中整個應用停止的時間控制在5分鐘内。
參考連結
關于SQL Server備份還原理論，我們完成了備份還原專題系列月報六篇，以及基于這些理論設計出了阿裡雲RDS SQL自動化遷移上雲方法。産品介紹參加如下幫助文檔：
全量備份資料上雲SQL Server 2008 R2版：
https://help.aliyun.com/document_detail/64341.html全量備份資料上雲SQL Server 2012及以上版本：
https://help.aliyun.com/document_detail/68310.html增量備份資料上雲SQL Server 2012及以上版本：
https://help.aliyun.com/document_detail/71614.html歡迎大家使用并提出寶貴意見。