最近有個維護的項目需要把 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 後問題消失。
下面進入正題，看看遷移的過程中都需要什麼樣的工具，如何操作以及需要注意的事項。在此特別強調，舊數據庫一般都是處於正在使用的狀態，所以千萬不要在真實的庫上做各種實驗。筆者所有的前期實驗都是在通過恢復備份文件創建的測試庫上完成的。
遷移要點分析
在雲端創建 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。
此時我們有兩種解決方法：
1.點擊對話框中的 ”Sign in”，用 Azure 賬戶登錄；然後點擊 ”OK”，此時已經完成了防火牆規則的設置，SSMS 已登錄 Azure SQL Server。這種方法一般用於開發和測試，只能添加當前客戶端所使用的IP。
2.更加通用的方法是登錄 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提供的工具還算比較完善，網絡上的各種已知問題解決方案也很詳盡。所以儘管筆者碰到了很多的問題，但沒有卡住的地方，總算磕磕絆絆的完成了數據庫遷移的任務。
