遷移 SQL Server 數據庫到 Azure SQL 實戰

時間 2019-12-01

原文原文鏈接

最近有個維護的項目須要把 SQL Server 2012 的數據庫遷移到 Azure SQL 上去，遷移過程可謂一波三折，故在此分享此次遷移中碰到的點點滴滴，但願對朋友們有所幫助。html

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) 就能夠了，請注意選擇合適的區域(這會影響訪問速度)。post

容許從本地訪問 Azure SQL Server

Azure SQL Server 建立好之後，咱們經過 SSMS 測試一下鏈接狀況。當咱們輸入了正確的地址和用戶信息後卻彈出了一個提示框：學習

它提示咱們，當前的IP不能訪問 Azure 上的數據庫服務器，而且讓我以 Azure 帳號登陸並建立一條防火牆規則。測試

其實這是 Azure 提供的一個安全措施，它讓你顯式的指定哪些IP地址或者IP網段能夠訪問 Azure SQL Server。ui

此時咱們有兩種解決方法：

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 的帶寬有很大的關係…