使用 Azure 資料庫移轉服務的相關常見問題集

Azure 資料庫移轉服務是一個完全受控的服務，能夠從多個資料庫來源無縫移轉到 Azure 資料平台，將停機時間降到最低。 服務目前已正式發行，後續開發重點放在下列工作：

• 可靠性和效能。
• 反覆新增來源目標組。
• 持續投資無衝突的移轉。

這項服務目前支援各種來源/目標對組或移轉案例。 如需每個可用移轉案例狀態的完整清單，請參閱 Azure 資料庫移轉服務支援的移轉案例狀態一文。

從 SQL Server 移轉時，Azure 資料庫移轉服務的支援來源為 SQL Server 2008 和更新版本。 如果您使用 Azure Data Studio 搭配 SQL 移轉延伸模組，支援的來源為 SQL Server 2008 到 SQL Server 2022。

您可以使用 Azure 資料移轉服務來執行離線和線上移轉。 若使用離線移轉，當移轉開始時，應用程式也會開始停機。 若使用線上移轉，則只會在移轉結束時於完全移轉期間停機。 建議您先測試離線移轉來決定停機時間是否在容忍範圍內；如果無法容忍，則請進行線上移轉。

若要將資料庫大規模移轉至 Microsoft Azure，建議您使用 Azure 資料庫移轉服務這個方法。 如需 Azure 資料庫移轉服務和其他 Microsoft 資料庫移轉工具相較之下孰優孰劣的相關資訊，以及在各種案例中使用這項服務的建議，請參閱區分 Microsoft 的資料庫移轉工具和服務。

Azure Migrate 可協助將內部部署虛擬機器移轉至 Azure IaaS。 此服務會評估移轉適用性，以及如何根據效能來調整大小，並估計在 Azure 中執行內部部署機器的成本。 Azure Migrate 可用來將內部部署的 VM 型工作負載隨即移轉到 Azure IaaS VM。 不過，與 Azure 資料庫移轉服務不同的是，Azure Migrate 並非特製化的資料庫移轉服務供應項目，因此不適用於 Azure PaaS 關聯式資料庫平台 (例如，Azure SQL Database 或 Azure SQL 受控執行個體)。

否。 資料移轉服務不會儲存客戶資料。

針對 Azure SQL VM 和 Azure SQL MI 目標，DMS 會使用實體移轉，也就是使用備份與還原。 如下所述，選擇的移轉模式會決定資料在來源和目標之間保持一致的方式。

• 離線移轉：在離線移轉至 Azure SQL VM 和 Azure SQL MI 目標期間，當移轉開始時應用程式即會開始停機。 只要來源的最新備份檔已傳輸到 SMB 網路儲存體或 Azure Blob 容器，DMS 就會將所有備份檔還原至目標 (依據移轉設定)。 如果使用 CHECKSUM 選項進行備份，DMS 還原作業會自動執行驗證。 如果沒有總和檢查碼，則會在還原之前明確檢查備份的完整性。 這可確保還原檔案與備份檔案相同，因此所含的資料相同。 您可以在 DMS 移轉監視頁面所顯示的目標上套用/還原備份檔案，以驗證所有備份檔案 (包括來源的最後一個備份檔案名稱)，並驗證其各自的總和檢查碼。

• 線上移轉：在線上移轉至 Azure SQL VM 和 Azure SQL MI 目標期間，只要您起始完全移轉並停止應用程式，就會開始停機。 只要來源的最新備份檔已傳輸到 SMB 網路儲存體或 Azure Blob 容器，DMS 就會將所有備份檔還原至目標 (依據移轉設定)。 按下完全移轉按鈕之後，DMS 會顯示在保存在 SMB 網路儲存體或 Azure Blob 容器且尚未在目標套用/還原的待完成備份檔計數 (如果有的話)。 如果使用 CHECKSUM 選項進行備份，DMS 還原作業會自動執行驗證。 如果沒有總和檢查碼，則會在還原之前明確檢查備份的完整性。 這可確保還原檔案與備份檔案相同，因此所含的資料相同。 您可以在 DMS 移轉監視頁面所顯示的目標上套用/還原備份檔案，以驗證所有備份檔案 (包括來源的最後一個備份檔案名稱)，並驗證其各自的總和檢查碼。

針對 Azure SQL DB 目標，DMS 會在使用 Azure SQL DB 的情況下執行邏輯移轉，亦即，從來源 SQL 資料庫的資料表複製資料，然後寫入目標 Azure SQL DB 的資料表。 由於 DMS 僅支援離線移轉至 Azure SQL DB，因此當移轉開始時，應用程式即會開始停機。 您可以從移轉監視頁面監視和驗證讀取 (從來源資料庫資料表) 和複製 (寫入目標 Azure SQL DB 資料表) 的資料列數目。 如需額外確認，您可以執行下列 TSQL，取得來源和目的地資料庫的總和檢查碼，並驗證來源和還原資料是否相同。

  "SELECT CHECKSUM_AGG(CHECKSUM(*)) FROM <table_name>"
  

