最近有個維護的專案需要把 SQL Server 2012 的資料庫遷移到 Azure SQL 上去。主要是因為租用的主機到期，而運營商停止了主機租賃業務，看來向雲端的遷移是大勢所趨啊！經過一番折騰最終成功遷移，但過程可謂是一波三折。故在此分享這次遷移中碰到的點點滴滴，希望對朋友們有所幫助。
Azure SQL 的版本
Azure SQL Database 是微軟提供的 SQL 服務(PaaS)。最新的版本叫 Azure SQL Database V12，其實微軟還是透過 SQL Server 2014 提供的資料庫服務：
上圖中第一個資料庫伺服器是本地安裝的 SQL Server 2014，第二個和第三個則是雲上的 Azure SQL Database。可以很清楚的看到，它們的版本是一樣的。
但是可不要以為 Azure SQL Database 提供的資料庫和本地安裝版本是一樣的噢。它們還是有不少差別的，這一點在遷移現有資料庫時尤為重要。
由於提供的是線上的服務，所以 Azure SQL Database 可以快速的釋出新特性，這些從不斷更新的 MSDN 文件可見一斑。MS 也強烈建議我們在和 Azure SQL Database 打交道時一定要用最新版的工具。筆者在剛開始使用了 SQL Server 2014 中的 SSMS (SQL Server Management Studio) ，結果連線 Azure SQL 後發現顯示的資訊和 Azure portal 對不上，安裝最新版的 SSMS 後問題消失。
下面進入正題，讓我們把一個8G大小的陳年老庫一步步的遷移到雲上。看這過程中都需要什麼樣的工具，如何操作以及需要注意的事項。在此特別強調，舊資料庫一般都是處於正在使用的狀態，所以千萬不要在真實的庫上做各種實驗。筆者所有的前期實驗都是在透過恢復備份檔案建立的測試庫上完成的。
遷移要點分析
在雲端建立Azure SQL Server
Azure SQL Database 是執行在 Azure SQL Server 中的，所以我們要在 Azure 上先把 Azure SQL Server 建立好。操作比較簡單，直接在 Azure 上新增 SQL Server (logical server) 就可以了，請注意選擇合適的區域(主要影響訪問速度)。
允許從本地訪問 Azure SQL Server
Azure SQL Server 建立好以後，我們透過 SSMS 測試一下能不能連上。當我們輸入了正確的地址和使用者資訊後卻彈出了一個提示框：
它提示我們當前的 IP 不能訪問 Azure上的資料庫伺服器，並且讓我以 Azure 賬號登入並建立一條防火牆規則。
其實這是 Azure 提供的一個安全措施，它讓你顯式的指定都哪些IP地址或者IP網段可以訪問 Azure SQL Server。此時我們有兩種做法。
- 點選對話方塊中的 "Sign in"，用Azure賬戶登入。然後點選 "OK"，此時已經完成了防火牆規則的設定，SSMS 已登入 Azure SQL Server。這種方法一般用於開發和測試，只能新增當前客戶端所使用的 IP。
- 更加通用的方法是登入 Azure portal，進入 Azure SQL Server 的配置介面，為防火牆新增規則。同樣的，可以新增單個 IP 也可以一次新增一個網段：
相容性處理
由於 MS SQL Server 版本眾多，且雲上的版本與本地版本也有差異。所以能不能遷移成功主要看能不能找到並解決資料庫之間的相容性問題。
下面將詳細的介紹筆者碰到的相容性問題。
相容性處理詳情
資料庫中設定的使用者不存在
相容性檢查的報告顯示下面的資訊：
Error SQL71564: Error validating element [xxxx]: The element [xxxx] has been orphaned from its login and cannot be deployed.
其中的 xxxx 是資料庫中設定的使用者名稱。
這個錯誤的原因是使用者被定義在本地的 SQL Server 中，資料庫中只有使用使用者的資訊，把資料庫遷移到雲上後，就找不到對應使用者的定義了。所以需要移除本地使用者的資訊。不用擔心資料庫的訪問問題，因為完成遷移後你可以使用剛才建立的 Azure SQL Server 賬號訪問資料庫。當然你還可以為一個資料庫建立獨立的訪問賬號，具體操作請參考 MSDN。
不支援Extended Property
相容性檢查的報告顯示下面的資訊：
One or more unsupported elements were found in the schema used as part of a data package. Error SQL71564: The element Extended Property: [dbo].[xxxx].[MS_Description] is not supported when used as part of a data package (.bacpac file).
其中的 xxxx 是資料庫中一張表的名稱。
這下可要了命了，不支援 Extended Property！在筆者的資料庫中有好幾處都用到了這個特性。怎麼辦？只好一遍又一遍的檢視程式。最後發現程式中沒有使用這個特性，好像當時只是有人用它做了一些說明。最終的結論是可以移除。
建立 clustered index
相容性檢查的報告顯示下面的資訊：
One or more unsupported elements were found in the schema used as part of a data package. Error SQL71564: Table Table: [dbo].[xxxx] does not have a clustered index.
Clustered indexes are required for inserting data in this version of SQL Server.
其中的 xxxx 是資料庫中一張表的名稱。
需要給表建立 clustered index，看似不是一件小事情。因為任何對錶的修改都可能會影響到程式邏輯，怎麼辦呢？網上的朋友們早就有了比較靠譜的解決方案，就是給表新增一列用來做 clustered index，這樣原來表中的列就沒有發生變化：
ALTER TABLE [xxxx] ADD RowId int NOT NULL IDENTITY (1, 1) PRIMARY KEY CLUSTERED GO
其他
還有一些點，主要是和業務相關的，就不在此贅述。個人感覺絕大多數的問題在網上都有不同的解決方案，關鍵是要採用自己的業務能夠接受的方式去解決問題。
接下來把所有對資料庫的變更寫成一個指令碼檔案。在正式的遷移中，直接在正式庫上執行指令碼檔案。
遷移過程
MS 提供了不同的工具進行相容性檢查、遷移等工作。我們這裡統統使用 SSMS (SQL Server Management Studio) 。下面看看具體的操作步驟。
在 SSMS 中右鍵需要遷移的資料庫，選擇 Tasks 中的"Deploy Database to Microsoft Azure SQL Database…"。
在開啟的嚮導中點選 "next" 進入"Deployment Settings"介面。
首先需要設定 Azure SQL Server 的連線地址和連線賬號：
接下來設定遷移後的資料庫名稱和資源配置：
注意 Azure SQL Database settings，MS 把資料庫使用的資源劃分成了三個不同的類別：Basic, Standard, Premium。每個類別中又劃分了不同的收費標準，簡單說就是你要使用更多更好的資源就要掏更多的錢。當然也可以反過來說，如果我用的資源不多花一點點錢就夠了！
我們發現上圖中的最後一行要求我們為 *.bacpac 檔案指定一個儲存路徑。*.bacpac 檔案是遷移過程中生成的中間檔案，當相容性檢查透過後，就把資料庫中的所有內容都匯出到這個檔案中。從這個資訊我們可以得知，無論採用何種遷移方式，其核心操作都是兩步：先從本地資料庫生成 *.bacpac 檔案，再從*.bacpac 檔案恢復一個Azure SQL Database。
單擊 "Next" 顯示配置的詳情，再下一步就開始相容性檢查。如果沒有相容性問題，就執行遷移操作。
我的資料庫存在一些相容性問題，所以顯示了錯誤報告並終止了遷移操作：
點選 "Result" 列中的連結就能看到詳細的報告，前面已經介紹過相容性問題，直接執行我們處理相容性問題的指令碼檔案，然後再試一次！
這次的執行已經沒有錯誤提示了，其實後臺已經開始了遷移過程。比較不爽的是這個過程沒有詳細的進度提示，只能黑等。我的經驗資料是8G的庫完成遷移大概是 8-12小時。當然這和你連線 Azure 的頻寬有很大的關係…
總結
由於整個遷移過程涉及的方方面面實在太多，本文只是概要式的介紹筆者認為遷移過程中的要點和自己碰到的問題。總的感覺是 MS 提供的工具還算比較完善，網路上的各種已知問題解決方案也很詳盡。所以儘管筆者碰到了很多的問題，但沒有卡殼的地方，總算磕磕絆絆的完成了資料庫遷移的任務。