將 Azure SQL Database 從以 DTU 為基礎的模型遷移到以 vCore 為基礎的模型Migrate Azure SQL Database from the DTU-based model to the vCore-based model

適用於: Azure SQL Database

本文說明如何從以 DTU 為基礎的購買模型 ,將 Azure SQL Database 中的資料庫移轉到以 vCore 為基礎的購買模型This article describes how to migrate your database in Azure SQL Database from the DTU-based purchasing model to the vCore-based purchasing model.

移轉資料庫Migrate a database

將資料庫從以 DTU 為基礎的購買模型遷移到以 vCore 為基礎的購買模型,類似于在「基本」、「標準」和「高階」服務層級中的服務目標之間進行調整,並具有類似的 持續時間 和在遷移程式結束時的 最短停機 時間。Migrating a database from the DTU-based purchasing model to the vCore-based purchasing model is similar to scaling between service objectives in the Basic, Standard, and Premium service tiers, with similar duration and a minimal downtime at the end of the migration process. 遷移至以 vCore 為基礎的購買模型的資料庫可隨時以同樣的方式遷移回以 DTU 為基礎的購買模型,但遷移至 超大規模 服務層的資料庫除外。A database migrated to the vCore-based purchasing model can be migrated back to the DTU-based purchasing model at any time in the same fashion, with the exception of databases migrated to the Hyperscale service tier.

選擇 vCore 服務層級和服務目標Choose the vCore service tier and service objective

針對大部分的 DTU 來 vCore 遷移案例,基本和標準服務層級中的資料庫和彈性集區會對應至 一般用途 服務層級。For most DTU to vCore migration scenarios, databases and elastic pools in the Basic and Standard service tiers will map to the General Purpose service tier. Premium 服務層中的資料庫和彈性集區會對應至 商務關鍵 服務層級。Databases and elastic pools in the Premium service tier will map to the Business Critical service tier. 視應用程式案例和需求而定, 超大規模 服務層級通常可以作為所有 DTU 服務層級中單一資料庫的遷移目標。Depending on application scenario and requirements, the Hyperscale service tier can often be used as the migration target for single databases in all DTU service tiers.

若要針對 vCore 模型中已遷移的資料庫選擇服務目標或計算大小,您可以使用簡單但近似的經驗法則:基本或標準層中的每 100 Dtu 至少 需要 1 vCore,而進階層中的每 125 dtu 至少需要 1 個 vCore。To choose the service objective, or compute size, for the migrated database in the vCore model, you can use a simple but approximate rule of thumb: every 100 DTUs in the Basic or Standard tiers require at least 1 vCore, and every 125 DTUs in the Premium tier require at least 1 vCore.

提示

這是大約的規則,因為它不會考慮 DTU 資料庫或彈性集區所使用的硬體世代。This rule is approximate because it does not consider the hardware generation used for the DTU database or elastic pool.

在 DTU 模型中,任何可用的 硬體世代 都可用於您的資料庫或彈性集區。In the DTU model, any available hardware generation can be used for your database or elastic pool. 此外,您只需選擇較高或較低的 DTU 或 eDTU 值,就可以直接對虛擬核心 (邏輯 Cpu 的數目進行間接控制) 。Further, you have only indirect control over the number of vCores (logical CPUs), by choosing higher or lower DTU or eDTU values.

使用 vCore 模型時,客戶必須明確地選擇硬體世代以及虛擬核心 (邏輯) Cpu 數目。With the vCore model, customers must make an explicit choice of both the hardware generation and the number of vCores (logical CPUs). DTU 模型不提供這些選擇,不過硬體世代以及用於每個資料庫和彈性集區的邏輯 Cpu 數目,都會透過動態管理檢視來公開。The DTU model does not offer these choices, however the hardware generation and the number of logical CPUs used for every database and elastic pool are exposed via dynamic management views. 這讓您能夠更精確地判斷相符的 vCore 服務目標。This makes it possible to determine the matching vCore service objective more precisely.