注意：前提是沒有任何應用程式正在寫入來源或目標資料庫。 您也可以利用資料庫比較工具之類的工具來比較資料。

下列清單包含可在幕後建立以執行資料移轉的 Azure 資源。 使用的服務可能會因移轉案例而有所不同。

• Azure 監視器
• Azure VM
• Azure 儲存體
• Azure 服務匯流排
• Azure Data Factory

在內部，DMS 會維護中繼資料存放區，其中包含網路位置、認證、備份檔案及已完成工作的相關資訊。 認證和選取的欄位 (例如帳戶金鑰) 都會加密。 資料 (例如可能包含在遙測中的資料表名稱) 會進行雜湊處理。 使用者名稱可能會在服務記錄中以純文字顯示，但絕對不會顯示密碼。 遙測資料會按區域區隔、由保留原則控管，且只有 Microsoft 中的授權人員能夠使用，以便進行有效的疑難排解。 Azure 資源名稱 (例如伺服器和資料庫名稱) 遵循 Azure 資源適用的規則。

DMS (傳統) 利用 Azure 服務匯流排主題來簡化計算層之間的通訊。 Azure 服務匯流排主題對每個 DMS 執行個體而言都是唯一的，而且所有個人資料都會經過加密。

Azure 虛擬機器上的 Azure SQL 受控執行個體和 SQL Server

結構描述和資料會使用備份與還原進行移轉。 客戶可以選擇從網路共用或直接從儲存體容器還原。 可能會取用含有 Windows 效能資料的檔案，以提供選擇性 (但強烈建議使用) 工作負載大小調整建議。

Azure SQL Database

移轉至 Azure SQL Database 的程序分成兩個步驟。 第一個步驟是結構描述移轉。 DMS (傳統) 使用 SQL 管理物件 (SMO) 進行結構描述移轉。 第二個步驟是實際資料移轉。 SqlBulkCopy 可用來執行資料移轉。 DMS 不支援結構描述移轉。 資料是使用 Azure Data Factory 進行移轉。 選擇性但強烈建議使用，可以取用含有 Windows 效能資料的檔案，以提供工作負載大小調整建議。

適用於 PostgreSQL 的 Azure 資料庫

在此案例中，使用者會使用 pg_dump 和 pg_restore 命令行公用程式擷取中繼資料，在此情況下為結構描述。 設定 PostgreSQL 的異動數據擷取時，DMS 會在內部使用 pg_dump 和 pg_restore 來執行 CDC 的初始植入。 資料會儲存在只有 DMS 執行個體可以存取的加密暫存儲存體中。 可能會取用含有 Windows 效能資料的檔案，以提供選擇性 (但強烈建議使用) 工作負載大小調整建議。

適用於 MySQL 的 Azure 資料庫

在此案例中，DMS (傳統) 會使用 mysql-net/MySqlConnector 來執行結構描述擷取和移轉。 盡可能使用 MySQL binlog 複寫來複寫資料和結構描述變更。 自訂程式碼可用來同步處理無法使用 binlog 複寫的變更。

MongoDB 至 Azure Cosmos DB

DMS 會從 MongoDB 擷取資料並插入到 Cosmos DB。 且可讓您選擇從 BSON 或 JSON 傾印擷取資料。

針對 BSON 傾印，DMS 會使用 Blob 容器的相同資料夾中格式 bsondump 的資料。 DMS 只會使用格式 collection.metadata.json 尋找中繼資料檔案。

針對 JSON 傾印，DMS 會讀取以包含資料庫命名的 Blob 容器資料夾中的檔案。 在每個資料庫資料夾中，DMS 只會使用放在 data 子資料夾中的資料檔案。 DMS 只會查看放在 metadata 子資料夾並使用格式 collection.json 命名的中繼資料檔案。

Oracle 移轉至 Azure SQL Database

在此案例中，會取用 AWR 報告或 Windows perfmon 檔案來提供選擇性 (但強烈建議使用) 工作負載大小調整建議。 執行移轉的使用者會使用資料庫結構描述轉換工具組來執行結構描述移轉，以準備目標資料庫。

Oracle 移轉至適用於 PostgreSQL 的 Azure 資料庫

與「Oracle 移轉至 Azure SQL Database」很像，在此案例中，會取用 AWR 報告或 Windows perfmon 檔案來提供選擇性 (但強烈建議使用) 工作負載大小調整建議。 執行移轉的使用者會使用 ora2pg 程式庫來擷取結構描述，並手動移轉資料。

DMS (傳統) 依賴客戶網路設定。 如果移轉來源使用私人端點，我們就會使用私人端點，這是慣用設定。 如果公用端點是唯一選項，我們就會使用公用端點。

