使用連結進行遷移 - Azure SQL 托管執行個體

本文將教導你如何透過受控執行個體連結，將你的SQL Server資料庫遷移到 Azure SQL 受控執行個體。

如需詳細遷移指南，請參考 Migrate to Azure SQL 受控執行個體。要比較遷移工具，請參考比較 LRS 與受控執行個體連結。

注意

你現在可以直接透過 Azure 入口網站，將由 Azure Arc 啟用的 SQL Server 實例遷移到 Azure SQL 受控執行個體。欲了解更多資訊，請參閱遷移至 Azure SQL 受控執行個體。

概觀

受控執行個體連結使得可以將託管於任何位置的 SQL Server 遷移到 Azure SQL 受控執行個體。該連結使用 Always On 可用性群組技術，幾乎即時地從主要 SQL Server 實例複製到次要 SQL 受管理執行個體的變更。這個連結提供 SQL Server 與 Azure SQL 受控執行個體之間唯一真正線上的遷移選項，因為唯一的停機時間是切換到目標 SQL 管理實例。

使用連結進行移轉可提供您：

在完成遷移到 Azure 之前，能在 SQL 受管理執行個體上測試唯讀工作負載的能力。
您可視需要保持連結並持續執行移轉，一次執行數週甚至數月。
近乎即時的資料複製，提供最快的 Azure 資料複製。
相較於現今所有其他可用解決方案，停機時間最短的移轉。
即刻切換至目標 SQL 托管執行個體。
您可隨時移轉。
能夠將單一或多個資料庫從單一或多個 SQL Server 實例遷移到同一個或多個 SQL 管理實例的 Azure。
唯一真正線上移轉至業務關鍵服務層級。

注意

雖然每個連結只能遷移一個資料庫，但你可以從同一個 SQL Server 實例建立多條連結到同一個 SQL 受管理執行個體。

切換行為

切換行為取決於你遷移的 SQL Server 版本以及目標 SQL 受管理執行個體的更新政策：

從 SQL Server 2016 轉到 SQL Server 2019，切換到 SQL 受管理執行個體會丟棄連結。
對於 SQL Server 2022 或更新版本，切換到 SQL 受管理執行個體時，可以在故障轉移時根據你的選擇，選擇移除連結或保留連結。如果你選擇保留連結，且你的 SQL 管理實例有匹配的更新策略，必要時可以反向遷移回 SQL Server。

遷移時，建議移除連結。如果你選擇保留連結，但之後又決定移除，請等 Azure 在故障轉移後完成資料庫的第一次完整備份後再移除連結。此步驟確保資料庫在 SQL 受管理執行個體上保持健康且完全正常運作。這也有助於避免一個罕見的已知問題：如果連結過早移除，伺服器重啟後資料庫可能暫時無法使用。如需詳細資訊，請參閱 MI 連結容錯移轉後，資料庫會在伺服器重新啟動後變得無法使用。

逆轉遷移

根據你的 SQL 管理實例的更新政策，可能支援將 Azure SQL 受控執行個體反向遷移回 SQL Server。例如：

SQL Server 2022 更新政策：設定為 SQL Server 2022 更新政策的實例資料庫可回復至 2022 SQL Server實例。
SQL Server 2025 更新政策：設定為 SQL Server 2025 更新政策的實例資料庫可回復至 2025 SQL Server實例。
Always-up-to-date 更新政策：設定為 Always-up-to-date 更新政策的實例資料庫無法回復為 SQL Server。

如果你的原始 SQL Server 版本早於 SQL Server 2022，則無法進行反向遷移。當你將資料庫遷移到 SQL 受管理執行個體時，它會進行內部升級，升級到與早期 SQL Server 版本不相容的新資料庫版本。只有在 SQL 受管理執行個體設定對應更新政策時，反向遷移資料庫相容性才可用。

必要條件

要使用連結進行 Azure SQL 受控執行個體的遷移，你需要以下先決條件：

