將 Azure SQL Database 從以 DTU 為基礎的模型移轉到以虛擬核心為基礎的模型

適用於：Azure SQL 資料庫

本文說明如何將 Azure SQL Database 中的資料庫從以 DTU 為基礎的購買模型移轉到以虛擬核心為基礎的購買模型。

移轉資料庫

將資料庫從以 DTU 為基礎的購買模型移轉到以虛擬核心為基礎的購買模型，類似於在基本、標準和進階服務層級中的服務目標之間進行調整，而且在移轉程序結束時，會有類似的持續時間和最短停機時間。 移轉到以虛擬核心為基礎之購買模型的資料庫，可使用同樣的步驟隨時移轉回以 DTU 為基礎的購買模型，但移轉到超大規模資料庫服務層級的資料庫則除外。

您可使用 Azure 入口網站、PowerShell、Azure CLI 和 Transact-SQL，將資料庫移轉至不同的購買模型。

$parameters = @{
     ResourceGroupName = "<resource group name>"
     DatabaseName = "<database name>"
     ServerName = "<server name>"
     Edition = "<service tier, such as Hyperscale>"
     RequestedServiceObjectiveName = "<hardware such as HS_Gen5_2>"
}

Set-AzSqlDatabase @parameters

az sql db update --resource-group "<resource group name>" --server "<server name>" --name "<database name>" --edition <service tier, such as Hyperscale> --capacity 4 --family Gen5

ALTER DATABASE <database name> MODIFY (EDITION = '<service tier, such as Hyperscale>');

選擇虛擬核心服務層級和服務目標

無論是 DTU 或虛擬核心的移轉案例，基本和標準服務層級的資料庫和彈性集區多半都會對應至一般用途服務層級。 進階服務層級的資料庫和彈性集區會對應至業務關鍵服務層級。 視應用程式案例和需求而定，超大規模資料庫服務層級通常可作為所有 DTU 服務層級中資料庫和彈性集區的移轉目標。

若要為虛擬核心模型中已移轉的資料庫選擇服務目標或計算大小，您可以使用近似的基本經驗法則：在基本或標準層，每 100 個 DTU至少需要 1 個虛擬核心，而在進階層，每 125 個 DTU 至少需要 1 個虛擬核心。

在 DTU 模型，系統可能會為資料庫或彈性集區選取任何可用的硬體設定。 此外，在 DTU 模型中，您只能透過選擇較高或較低的 DTU 或 eDTU 值，來間接控制虛擬核心 (邏輯 CPU) 數目。

在虛擬核心模型中，客戶必須明確地選擇硬體設定和虛擬核心 (邏輯 CPU) 數目。 雖然 DTU 模型不提供這些選項，但每個資料庫和彈性集區所使用的硬體類型和邏輯 CPU 數目都會透過動態管理檢視公開。 這讓您能夠更精確地判斷相符的虛擬核心服務目標。

下列方法會使用這項資訊來判斷具有類似資源配置的虛擬核心服務目標，以在移轉到虛擬核心模型之後取得類似等級的效能。

DTU 與虛擬核心的對應

下列 Transact-SQL 查詢在要移轉的 DTU 資料庫內容執行時，會傳回虛擬核心模型每個硬體設定中相符的虛擬核心數目 (可能為分數)。 您可以將此數字四捨五入到最接近虛擬核心模型每個硬體設定中資料庫和彈性集區可用的虛擬核心數目，客戶可以選擇最符合其 DTU 資料庫或彈性集區的虛擬核心服務目標。

範例一節將說明使用這種方法的範例移轉案例。

請在要移轉的資料庫內容中執行此查詢，而不是在 master 資料庫中執行。 移轉彈性集區時，請在集區的任何資料庫內容中執行查詢。