DMS 會在幕後大量使用 ADF 來排程和協調資料移動。 此外，自我裝載整合執行階段與您可能已經用於自己的 ADF 管線的執行階段並無不同。 如需防火牆和 Proxy 伺服器問題的詳細資訊，請參閱建立及設定自我裝載整合執行階段。

所有待用客戶資料都已加密。 某些中繼資料 (包括但不限於邏輯伺服器名稱和資料庫名稱)，以及移轉狀態和移轉進度會出現在未加密的服務記錄中。

傳輸中的所有資料均預設為使用 TLS 1.2 加密保護。 需要舊版 TLS 的舊版用戶端，需要在 DMS (傳統) 入口網站頁面啟用的必要版本。 針對 DMS，安裝自我裝載整合執行階段的電腦可設定為允許必要的 TLS 設定，以容納舊版用戶端。 若要進一步了解 SQL Server 的 TLS 設定，請參閱 KB3135244 - Microsoft SQL Server 的 TLS 1.2 支援。

請盡可能使用私人端點。 如果無法選擇私人端點，則服務層之間的通訊會使用公用端點。 不論端點類型為何，所有資源都會專用/範圍限定於特定 DMS 執行個體，並使用唯一認證加以保護。

我們不支援在資料平面或控制平面中使用客戶自控金鑰來加密資料。 不過，所有待用客戶資料都會使用服務管理的金鑰加密。 某些中繼資料 (包括但不限於邏輯伺服器名稱和資料庫名稱)，以及移轉狀態和進度會以未加密的形式出現在服務記錄中。

傳輸中的所有資料均預設為使用 TLS 1.2 加密。 DMS (傳統) 入口網站頁面允許舊版用戶端使用舊版 TLS。 針對 DMS，安裝自我裝載整合執行階段的電腦可設定為允許管理 TLS 設定，以容納舊版用戶端。 若要進一步了解 SQL Server 的 TLS 設定，請參閱 KB3135244 - Microsoft SQL Server 的 TLS 1.2 支援。

我們不會公開在控制或資料平面上使用客戶自控金鑰來加密資料的功能。 一旦刪除 DMS 執行個體，所有客戶資料均會立即刪除，但服務記錄除外。 DMS 服務記錄只會保留 30 天。

TDE

DMS 支援將客戶自控金鑰 (CMK) 移轉至 Azure SQL，以進行透明資料庫加密 (TDE)。 如需移轉 TDE 金鑰的逐步指示，請參閱教學課程：在 Azure Data Studio 中將已啟用 TDE 的資料庫 (預覽) 移轉至 Azure SQL。

儲存格加密

儲存格層級加密是在結構描述層級進行處理。 結構描述移轉工具會移轉所有結構描述物件，包括實作儲存格層級加密所需的函式和預存程序。

Always Encrypted

DMS 目前不支援透過在來源和目標之間移轉個別資料列的方式來執行 Always Encrypted 移轉。 若是使用備份/還原，則透過 Always Encrypted 加密的資料行會如預期般移轉，例如從現有的 SQL Server 執行個體移至 Azure SQL VM 或 Azure SQL 受控執行個體。

我們不會在 Azure 已經提供的範圍外，實作任何位置感知存取控制。 與 DMS 執行個體相關聯的所有資料都位於與 DMS 資源相同的區域中。

我們的服務可用於具有不同內部控制和商務程序的各種環境。 DMS 可在使用帳戶有權存取的位置移入和移出資料。 使用者有責任了解其工作環境的權限和內部控制。 尤其重要的是，請確保 DMS 用來連接來源的帳戶具有存取權，可以查看要從來源移轉的所有資料。

VNET 插入是將位於 Microsoft 租用戶內的 Azure 資源新增至客戶租用戶下 VNet 子網路的動作。 搭配 DMS 採用此方法，可讓我們代表客戶來管理計算，同時仍可維護客戶資源的存取權。 由於網路位於客戶訂用帳戶中，Microsoft 除了發出啟動、停止、刪除或部署命令外，無法管理 VM。 所有需要存取 VM 的其他管理動作都需要客戶起始的支援要求和核准。

您必須注意數個必要條件，以確保在執行資料庫移轉時，Azure 資料庫移轉服務能順利執行。 某些必要條件會套用到服務所支援的所有案例 (來源目標組)，而有些必要條件則是特定案例獨有的。

Azure 資料庫移轉服務在所有支援的移轉案例中的必要條件都是一樣的，包括以下需求：

