将 Azure SQL 数据库从基于 DTU 的模型迁移到基于 vCore 的模型

适用于：Azure SQL 数据库

本文介绍如何将 Azure SQL 数据库中的数据库从基于 DTU 的购买模型迁移到基于 vCore 的购买模型。

迁移数据库

将数据库从基于 DTU 的购买模型迁移到基于 vCore 的购买模型类似于在“基本”、“标准”和“高级”服务层级中的服务目标之间进行缩放，并且在迁移过程结束时，持续时间相似且停机时间极短。 迁移到基于 vCore 的购买模型的数据库可以在任何时间通过相同的步骤迁移回基于 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>');

选择 vCore 服务层级和服务目标

对于大多数从 DTU 到 vCore 的迁移应用场景，“基本”和“标准”服务层级中的数据库和弹性池将映射到“常规用途”服务层级。 “高级”服务层级中的数据库和弹性池将映射到“业务关键”服务层级。 根据应用程序方案和要求，超大规模服务层级通常可用作所有 DTU 服务层级中数据库和弹性池的迁移目标。

若要为 vCore 模型中已迁移的数据库选择服务目标或计算大小，可以使用一种基本但近似的经验法则：“基本”或“标准”层级中的每 100 个 DTU 需要至少 1 个 vCore，“高级”层级中的每 125 个 DTU 需要至少 1 个 vCore。

在 DTU 模型中，只能通过选择更高或更低的 DTU 或 eDTU 值，间接控制 vCore（逻辑 CPU）数目。

在 vCore 模型中，客户必须明确选择硬件配置和 vCore（逻辑 CPU）数目。 虽然 DTU 模型不提供这些选项，但通过动态管理视图公开了用于每个数据库和弹性池的硬件类型和逻辑 CPU 数目。 这样就可以更精确地确定匹配的 vCore 服务目标。

以下方法使用此信息来确定具有相似资源分配的 vCore 服务目标，以在迁移到 vCore 模型后获得相似的性能级别。

DTU 到 vCore 的映射

以下 Transact-SQL 查询在要迁移的 DTU 数据库的上下文中执行时，会返回 vCore 模型中每个硬件配置中的匹配 vCore 数目（可能是小数）。 你可以将此数字舍入为与 vCore 模型内每个硬件配置中数据库和弹性池可用的 vCore 数目最接近的数，客户可以选择与其 DTU 数据库或弹性池最匹配的 vCore 服务目标。

示例部分中介绍了使用此方法的示例迁移方案。

请在要迁移的数据库的上下文中执行该查询，而不是在 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
FROM dtu_vcore_map;

其他因素

除了 vCore（逻辑 CPU）数目和硬件类型之外，还有一些其他因素也可能影响 vCore 服务目标的选择：

• 映射 Transact-SQL 查询根据 CPU 容量来匹配 DTU 和 vCore 服务目标，因此对于 CPU 密集型工作负载，结果更准确。

• 硬件类型和 vCore 数目相同时，vCore 数据库的 IOPS 和事务日志吞吐量资源限制通常高于 DTU 数据库。 对于 IO 密集型工作负载，在 vCore 模型中使用较少数量的 vCore 就有可能达到相同的性能级别。 sys.dm_user_db_resource_governance 视图中公开了 DTU 和 vCore 数据库的实际资源限制。 在要迁移的 DTU 数据库或池和使用近似匹配服务目标的 vCore 数据库或池之间比较这些值有助于更精确地选择 vCore 服务目标。

• 映射查询还返回要迁移的 DTU 数据库或弹性池以及 vCore 模型中每个硬件配置的每个内核的内存量。 对于需要大量内存数据缓存来实现足够性能的工作负载或需要大量内存授予来进行查询处理的工作负载，必须确保在迁移到 vCore 之后具有相似或更高的总内存。 对于此类工作负载，可能有必要增加 vCore 的数量以获得足够的总内存，具体取决于实际性能。

• 选择 vCore 服务目标时，应考虑 DTU 数据库的历史资源使用率。 若 DTU 数据库的 CPU 资源一直未得到充分利用，则其需要的 vCore 数目可能比映射查询所返回的数目少。 相反，对于因持续的 CPU 高利用率而导致工作负载性能不足的 DTU 数据库，其需要的 vCore 数目可能比映射查询所返回的数量多。

• 如果要迁移具有间歇性或不可预测的使用模式的数据库，请考虑使用“用于 Azure SQL 数据库的无服务器计算层级”计算层级。 无服务器中并发辅助角色的最大数目是所配置的最大 vCore 数的预配计算限制的 75%。 此外，无服务器中可用的最大内存为配置的最大 vCore 数乘以 3 GB，此结果小于预配计算的每核内存。 例如，在无服务器中配置 40 个最大 vCore 时，在 Gen5 上的最大内存为 120 GB，而对于 40 个 vCore 预配的计算则为 204 GB。

• 在 vCore 模型中，支持的最大数据库大小可能因硬件而异。 对于大型数据库，请检查 vCore 模型中支持的单一数据库和弹性池最大大小。