;WITH dtu_vcore_map
AS (
    SELECT rg.slo_name,
        CAST(DATABASEPROPERTYEX(DB_NAME(), 'Edition') AS NVARCHAR(40)) COLLATE DATABASE_DEFAULT AS dtu_service_tier,
        CASE 
            WHEN slo.slo_name LIKE '%SQLG4%' THEN 'Gen4' --Gen4 is retired.
            WHEN slo.slo_name LIKE '%SQLGZ%' THEN 'Gen4' --Gen4 is retired.
            WHEN slo.slo_name LIKE '%SQLG5%' THEN 'standard_series'
            WHEN slo.slo_name LIKE '%SQLG6%' THEN 'standard_series'
            WHEN slo.slo_name LIKE '%SQLG7%' THEN 'standard_series'
            WHEN slo.slo_name LIKE '%GPGEN8%' THEN 'standard_series'
            END COLLATE DATABASE_DEFAULT AS dtu_hardware_gen,
        s.scheduler_count * CAST(rg.instance_cap_cpu / 100. AS DECIMAL(3, 2)) AS dtu_logical_cpus,
        CAST((jo.process_memory_limit_mb / s.scheduler_count) / 1024. AS DECIMAL(4, 2)) AS dtu_memory_per_core_gb
    FROM sys.dm_user_db_resource_governance AS rg
    CROSS JOIN (
        SELECT COUNT(1) AS scheduler_count
        FROM sys.dm_os_schedulers
        WHERE status COLLATE DATABASE_DEFAULT = 'VISIBLE ONLINE'
        ) AS s
    CROSS JOIN sys.dm_os_job_object AS jo
    CROSS APPLY (SELECT UPPER(rg.slo_name) COLLATE DATABASE_DEFAULT AS slo_name) slo
    WHERE rg.dtu_limit > 0
        AND DB_NAME() COLLATE DATABASE_DEFAULT <> 'master'
        AND rg.database_id = DB_ID()
)
SELECT dtu_logical_cpus,
    dtu_memory_per_core_gb,
    dtu_service_tier,
    CASE 
        WHEN dtu_service_tier = 'Basic' THEN 'General Purpose'
        WHEN dtu_service_tier = 'Standard' THEN 'General Purpose or Hyperscale'
        WHEN dtu_service_tier = 'Premium' THEN 'Business Critical or Hyperscale'
        END AS vcore_service_tier,
    CASE 
        WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus * 1.7
        WHEN dtu_hardware_gen = 'standard_series' THEN dtu_logical_cpus
        END AS standard_series_vcores,
    5.05 AS standard_series_memory_per_core_gb,
    CASE 
        WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus
        WHEN dtu_hardware_gen = 'standard_series' THEN dtu_logical_cpus * 0.8
        END AS Fsv2_vcores,
    1.89 AS Fsv2_memory_per_core_gb,
    CASE 
        WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus * 1.4
        WHEN dtu_hardware_gen = 'standard_series' THEN dtu_logical_cpus * 0.9
        END AS M_vcores,
    29.4 AS M_memory_per_core_gb
FROM dtu_vcore_map;

其他因素

除了虛擬核心 (邏輯 CPU) 數目和硬體類型之外，還有其他數個因素可能影響虛擬核心服務目標的選擇：

• 對應的 Transact-SQL 查詢會比對 DTU 與虛擬核心服務目標的 CPU 容量，因此結果對於 CPU 密集型工作負載會更精確。

• 如有相同的硬體類型和相同的虛擬核心數目，虛擬核心資料庫的 IOPS 和交易記錄輸送量資源限制通常會高於 DTU 資料庫。 對於 IO 密集型工作負載，若要達到相同等級的效能，可降低虛擬核心模型中的虛擬核心數目。 DTU 和虛擬核心資料庫的實際資源限制會在 sys.dm_user_db_resource_governance 檢視中公開。 比較待移轉之 DTU 資料庫或集區之間的這些值時，服務目標大約相符的虛擬核心資料庫或集區可協助您更精確選取虛擬核心服務目標。

• 此對應查詢也會針對要移轉的 DTU 資料庫或彈性集區，以及虛擬核心模型中的每個硬體設定，傳回每個核心的記憶體數量。 對於需要大型記憶體資料快取以達到足夠效能的工作負載，或是需要大型記憶體授與以進行查詢處理的工作負載，請務必確定在移轉到虛擬核心之後有類似或更高的總記憶體。 針對這類工作負載，視實際效能而定，可能必須增加虛擬核心數目，才能取得足夠的總記憶體。

• 選擇虛擬核心服務目標時，應考慮 DTU 資料庫的歷史資源使用率。 CPU 資源使用率一致未充分利用的 DTU 資料庫，需要的虛擬核心數目可能比對應查詢所傳回的還少。 反之，如果 DTU 資料庫的 CPU 使用率一致偏高，導致工作負載效能不足，則需要的虛擬核心數目可能比查詢所傳回的還多。

• 如果移轉的資料庫具有間歇或無法預測的使用模式，請考慮使用 Azure SQL 資料庫計算層的無伺服器計算層。 無伺服器中的並行背景工作角色數目上限，是佈建計算中針對所設定相同虛擬核心數目上限的 75%。 此外，無伺服器中可用的記憶體上限為 3 GB 乘以所設定的虛擬核心數目上限，小於佈建計算的每個核心記憶體。 例如，相較於 40 個虛擬核心佈建計算為 204 GB，在無伺服器中設定 40 個虛擬核心數目上限時，Gen5 的記憶體上限為 120 GB。

• 在虛擬核心模型，支援的資料庫大小上限可能因硬體而有所不同。 針對大型資料庫，請檢查虛擬核心模型中單一資料庫和彈性集區所支援的大小上限。

• 針對彈性集區，使用 DTU 購買模型和虛擬核心模型之彈性集區的資源限制，對於每個集區支援的資料庫數目上限有所不同。 移轉有多個資料庫的彈性集區時，應考慮這點。

• 部分硬體設定未必可在每個區域使用。 請根據 SQL Database 的硬體設定檢查可用性。

本節提供的 DTU 與虛擬核心調整大小指導方針，旨在協助對目標資料庫服務目標進行初始估算。

