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

  • 發行項

適用於：Azure SQL 資料庫

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

移轉資料庫

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

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

若要使用 Azure 入口網站將資料庫移轉至不同的購買模型，請遵循下列步驟：

  1. 在 Azure 入口網站中，前往您的 SQL Database。

  2. 選取 [設定] 下的 [計算 + 儲存體]。

  3. 使用 [服務層級] 底下的下拉式清單，選取新的購買模型和服務層級：

    選取 [服務層級] Azure 入口網站中 SQL 資料庫的 [計算 + 儲存體] 頁面的螢幕擷取畫面。

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

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

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

提示

由於不會考慮 DTU 資料庫或彈性集區所使用的特定類型硬體，因此是近似的法則。

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

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

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

DTU 與虛擬核心的對應

下列 T-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 資料庫的歷史資源使用率。 如果 DTU 資料庫的 CPU 資源使用率一致過高，則可能需要比對應查詢所傳回更少的虛擬核心數目。 相反地，如果 DTU 資料庫的 CPU 使用率一致很高而導致不當的工作負載效能，則可能需要比查詢所傳回更多的虛擬核心數目。
  • 如果移轉的資料庫具有間歇或無法預測的使用模式，請考慮使用無伺服器計算層。 請注意，無伺服器中的並行背景工作角色數目上限是佈建計算中針對所設定相同虛擬核心數目上限的 75%。 此外，無伺服器中可用的記憶體上限為 3 GB 乘以所設定的虛擬核心數目上限，小於佈建計算的每個核心記憶體。 例如，相較於 40 個虛擬核心佈建計算為 204 GB，在無伺服器中設定 40 個虛擬核心數目上限時，Gen5 的記憶體上限為 120 GB。
  • 在虛擬核心模型中，支援的資料庫大小上限可能會因硬體而有所不同。 針對大型資料庫，請檢查虛擬核心模型中單一資料庫和彈性集區所支援的大小上限。
  • 針對彈性集區，DTU 和虛擬核心模型對於每個集區支援的資料庫數目上限會有所不同。 移轉具有多個資料庫的彈性集區時，應考慮這點。
  • 某些硬體設定可能無法在每個區域中使用。 請根據 SQL Database 的硬體設定檢查可用性。

重要

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

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

DTU 到虛擬核心的移轉範例

注意

下列範例中的值僅供說明之用。 在描述案例中傳回的實際值可能會不同。

移轉標準 S9 資料庫

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

dtu_logical_cpus dtu_memory_per_core_gb standard_series_vcores standard_series_memory_per_core_gb
24.00 5.40 24.000 5.05

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

移轉標準 S0 資料庫

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

dtu_logical_cpus dtu_memory_per_core_gb standard_series_vcores standard_series_memory_per_core_gb
0.25 1.3 0.500 5.05

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

移轉進階 P15 資料庫

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

dtu_logical_cpus dtu_memory_per_core_gb standard_series_vcores standard_series_memory_per_core_gb
42.00 4.86 42.000 5.05

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

移轉基本 200 eDTU 彈性集區

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

dtu_logical_cpus dtu_memory_per_core_gb standard_series_vcores standard_series_memory_per_core_gb
4.00 5.40 4.000 5.05

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

移轉異地複寫資料庫

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

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

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

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

目前的服務層級 目標服務層級 遷移類型 使用者動作
標準 一般用途 橫向 可依任何順序移轉，但必須確保適當的虛擬核心大小調整，如上所述
Premium 業務關鍵 橫向 可依任何順序移轉，但必須確保適當的虛擬核心大小調整，如上所述
標準 業務關鍵 升級 必須先遷移次要
業務關鍵 標準 降級 必須先遷移主要
Premium 一般用途 降級 必須先遷移主要
一般用途 Premium 升級 必須先遷移次要
業務關鍵 一般用途 降級 必須先遷移主要
一般用途 業務關鍵 升級 必須先遷移次要

移轉容錯移轉群組

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

建立異地複寫次要資料庫

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

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

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

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

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

下一步