下列方法會使用這項資訊來判斷具有類似資源配置的 vCore 服務目標,以在遷移至 vCore 模型之後取得類似的效能層級。The following approach uses this information to determine a vCore service objective with a similar allocation of resources, to obtain a similar level of performance after migration to the vCore model.

DTU 與 vCore 的對應DTU to vCore mapping

下面的 T-SQL 查詢,在要遷移的 DTU 資料庫內容中執行時,將會傳回相符的 (可能會在 vCore 模型中的每個硬體產生中) 數目的虛擬核心。A T-SQL query below, when executed in the context of a DTU database to be migrated, will return a matching (possibly fractional) number of vCores in each hardware generation in the vCore model. 藉由將此數位四捨五入到 vCore 模型中每個硬體產生之 資料庫彈性 集區的最虛擬核心可用數量,客戶可以選擇最符合其 DTU 資料庫或彈性集區的 vCore 服務目標。By rounding this number to the closest number of vCores available for databases and elastic pools in each hardware generation in the vCore model, customers can choose the vCore service objective that is the closest match for their DTU database or elastic pool.

範例一節將說明使用這種方法的範例遷移案例。Sample migration scenarios using this approach are described in the Examples section.

在要遷移之資料庫的內容中執行此查詢,而不是在資料庫中執行 masterExecute this query in the context of the database to be migrated, rather than in the master database. 在遷移彈性集區時,請在集區中任何資料庫的內容中執行查詢。When migrating an elastic pool, execute the query in the context of any database in the pool.

WITH dtu_vcore_map AS
(
SELECT TOP (1) rg.slo_name,
               CASE WHEN rg.slo_name LIKE '%SQLG4%' THEN 'Gen4'
                    WHEN rg.slo_name LIKE '%SQLGZ%' THEN 'Gen4'
                    WHEN rg.slo_name LIKE '%SQLG5%' THEN 'Gen5'
                    WHEN rg.slo_name LIKE '%SQLG6%' THEN 'Gen5'
               END 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 = 'VISIBLE ONLINE') AS s
CROSS JOIN sys.dm_os_job_object AS jo
WHERE dtu_limit > 0
      AND
      DB_NAME() <> 'master'
)
SELECT dtu_logical_cpus,
       dtu_hardware_gen,
       dtu_memory_per_core_gb,
       CASE WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus
            WHEN dtu_hardware_gen = 'Gen5' THEN dtu_logical_cpus * 0.7
       END AS Gen4_vcores,
       7 AS Gen4_memory_per_core_gb,
       CASE WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus * 1.7
            WHEN dtu_hardware_gen = 'Gen5' THEN dtu_logical_cpus
       END AS Gen5_vcores,
       5.05 AS Gen5_memory_per_core_gb,
       CASE WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus
            WHEN dtu_hardware_gen = 'Gen5' 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 = 'Gen5' THEN dtu_logical_cpus * 0.9
       END AS M_vcores,
       29.4 AS M_memory_per_core_gb
FROM dtu_vcore_map;

其他因素Additional factors