目標資料庫的最佳設定取決於工作負載。 因此，若要在移轉後達到最佳性價比，可能需要利用虛擬核心模型的彈性，調整虛擬核心數目、硬體設定以及服務和計算層。 您可能還必須調整資料庫設定參數 (例如平行處理原則的最大程度)，以及 (或) 變更資料庫相容性層級，才能實現資料庫引擎最近的改良成果。

DTU 到虛擬核心的移轉範例

移轉標準 S9 資料庫

對應查詢會傳回下列結果 (為求簡單明瞭，不會顯示部分資料行)：

我們看到 DTU 標準資料庫有 24 個邏輯 CPU (虛擬核心)，每個虛擬核心 5.4 GB 的記憶體。 與此直接相符的是標準系列 (Gen5) 硬體上的一般用途 24 個虛擬核心資料庫，即 GP_Gen5_24 虛擬核心服務目標。

移轉標準 S0 資料庫

對應查詢會傳回下列結果 (為求簡單明瞭，不會顯示部分資料行)：

我們看到 DTU 資料庫有對應的 0.25 個邏輯 CPU (虛擬核心)，每個虛擬核心 1.3 GB 的記憶體。 標準系列 (Gen5) 硬體設定中最小的虛擬核心服務目標 GP_Gen5_2，提供比標準 S0 資料庫多的計算資源，因此不可能直接相符。 慣用 GP_Gen5_2 選項。 此外，如果工作負載非常適合無伺服器計算層，則 GP_S_Gen5_1 會是更接近的相符項。

移轉進階 P15 資料庫

對應查詢會傳回下列結果 (為求簡單明瞭，不會顯示部分資料行)：

我們看到 DTU 資料庫有 42 個邏輯 CPU (虛擬核心)，每個虛擬核心 4.86 GB 的記憶體。 雖然沒有 42 個核心的虛擬核心服務目標，但 BC_Gen5_40 服務目標在 CPU 和記憶體容量方面近乎對等，因此非常合適。

移轉基本 200 eDTU 彈性集區

對應查詢會傳回下列結果 (為求簡單明瞭，不會顯示部分資料行)：

我們看到 DTU 彈性集區有 4 個邏輯 CPU (虛擬核心)，每個虛擬核心 5.4 GB 的記憶體。 標準系列硬體需要 4 個虛擬核心，不過，此服務目標支援每個集區最多 200 個資料庫，而基本 200 eDTU 彈性集區支援最多 500 個資料庫。 如果要移轉的彈性集區具有 200 個以上的資料庫，則相符的虛擬核心服務目標必須是 GP_Gen5_6，以支援最多 500 個資料庫。

移轉異地複寫資料庫

從以 DTU 為基礎的模型移轉到以虛擬核心為基礎的購買模型，類似於在標準和進階服務層級資料庫之間進行異地複寫關聯性的升級或降級。 移轉期間，您不必針對一般用途與業務關鍵服務層級停止異地複寫，但必須遵循下列排序規則：

• 升級時，您必須先升級次要資料庫，然後再升級主要資料庫。
• 降級時，順序相反︰您必須先降級主要資料庫，然後再降級次要資料庫。

若要移轉至超大規模資料庫服務層級，應暫時移除異地複寫。 如需詳細資訊，請參閱將現有的資料庫移轉到超大規模資料庫。

在兩個彈性集區之間使用異地複寫時，建議將其中一個指定為主要集區，並將另一個指定為次要集區。 因此，移轉彈性集區時，應使用相同的排序指引。 不過，如果您有包含主要和次要資料庫的彈性集區，請將具有較高使用率的集區視為主要，並據以依照排序規則進行。

下表提供特定移轉案例的指引：

移轉容錯移轉群組

在遷移具有多個資料庫的容錯移轉群組時，必須個別遷移主要和次要資料庫。 過程中適用相同的考量和排序規則。 資料庫轉換成以虛擬核心為基礎的購買模型之後，容錯移轉群組在相同的原則設定下仍會有效。

建立異地複寫次要資料庫

您只能使用針對主要資料庫所使用的相同服務層級，來建立異地複寫次要資料庫 (異地次要)。 對於具有高記錄產生速率的資料庫，建議使用與主要相同的計算大小來建立異地次要。

如果您在彈性集區為單一主要資料庫建立異地次要，請確定集區的 maxVCore 設定符合主要資料庫的計算大小。 如果您為另一個彈性集區的主要資料庫建立異地次要，建議您讓集區有相同的 maxVCore 設定。

使用資料庫複製從 DTU 移轉到虛擬核心

資料庫複製會在複製作業開始之後的某個時間點，建立資料的交易一致性快照集。 它不會在該時間點之後，同步來源與目標之間的資料。

透過使用 PowerShell、Azure CLI 或 Transact-SQL，您可以將任何資料庫 (具有以 DTU 為基礎的計算大小) 複製到資料庫 (具有以虛擬核心為基礎的計算大小)，而不會有任何限制或特殊排序，但前提是目標計算大小支援來源資料庫的最大資料庫大小。 Azure 入口網站不支援將資料庫複製到不同的服務層級。

相關內容

• 使用虛擬核心購買模型的單一資料庫資源限制
• 使用虛擬核心購買模型的彈性集區資源限制