• 对于弹性池，使用 DTU 购买模型的弹性池的资源限制和 vCore 模型对每个池支持的数据库最大数目有所不同。 迁移包含多个数据库的弹性池时，应该考虑这一点。

本节中提供的 DTU 到 vCore 的大小调整指南旨在帮助初步估计目标数据库服务目标。

目标数据库的最佳配置取决于工作负荷。 因此，若要在迁移后达到最佳性价比，可能需要使用 vCore 模型的灵活性来调整 Vcore 数目、硬件配置以及服务和计算层级。 可能还需要调整数据库配置参数（如最大并行度），和/或更改数据库兼容性级别以启用数据库引擎中的最近改进。

DTU 到 vCore 的迁移示例

迁移标准 S9 数据库

映射查询返回以下结果（为简洁起见，某些列未显示）：

我们看到 DTU 标准数据库具有 24 个逻辑 CPU (vCore)，每个 vCore 的内存为 5.4 GB。 与之直接匹配的是标准系列 (Gen5) 硬件上的常规用途 2 vCore 数据库，即“GP_Gen5_24”vCore 服务目标。

迁移标准 S0 数据库

映射查询返回以下结果（为简洁起见，某些列未显示）：

我们看到 DTU 数据库具有相当的 0.25 个逻辑 CPU (vCore)，每个 vCore 的内存为 1.3 GB。 标准系列 (Gen5) 硬件配置中的最小 vCore 服务目标为 GP_Gen5_2，其提供的计算资源超出了标准 S0 数据库的需求，因此无法进行直接匹配。 GP_Gen5_2 选项是首选。 此外，如果工作负载很适合无服务器计算层，那么“GP_S_Gen5_1”更匹配。

迁移高级 P15 数据库

映射查询返回以下结果（为简洁起见，某些列未显示）：

我们看到 DTU 数据库具有 42 个逻辑 CPU (vCore)，每个 vCore 的内存为 4.86 GB。 尽管没有 vCore 服务目标具有 42 个内核，但 BC_Gen5_40 服务目标在 CPU 和内存容量方面几乎相当，因此是一个非常有效的匹配项。

迁移基本 200 eDTU 弹性池

映射查询返回以下结果（为简洁起见，某些列未显示）：

我们看到 DTU 弹性池具有 4 个逻辑 CPU (vCore)，每个 vCore 的内存为 5.4 GB。 标准系列硬件需要有 4 个 vCore，但是，此服务目标的每个池支持最多 200 个数据库，而基本 200 eDTU 弹性池支持最多 500 个数据库。 如果要迁移的弹性池具有超过 200 个数据库，则匹配的 vCore 服务目标必须为“GP_Gen5_6”，它支持最多 500 个数据库。

迁移异地复制的数据库

从基于 DTU 的模型迁移到基于 vCore 的购买模型类似于在标准和高级服务层级中的数据库之间升级或降级异地复制关系。 在迁移过程中，不必停止“常规用途”和“业务关键”服务层级的异地复制，但必须遵循以下顺序规则：

• 升级时，必须先升级辅助数据库，再升级主数据库。
• 降级时，必须反转顺序：先降级主数据库，再降级辅助数据库。

若要迁移至“超大规模”服务层级，应暂时删除异地复制。 有关详细信息，请参阅将现有数据库迁移到“超大规模”。

在两个弹性池之间使用异地复制时，建议将一个池指定为主池，另一个池指定为辅助池。 在这种情况下，迁移弹性池时应遵循相同的顺序指导。 但是，如果弹性池同时包含主数据库和辅助数据库，请将利用率较高的池视为主池，并相应地遵循顺序规则。

下表提供具体迁移场景的指导：

迁移故障转移组

迁移包含多个数据库的故障转移组需要单独迁移主数据库和辅助数据库。 在此过程中，请遵循相同的注意事项和顺序规则。 将数据库转换到基于 vCore 的购买模型后，故障转移组将保持有效并使用相同的策略设置。

创建异地复制辅助数据库

只能使用与主数据库所用的相同服务层级来创建异地复制辅助数据库。 对于日志生成速率较高的数据库，我们建议使用与主数据库相同的计算大小创建异地辅助数据库。

如果在弹性池中为单个主数据库创建异地辅助数据库，请确保对该池使用的 maxVCore 设置与主数据库计算大小相匹配。 如果为另一个弹性池中的主数据库创建异地辅助数据库，我们建议对该池使用相同的 maxVCore 设置。

使用数据库副本从 DTU 迁移到 vCore

数据库复制在复制操作开始后的某个时间点创建数据的事务一致快照。 在该时间点之后，它不会在源和目标之间同步数据。

可以使用 PowerShell、Azure CLI 或 Transact-SQL 将采用基于 DTU 的计算大小的任何数据库复制到采用基于 vCore 的计算大小的数据库，且无需遵守上述限制或特殊的顺序，前提是目标计算大小支持源数据库的最大数据库大小。 Azure 门户不支持将数据库复制到其他服务层级。

相关内容

• 使用 vCore 购买模型的单一数据库的资源限制
• 使用 vCore 购买模型的弹性池的资源限制