将 Azure SQL 数据库从基于 DTU 的模型迁移到基于 vCore 的模型Migrate Azure SQL Database from the DTU-based model to the vCore-based model

适用于:是Azure SQL 数据库 APPLIES TO: yesAzure SQL Database

本文介绍如何将 Azure SQL 数据库中的数据库从基于 DTU 的购买模型迁移到基于 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. “高级”服务层级中的数据库和弹性池将映射到业务关键服务层级。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 值,间接控制 vCore(逻辑 CPU)数目。Further, you have only indirect control over the number of vCores (logical CPUs), by choosing higher or lower DTU or eDTU values.

使用 vCore 模型时,客户必须明确选择硬件代系和 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

在要迁移的 DTU 数据库的上下文中执行以下 T-SQL 查询时,系统将返回 vCore 模型的每个硬件代系中匹配的 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 模型内每个硬件代系中数据库弹性池可用的 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.

请在要迁移的数据库的上下文中执行该查询,而不是在 master 数据库中执行。Execute 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

除了 vCore(逻辑 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 查询根据 CPU 容量来匹配 DTU 和 vCore 服务目标,因此对于 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 数目相同时,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 模型中使用较少数量的 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. 对于此类工作负载,可能有必要增加 vCore 的数量以获得足够的总内存,具体取决于实际性能。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. 若 DTU 数据库的 CPU 资源一直未得到充分利用,则其需要的 vCore 数目可能比映射查询所返回的数目少。DTU databases with consistently under-utilized CPU resources may need fewer vCores than the number returned by the mapping query. 相反,对于因持续的 CPU 高利用率而导致工作负载性能不足的 DTU 数据库,其需要的 vCore 数目可能比映射查询所返回的数量多。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. 请注意,无服务器中并发辅助角色(请求)的最大数目是所配置最大 vCore 的预配计算限制的 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. 此外,无服务器中可用的最大内存为配置的最大 vCore 数目乘以 3 GB。例如,当配置的最大 vCore 数目为 40 时,最大内存为 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 模型的灵活性来调整 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.

DTU 到 vCore 的迁移示例DTU 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),每个 vCore 的内存为 5.4 GB,并使用 Gen5 硬件。We see that the DTU database has 24 logical CPUs (vCores), with 5.4 GB of memory per vCore, and is using Gen5 hardware. 与之直接匹配是 Gen5 硬件上的常规用途 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),每个 vCore 的内存为 0.42 GB,并使用 Gen4 硬件。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. Gen4 和 Gen5 硬件代系中的最小 vCore 服务目标为“GP_Gen4_1”和“GP_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. 由于 Gen4 硬件即将停用,因此首选“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.

迁移高级 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),每个 vCore 的内存为 4.86 GB,并使用 Gen5 硬件。We see that the DTU database has 42 logical CPUs (vCores), with 4.86 GB of memory per vCore, and is using Gen5 hardware. 尽管没有 vCore 服务目标具有 42 个内核,但“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),每个 vCore 的内存为 5.4 GB,并使用 Gen5 硬件。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 个数据库,则匹配的 vCore 服务目标必须为“GP_Gen5_6”,它支持最多 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 的购买模型类似于在标准和高级服务层级中的数据库之间升级或降级异地复制关系。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
高级Premium 业务关键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
高级Premium 常规用途General purpose 降级Downgrade 必须先迁移主数据库Must migrate primary first
常规用途General purpose 高级Premium 升级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 的计算大小的任何数据库复制到采用基于 vCore 的计算大小的数据库,且无需遵守上述限制或特殊的顺序,前提是目标计算大小支持源数据库的最大数据库大小。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