• 使用 Azure Resource Manager 部署模型建立適用於 Azure 資料庫移轉服務的 Microsoft Azure 虛擬網路，此模型會使用 ExpressRoute 或 VPN 提供內部部署來源伺服器的站對站連線。
• 請確定您虛擬網路的網路安全性群組規則不會封鎖服務匯流排、儲存體和 Azure 監視器服務標籤的連接埠 443。 如需虛擬網路 NSG 流量篩選的詳細資訊，請參閱＜使用網路安全性群組來篩選網路流量＞(機器翻譯) 一文。
• 使用來源資料庫前面的防火牆設備時，您可能必須新增防火牆規則，才能讓 Azure 資料庫移轉服務存取來源資料庫，以進行移轉。

如需使用 Azure 資料庫移轉服務完成特定移轉案例所需的所有必要條件清單，請參閱 Azure 資料庫移轉服務文件中的相關教學課程。

請新增防火牆規則，允許 Azure 資料庫移轉服務存取移轉來源資料庫。 服務的 IP 位址是動態的，但如果您使用的是 ExpressRoute，則會由公司網路私下指派此位址。 若要識別適當的 IP 位址，最簡單的方式是查看和所佈建 Azure 資料庫移轉服務資源相同的資源群組，以尋找相關聯的網路介面。 網路介面資源的名稱通常會以 NIC 前置詞作為開頭，後面接著獨特字元和數字序列，例如 NIC-jj6tnztnmarpsskr82rbndyp。 藉由選取此網路介面資源，您即可在 Azure 入口網站的 [資源概觀] 頁面上，看到必須包含在允許清單中的 IP 位址。

此外，您可能還需要在允許清單上包含 SQL Server 所接聽的連接埠來源。 根據預設，來源是連接埠 1433，但您也可以將來源 SQL Server 設定為接聽其他連接埠。 在此情況下，您也必須在允許清單上包含這些連接埠。 您可以使用動態管理檢視查詢來判斷 SQL Server 所接聽的連接埠：

SELECT DISTINCT
    local_tcp_port
FROM sys.dm_exec_connections
WHERE local_tcp_port IS NOT NULL;

您也可以藉由查詢 SQL Server 錯誤記錄來判斷 SQL Server 所接聽的連接埠：

USE master;
GO
xp_readerrorlog 0, 1, N'Server is listening on';
GO

有多個 Microsoft 教學課程可逐步引導您完成虛擬網路的設定程序，至於官方文件，則會在 Azure 虛擬網路一文中出現。

在典型的簡單資料庫移轉期間，您必須：

1. 建立目標資料庫。
2. 評估您的來源資料庫。
   • 若要進行同質移轉，請使用 DMA 評估現有的資料庫。
   • 若要進行異質移轉 (從競爭來源)，請使用 SSMA 評估現有的資料庫。 您也可以使用 SSMA 來轉換資料庫物件，並將結構描述移轉至目標平台。
3. 建立 Azure 資料庫移轉服務的執行個體。
4. 建立移轉專案，以指定用於移轉的來源資料庫、目標資料庫和資料表。
5. 啟動完整載入。
6. 挑選後續驗證。
7. 將生產環境手動轉換至新的雲端型資料庫。

如果您在進行移轉時無法連線到來源資料庫系統，請在用於設定 DMS 執行個體的虛擬網路的同一個子網路中建立一台虛擬機器。 在虛擬機器中，您應該可以執行連線測試，例如使用 UDL 檔案來測試與 SQL Server 的連線，或下載 Robo 3T 以測試 MongoDB 連線。 如果連線測試成功，您就應該不會有連線到來源資料庫的問題。 如果連線測試失敗，請連絡您的網路管理員。

如果使用者明確地停止 Azure 資料庫移轉服務 (DMS) 或服務未使用達 24 小時，則服務會處於停止或自動暫停的狀態。 在每個情況下，服務都會無法使用並處於停止狀態。 若要繼續使用中的移轉，請重新啟動服務。

若要提升使用服務來移轉資料庫的速度，您可以執行幾項工作：

若為 DMS (傳統)：

• 在建立服務執行個體時，請使用多重 CPU 一般用途定價層，以讓服務充分利用多個 vCPU 來進行平行處理，提升資料傳輸速度。
• 在資料移轉作業期間，暫時將 Azure SQL Database 目標執行個體擴大為進階層 SKU，讓使用較低層級 SKU 時可能會影響資料轉送活動的 Azure SQL Database 節流減到最少。

若為 DMS：

• 如果您要將備份從本機檔案共用複製到 Azure Blob 儲存體，或執行移轉至目標 Azure SQL DB 時，DMS 會使用 SHIR 節點作為其計算節點。 因此，請務必監視該 SHIR 節點的資源使用量。
• 在資料移轉作業期間，暫時將 Azure SQL Database 目標執行個體擴大為進階層 SKU，讓使用較低層級 SKU 時可能會影響資料轉送活動的 Azure SQL Database 磁碟節流減到最少。
• 如需詳細資訊，請參閱部落格。

下一步

• 什麼是 Azure 資料庫移轉服務。