除了虛擬核心數目 (邏輯 Cpu) 和硬體世代之外,其他數個因素可能會影響 vCore 服務目標的選擇:Besides the number of vCores (logical CPUs) and the hardware generation, several other factors may influence the choice of vCore service objective:

  • 對應 T-SQL 查詢符合 DTU 和 vCore 服務目標的 CPU 容量,因此對於 CPU 系結的工作負載而言,結果會更準確。The mapping T-SQL query matches DTU and vCore service objectives in terms of their CPU capacity, therefore the results will be more accurate for CPU-bound workloads.
  • 針對相同的硬體世代和相同數量的虛擬核心,vCore 資料庫的 IOPS 和交易記錄輸送量資源限制通常會高於 DTU 資料庫。For the same hardware generation and the same number of vCores, IOPS and transaction log throughput resource limits for vCore databases are often higher than for DTU databases. 對於 IO 系結的工作負載,可能會降低 vCore 模型中的虛擬核心數目,以達到相同層級的效能。For IO-bound workloads, it may be possible to lower the number of vCores in the vCore model to achieve the same level of performance. 以絕對值表示的 DTU 和 vCore 資料庫的資源限制會在 sys.dm_user_db_resource_governance 視圖中公開。Resource limits for DTU and vCore databases in absolute values are exposed in the sys.dm_user_db_resource_governance view. 比較要遷移的 DTU 資料庫與使用大約相符服務目標的 vCore 資料庫之間的這些值,可協助您更精確地選取 vCore 服務目標。Comparing these values between the DTU database to be migrated and a vCore database using an approximately matching service objective will help you select the vCore service objective more precisely.
  • 對應查詢也會針對要遷移的 DTU 資料庫或彈性集區,以及 vCore 模型中的每個硬體產生,傳回每個核心的記憶體數量。The mapping query also returns the amount of memory per core for the DTU database or elastic pool to be migrated, and for each hardware generation in the vCore model. 在遷移至 vCore 之後,如果需要大型記憶體資料快取以達到足夠效能的工作負載,或需要大型記憶體授與進行查詢處理的工作負載,請務必確定記憶體總計或更高的記憶體。Ensuring similar or higher total memory after migration to vCore is important for workloads that require a large memory data cache to achieve sufficient performance, or workloads that require large memory grants for query processing. 針對這類工作負載,視實際效能而定,可能需要增加虛擬核心數目,以取得足夠的總記憶體。For such workloads, depending on actual performance, it may be necessary to increase the number of vCores to get sufficient total memory.
  • 選擇 vCore 服務目標時,應考慮 DTU 資料庫的歷程 記錄資源使用量The historical resource utilization of the DTU database should be considered when choosing the vCore service objective. 具有一致使用量過低之 CPU 資源的 DTU 資料庫,可能需要比對應查詢所傳回的數目少虛擬核心。DTU databases with consistently under-utilized CPU resources may need fewer vCores than the number returned by the mapping query. 相反地,如果 DTU 資料庫的 CPU 使用率過高,可能會需要比查詢所傳回的更多虛擬核心。Conversely, DTU databases where consistently high CPU utilization causes inadequate workload performance may require more vCores than returned by the query.
  • 如果使用間歇或無法預測的使用模式來遷移資料庫,請考慮使用 無伺服器 計算層級。If migrating databases with intermittent or unpredictable usage patterns, consider the use of Serverless compute tier. 請注意,在無伺服器中) (要求的並行工作者數目上限為75% 布建計算中已設定的最大虛擬核心數目的限制。Note that the max number of concurrent workers (requests) in serverless is 75% the limit in provisioned compute for the same number of max vcores configured. 此外,無伺服器中可用的最大記憶體是已設定的最大虛擬核心數目的 3 GB 倍;例如,在設定 40 max 虛擬核心時,最大記憶體是 120 GB。Also, the max memory available in serverless is 3 GB times the maximum number of vcores configured; for example, max memory is 120 GB when 40 max vcores are configured.
  • 在 vCore 模型中,支援的資料庫大小上限可能會因硬體產生而有所不同。In the vCore model, the supported maximum database size may differ depending on hardware generation. 針對大型資料庫,請檢查 vCore 模型中針對 單一資料庫彈性集區所支援的最大大小。For large databases, check supported maximum sizes in the vCore model for single databases and elastic pools.
  • 針對彈性集區, DTUvCore 模型會有每個集區支援的最大資料庫數目差異。For elastic pools, the DTU and vCore models have differences in the maximum supported number of databases per pool. 當您遷移具有多個資料庫的彈性集區時,應考慮這一點。This should be considered when migrating elastic pools with many databases.
  • 某些硬體世代可能無法在每個區域中使用。Some hardware generations may not be available in every region. 檢查 硬體世代下的可用性。Check availability under Hardware Generations.

重要

系統會提供上述的 DTU 來 vCore 大小調整指導方針,以協助進行目標資料庫服務目標的初始估計。The DTU to vCore sizing guidelines above are provided to help in the initial estimation of the target database service objective.

目標資料庫的最佳設定取決於工作負載。The optimal configuration of the target database is workload-dependent. 因此,在遷移後達到最佳的價格/效能比率,可能需要利用 vCore 模型的彈性來調整虛擬核心數目、 硬體世代服務計算 層,以及調整其他資料庫設定參數,例如平行處理原則的 最大程度Thus, achieving the optimal price/performance ratio after migration may require leveraging the flexibility of the vCore model to adjust the number of vCores, the hardware generation, the service and compute tiers, as well as tuning of other database configuration parameters, such as maximum degree of parallelism.

VCore 遷移範例的 DTUDTU to vCore migration examples

注意

下列範例中的值僅供說明之用。The values in the examples below are for illustration purposes only. 在描述案例中傳回的實際值可能會不同。Actual values returned in described scenarios may be different.

遷移標準 S9 資料庫Migrating a Standard S9 database

對應查詢會傳回下列結果 (沒有為了簡潔起見而顯示的部分資料行) :The mapping query returns the following result (some columns not shown for brevity):

dtu_logical_cpusdtu_logical_cpus dtu_hardware_gendtu_hardware_gen dtu_memory_per_core_gbdtu_memory_per_core_gb Gen4_vcoresGen4_vcores Gen4_memory_per_core_gbGen4_memory_per_core_gb Gen5_vcoresGen5_vcores Gen5_memory_per_core_gbGen5_memory_per_core_gb
24.0024.00 Gen5Gen5 5.405.40 16.80016.800 77 24.00024.000 5.055.05

我們看到 DTU 資料庫有24個邏輯 Cpu (虛擬核心) ,每個 vCore 5.4 GB 的記憶體,而且正在使用第5代硬體。We see that the DTU database has 24 logical CPUs (vCores), with 5.4 GB of memory per vCore, and is using Gen5 hardware. 直接符合的是第5代硬體上的一般用途 24 vCore 資料庫,亦即 GP_Gen5_24 的 vCore 服務目標。The direct match to that is a General Purpose 24 vCore database on Gen5 hardware, i.e. the GP_Gen5_24 vCore service objective.

遷移標準 S0 資料庫Migrating a Standard S0 database

對應查詢會傳回下列結果 (沒有為了簡潔起見而顯示的部分資料行) :The mapping query returns the following result (some columns not shown for brevity):

dtu_logical_cpusdtu_logical_cpus dtu_hardware_gendtu_hardware_gen dtu_memory_per_core_gbdtu_memory_per_core_gb Gen4_vcoresGen4_vcores Gen4_memory_per_core_gbGen4_memory_per_core_gb Gen5_vcoresGen5_vcores Gen5_memory_per_core_gbGen5_memory_per_core_gb
0.250.25 Gen4Gen4 0.420.42 0.2500.250 77 0.4250.425 5.055.05

我們看到 DTU 資料庫具有相當於0.25 的邏輯 Cpu (虛擬核心) 、每個 vCore 0.42 GB 的記憶體,以及使用第4代硬體。We see that the DTU database has the equivalent of 0.25 logical CPUs (vCores), with 0.42 GB of memory per vCore, and is using Gen4 hardware. 第4代和第5代硬體世代中最小的 vCore 服務目標 GP_Gen4_1GP_Gen5_2 ,提供比標準 S0 資料庫更多的計算資源,因此不可能直接符合。The smallest vCore service objectives in the Gen4 and Gen5 hardware generations, GP_Gen4_1 and GP_Gen5_2 , provide more compute resources than the Standard S0 database, so a direct match is not possible. 由於第4代硬體已 解除委任,因此偏好 GP_Gen5_2 選項。Since Gen4 hardware is being decommissioned, the GP_Gen5_2 option is preferred. 此外,如果工作負載適用于 無伺服器 計算層級,則 GP_S_Gen5_1 會是更接近的相符項。Additionally, if the workload is well-suited for the Serverless compute tier, then GP_S_Gen5_1 would be a closer match.

遷移 Premium P15 資料庫Migrating a Premium P15 database

對應查詢會傳回下列結果 (沒有為了簡潔起見而顯示的部分資料行) :The mapping query returns the following result (some columns not shown for brevity):

dtu_logical_cpusdtu_logical_cpus dtu_hardware_gendtu_hardware_gen dtu_memory_per_core_gbdtu_memory_per_core_gb Gen4_vcoresGen4_vcores Gen4_memory_per_core_gbGen4_memory_per_core_gb Gen5_vcoresGen5_vcores Gen5_memory_per_core_gbGen5_memory_per_core_gb
42.0042.00 Gen5Gen5 4.864.86 29.40029.400 77 42.00042.000 5.055.05

我們看到 DTU 資料庫具有42個邏輯 Cpu (虛擬核心) ,每個 vCore 4.86 GB 的記憶體,而且正在使用第5代硬體。We see that the DTU database has 42 logical CPUs (vCores), with 4.86 GB of memory per vCore, and is using Gen5 hardware. 雖然沒有42核心的 vCore 服務目標,但 BC_Gen5_40 的服務目標在 CPU 和記憶體容量方面都非常接近,而且是非常相符的。While there is not a vCore service objective with 42 cores, the BC_Gen5_40 service objective is very close both in terms of CPU and memory capacity, and is a good match.

遷移基本的 200 eDTU 彈性集區Migrating a Basic 200 eDTU elastic pool

對應查詢會傳回下列結果 (沒有為了簡潔起見而顯示的部分資料行) :The mapping query returns the following result (some columns not shown for brevity):

dtu_logical_cpusdtu_logical_cpus dtu_hardware_gendtu_hardware_gen dtu_memory_per_core_gbdtu_memory_per_core_gb Gen4_vcoresGen4_vcores Gen4_memory_per_core_gbGen4_memory_per_core_gb Gen5_vcoresGen5_vcores Gen5_memory_per_core_gbGen5_memory_per_core_gb
4.004.00 Gen5Gen5 5.405.40 2.8002.800 77 4.0004.000 5.055.05

我們看到 DTU 彈性集區有4個邏輯 Cpu (虛擬核心) (每個 vCore 5.4 GB 記憶體),以及使用第5代硬體。We see that the DTU elastic pool has 4 logical CPUs (vCores), with 5.4 GB of memory per vCore, and is using Gen5 hardware. VCore 模型中的直接相符是 GP_Gen5_4 彈性集區。The direct match in the vCore model is a GP_Gen5_4 elastic pool. 不過,此服務目標支援每個集區最多200個資料庫,而基本 200 eDTU 彈性集區則支援最多500個資料庫。However, this service objective supports a maximum of 200 databases per pool, while the Basic 200 eDTU elastic pool supports up to 500 databases. 如果要遷移的彈性集區具有200以上的資料庫,則必須 GP_Gen5_6 相符的 vCore 服務目標,以支援最多500個資料庫。If the elastic pool to be migrated has more than 200 databases, the matching vCore service objective would have to be GP_Gen5_6 , which supports up to 500 databases.

遷移異地複寫資料庫Migrate geo-replicated databases

從以 DTU 為基礎的模型遷移到以 vCore 為基礎的購買模型,類似于在 standard 和 premium 服務層中的資料庫之間升級或降級異地複寫關聯性。Migrating from the DTU-based model to the vCore-based purchasing model is similar to upgrading or downgrading the geo-replication relationships between databases in the standard and premium service tiers. 在遷移期間,您不需要停止異地複寫,但必須遵循下列排序規則:During migration, you don't have to stop geo-replication, but you must follow these sequencing rules:

  • 升級時,您必須先升級次要資料庫,然後再升級主要資料庫。When upgrading, you must upgrade the secondary database first, and then upgrade the primary.
  • 降級時,順序相反︰您必須先降級主要資料庫,然後再降級次要資料庫。When downgrading, reverse the order: you must downgrade the primary database first, and then downgrade the secondary.

當您在兩個彈性集區之間使用異地複寫時,建議您將一個集區指定為主要集區,並將另一個集區指定為次要集區。When you're using geo-replication between two elastic pools, we recommend that you designate one pool as the primary and the other as the secondary. 在此情況下,當您要遷移彈性集區時,您應該使用相同的排序指引。In that case, when you're migrating elastic pools you should use the same sequencing guidance. 但是,如果您有包含主要和次要資料庫的彈性集區,請將集區的使用率視為主要和次要資料庫,並據以依照排序規則進行。However, if you have elastic pools that contain both primary and secondary databases, treat the pool with the higher utilization as the primary and follow the sequencing rules accordingly.

下表提供特定遷移案例的指引:The following table provides guidance for specific migration scenarios:

目前的服務層級Current service tier 目標服務層級Target service tier 遷移類型Migration type 使用者動作User actions
標準Standard 一般用途General purpose 橫向Lateral 可以依任何順序遷移,但必須確保適當的 vCore 大小調整,如上所述Can migrate in any order, but need to ensure appropriate vCore sizing as described above
PremiumPremium 業務關鍵Business critical 橫向Lateral 可以依任何順序遷移,但必須確保適當的 vCore 大小調整,如上所述Can migrate in any order, but need to ensure appropriate vCore sizing as described above
標準Standard 業務關鍵Business critical 升級Upgrade 必須先遷移次要Must migrate secondary first
業務關鍵Business critical 標準Standard 降級Downgrade 必須先遷移主要Must migrate primary first
PremiumPremium 一般用途General purpose 降級Downgrade 必須先遷移主要Must migrate primary first
一般用途General purpose PremiumPremium 升級Upgrade 必須先遷移次要Must migrate secondary first
業務關鍵Business critical 一般用途General purpose 降級Downgrade 必須先遷移主要Must migrate primary first
一般用途General purpose 業務關鍵Business critical 升級Upgrade 必須先遷移次要Must migrate secondary first

遷移容錯移轉群組Migrate failover groups

在遷移具有多個資料庫的容錯移轉群組時,必須個別遷移主要和次要資料庫。Migration of failover groups with multiple databases requires individual migration of the primary and secondary databases. 過程中適用相同的考量和排序規則。During that process, the same considerations and sequencing rules apply. 將資料庫轉換成以 vCore 為基礎的購買模型之後,容錯移轉群組將會以相同的原則設定保持有效。After the databases are converted to the vCore-based purchasing model, the failover group will remain in effect with the same policy settings.

建立異地複寫次要資料庫Create a geo-replication secondary database

您只能使用主資料庫所用的相同服務層級,來建立異地複寫次要資料庫, (異地複寫的次要資料庫) 。You can create a geo-replication secondary database (a geo-secondary) only by using the same service tier as you used for the primary database. 對於記錄產生率較高的資料庫,我們建議使用與主資料庫相同的計算大小來建立異地次要資料庫。For databases with a high log-generation rate, we recommend creating the geo-secondary with the same compute size as the primary.

如果您要在彈性集區中為單一主資料庫建立異地次要資料庫,請確定集區的 maxVCore 設定符合主資料庫的計算大小。If you're creating a geo-secondary in the elastic pool for a single primary database, make sure the maxVCore setting for the pool matches the primary database's compute size. 如果您要為另一個彈性集區中的主資料庫建立異地次要資料庫,建議您讓集區具有相同的 maxVCore 設定。If you're creating a geo-secondary for a primary in another elastic pool, we recommend that the pools have the same maxVCore settings.

使用資料庫複製從 DTU 遷移至 vCoreUse database copy to migrate from DTU to vCore

您可以將任何資料庫 (具有以 DTU 為基礎的計算大小) 複製到資料庫 (具有以虛擬核心為基礎的計算大小),而不會有任何限制或特殊排序,但前提是目標計算大小支援來源資料庫的最大資料庫大小。You can copy any database with a DTU-based compute size to a database with a vCore-based compute size without restrictions or special sequencing as long as the target compute size supports the maximum database size of the source database. 資料庫複本會在複製作業開始時建立資料的快照集,而且不會在來源與目標之間同步處理資料。The database copy creates a snapshot of the data as of the starting time of the copy operation and doesn't synchronize data between the source and the target.

後續步驟Next steps