一個有效的 Azure 訂閱。如果您沒有訂用帳戶，請建立免費帳戶。
已安裝所需服務更新的支援版本 SQL Server。

評估與發現

在確認您的來源環境受到支援之後，請從移轉前階段開始。探索所有現有的資料來源、評定移轉可行性，並找出可能會妨礙您移轉的任何封鎖問題。在發現階段，掃描網路以識別組織所使用的所有 SQL Server 實例與功能。

您可以使用下列工具來探索環境的 SQL 來源：

SQL Server 由 Azure Arc 啟用：Azure Arc 啟用的SQL Server自動產生遷移到Azure的評估，簡化遷移的發現過程與準備度評估。
Azure Migrate 用以評估本地伺服器的遷移適用性，執行基於效能的規模，並提供Azure運行成本估算。
Microsoft 評估與規劃工具包（「MAP 工具包」）用來評估您現有的 IT 基礎設施。此工具組提供功能強大的詳細目錄、評量和報告工具，以簡化移轉規劃程序。

在發現資料來源後，評估任何可遷移至 Azure SQL 受控執行個體的本地 SQL Server 實例，以找出遷移阻擋或相容性問題。

你可以使用遷移準備度評估來評估你的來源SQL Server實例。

如需詳細指引，請檢閱移轉前。

建立目標執行個體

在評估完現有環境，並確定目標 SQL 管理實例所需的服務層級與硬體配置後，使用 Azure portal、PowerShell 或 Azure CLI 部署目標實例。

設定連結

在建立目標 SQL 管理實例後，設定 SQL Server 實例的資料庫與 Azure SQL 受控執行個體之間的連結。首先，準備你的環境，然後使用 SQL Server Management Studio （SSMS）或 scripts 來設定連結。

檢查複製延遲

重要的是，次要副本在執行計畫遷移故障轉移前，先追上主副本。如果次要副本遠遠落後於主副本，計劃故障轉移可能會逾時並失敗。

請在 SQL Server 和 SQL 受管理執行個體上使用以下 T-SQL 查詢，來監控副本間的複寫延遲：

-- Execute on SQL Server and SQL Managed Instance 
USE master
DECLARE @link_name varchar(max) = '<DAGname>'
SELECT
   ag.name [Link name], 
   ars1.role_desc [Link role],
   ars2.connected_state_desc [Link connected state],
   ars2.synchronization_health_desc [Link sync health],
   drs.secondary_lag_seconds [Link replication latency (seconds)]
FROM
   sys.availability_groups ag 
   JOIN sys.dm_hadr_availability_replica_states ars1
   ON ag.group_id = ars1.group_id
   JOIN sys.dm_hadr_availability_replica_states ars2
   ON ag.group_id = ars2.group_id
   JOIN sys.dm_hadr_database_replica_states drs
   ON ars2.replica_id = drs.replica_id
WHERE 
   ag.is_distributed = 1 AND ag.name = @link_name AND ars1.is_local = 1 AND ars2.is_local = 0
GO

如果複寫延遲很高，請等待次要副本追上主副本。如果延遲持續，您可能需要執行額外的故障排除步驟，例如暫停主副本的工作負載、改善兩個實例間的連結網路吞吐量，或增加次要副本的資源容量。停止 SQL Server 主要副本工作負載最簡單的方法是切斷與實例的應用程式連線。

移轉多個資料庫

如果你打算從同一伺服器上的多個實例遷移多個資料庫，為了最佳效能和可預測性，建議每個實例一次遷移 8 個資料庫。舉例來說，如果你有 10 個實例，每個實例連結 32 個資料庫，利用計畫性故障轉移，一次從每個實例遷移 8 個資料庫，並重複這個過程直到所有資料庫都遷移完畢。

資料同步和切換

在建立連結並準備好移轉之後，請遵循下列步驟 (通常是在維護時段)：

停止主要 SQL Server 資料庫的工作負載，讓 SQL 受管理執行個體上的次要資料庫能跟上。停止 SQL Server 主要副本工作負載最簡單的方法是切斷與實例的應用程式連線。
驗證所有資料已傳送到 SQL 受管理執行個體的次級資料庫。檢查複製延遲，確保次要副本跟上主要副本。
選擇 [計劃性容錯移轉] 來容錯移轉連結次要 SQL 受控執行個體。
（可選）在 成功切換後 勾選「移除連結」的選項，以確保故障轉移是單向的，連結就會被移除。
（可選）如果你使用的是支援的 SQL Server 版本，且有相符的 SQL 受管理執行個體 update 政策，切換後你可以保留連結，必要時還能逆轉遷移。請查看反向遷移部分以了解具體版本細節。
切換應用程式以連接到 SQL 受控執行個體端點。
（可選）如果您在故障轉移時沒有選擇移除連結，您可以在轉換後不再需要時移除該連結。

驗證移轉

在完全移轉至 SQL 受控執行個體目標之後，請監視您的應用程式、測試效能並補救任何問題。

如需詳細資料，請檢閱移轉後。

已知的遷移問題

請參考連結，檢視以下與遷移相關的已知問題。

MI 連結容錯移轉後，伺服器重新啟動後資料庫會變得無法使用。

在極少數情況下，連結切換後伺服器重啟後，您的資料庫可能會暫時無法使用SQL 受管理執行個體。當您在初次容錯移轉至 SQL 受管理執行個體之後，Azure 尚未完成資料庫的完整備份之前就卸除連結時，就會發生這個已知問題。

在 Microsoft 介入後，資料庫會自動恢復，但這個恢復過程可能需要一些時間。

為了避免這個問題，在從 SQL Server 容錯移轉到 SQL 受控執行個體之後，請勿移除連結，直到第一次完整備份完成為止。欲了解更多資訊，請參閱伺服器重啟後資料庫不可用。

遷移到 SQL 管理實例後發生還原操作失敗

如果你將資料庫從 SQL Server 2019 及以後版本遷移到 Azure SQL 管理實例，並啟用加速資料庫復原，但將持久版本儲存（PVS）設定為非檔案 PRIMARY 群組，目標 SQL 管理實例可能會遇到還原操作失敗。

為了解決這個問題，請在遷移到 SQL 管理實例之前，先將來源 SQL Server 資料庫的持久版本儲存（PVS）設為 PRIMARY 。如果你已經遷移資料庫但沒有將 PVS 設為 PRIMARY，你可以先在來源 SQL Server 資料庫中設定，然後再重新遷移到 SQL 管理實例。

遷移到 SQL 受管理執行個體後無法使用 accelerated database recovery（加速資料庫復原）

從 SQL Server 2019 開始，如果你將資料庫遷移到 Azure SQL 管理實例，且來源資料庫已關閉加速資料庫復原，你就無法在目標 SQL 管理實例上使用加速資料庫復原。

為了解決這個問題，請在遷移到 SQL 受管實例之前，先在來源 SQL Server 資料庫啟用加速資料庫復原。如果你已經遷移資料庫但沒有啟用加速資料庫復原，可以在來源 SQL Server 資料庫啟用，然後再將資料庫遷移到 SQL 管理實例。

SQL Server 2017 及更早版本不支援加速資料庫復原，因此這個問題不適用於從這些版本遷移過來的資料庫。

遷移到 SQL 受管理執行個體後無法使用 Service Broker

如果你將資料庫遷移到 Azure SQL 管理實例，且來源資料庫的 Service Broker 被停用，你就無法在目標 SQL 管理實例上使用 Service Broker。

為了解決這個問題，請在遷移到 SQL 受管理執行個體之前，先在來源 SQL Server 資料庫啟用 Service Broker。如果你已經遷移資料庫但沒有啟用 Service Broker，可以在來源 SQL Server 資料庫啟用，然後再將資料庫重新遷移到 SQL 受管理執行個體。

若要使用連結：

若要深入了解連結：

針對其他複寫和遷移情境，請考慮：

意見反應

此頁面對您有幫助嗎？

Last updated on 2026-06-30