在 vCore 服务层级中进行选择,然后从 DTU 服务层级进行迁移Choose among the vCore service tiers and migrate from the DTU service tiers

使用基于虚拟核心 (vCore) 的购买模型,可以单独缩放计算和存储资源、匹配本地性能,以及优化价格。The virtual core (vCore)-based purchasing model lets you independently scale compute and storage resources, match on-premises performance, and optimize price. 它还可让选择硬件的代系:It also lets you choose the generation of hardware:

  • 第 4 代:最多 24 个基于 Intel E5-2673 v3 (Haswell) 2.4 GHz 处理器的逻辑 CPU,vCore = 1 PP(物理核心),每个 vCore 7 GB,附加了 SSDGen4: Up to 24 logical CPUs based on Intel E5-2673 v3 (Haswell) 2.4-GHz processors, vCore = 1 PP (physical core), 7 GB per vCore, attached SSD
  • 第 5 代:最多 80 个基于 Intel E5-2673 v4 (Broadwell) 2.3-GHz 处理器的逻辑 CPU,vCore = 1 LP(超线程),每个 vCore 5.1 GB 用于预配计算,每个 vCore 最多 24 GB 用于无服务器计算,快速 eNVM SSDGen5: Up to 80 logical CPUs based on Intel E5-2673 v4 (Broadwell) 2.3-GHz processors, vCore = 1 LP (hyper-thread), 5.1 GB per vCore for provisioned compute and up to 24 GB per vCore for serverless compute, fast eNVM SSD

第 4 代为每个 vCore 提供的内存要大得多。Gen4 hardware offers substantially more memory per vCore. 但是,第 5 代硬件允许以高得多的力度纵向扩展计算资源。However, Gen5 hardware allows you to scale up compute resources much higher.

Note

有关基于 DTU 的服务层级的信息,请参阅基于 DTU 的购买模型的服务层级For information about the DTU-based service tiers, see Service tiers for the DTU-based purchasing model. 有关基于 DTU 和基于 vCore 的购买模型的服务层级之间的差异信息,请参阅 Azure SQL 数据库购买模型For information about the differences between the service tiers for the DTU-based and the vCore-based purchasing models, see Azure SQL Database purchasing models.

服务层级的特征Service-tier characteristics

基于 vCore 的购买模型提供三个服务层级:“常规用途”、“超大规模”和“业务关键”。The vCore-based purchasing model provides three service tiers: general purpose, hyperscale, and business critical. 这些服务层级根据一系列计算大小、高可用性设计、故障隔离方法、存储类型和大小以及 I/O 范围进行区分。These service tiers are differentiated by a range of compute sizes, high-availability designs, fault-isolation methods, types and sizes of storage, and I/O ranges.

必须单独配置所需的存储和备份保持期。You must separately configure the required storage and retention period for backups. 若要设置备份保留期,请打开 Azure 门户,转到服务器(而不是数据库),然后转到“管理备份” > “配置策略” > “时间点还原配置” > “7 - 35 天”。 To set the backup-retention period, open the Azure portal, go to the server (not the database), and then go to Manage Backups > Configure Policy > Point In Time Restore Configuration > 7 - 35 days.

下表解释了这三个层级之间的差别:The following table explains the differences between the three tiers:

常规用途General purpose 业务关键Business critical 超大规模Hyperscale
最适用于Best for 提供以预算导向的、均衡的计算和存储选项。Offers budget oriented balanced compute and storage options. 事务率较高、IO 延迟较低的 OLTP 应用程序。OLTP applications with high transaction rate and low IO latency. 使用多个同步更新的副本提供最高故障复原能力和快速故障转移。Offers highest resilience to failures and fast failovers using multiple synchronously updated replicas. 大多数业务工作负荷。Most business workloads. 自动缩放存储大小,最大可达 100 TB,流畅的垂直和水平计算缩放,快速数据库还原。Auto-scaling storage size up to 100 TB, fluid vertical and horizontal compute scaling, fast database restore.
计算Compute 预配计算Provisioned compute:
Gen4:1 到 24 个 vCoreGen4: 1 to 24 vCores
Gen5:2 到 80 个 vCoreGen5: 2 to 80 vCores
无服务器计算Serverless compute:
Gen5:0.5 到 16 个 vCoreGen5: 0.5 - 16 vCores
预配计算Provisioned compute:
Gen4:1 到 24 个 vCoreGen4: 1 to 24 vCores
Gen5:2 到 80 个 vCoreGen5: 2 to 80 vCores
预配计算Provisioned compute:
Gen4:1 到 24 个 vCoreGen4: 1 to 24 vCores
Gen5:2 到 80 个 vCoreGen5: 2 to 80 vCores
内存Memory 预配计算Provisioned compute:
Gen4:每个 vCore 7 GBGen4: 7 GB per vCore
Gen5:每个 vCore 5.1 GBGen5: 5.1 GB per vCore
无服务器计算Serverless compute:
Gen5:每个 vCore 最多 24 GBGen5: Up to 24 GB per vCore
预配计算Provisioned compute:
Gen4:每个 vCore 7 GBGen4: 7 GB per vCore
Gen5:每个 vCore 5.1 GBGen5: 5.1 GB per vCore
预配计算Provisioned compute:
Gen4:每个 vCore 7 GBGen4: 7 GB per vCore
Gen5:每个 vCore 5.1 GBGen5: 5.1 GB per vCore
存储Storage 使用远程存储。Uses remote storage.
单一数据库和弹性池预配计算Single database and elastic pool provisioned compute:
5 GB - 4 TB5 GB - 4 TB
无服务器计算Serverless compute:
5 GB - 3 TB5 GB - 3 TB
托管实例:32 GB - 8 TBManaged instance: 32 GB - 8 TB
使用本地 SSD 存储。Uses local SSD storage.
单一数据库和弹性池预配计算Single database and elastic pool provisioned compute:
5 GB - 4 TB5 GB - 4 TB
托管实例Managed instance:
32 GB - 4 TB32 GB - 4 TB
可以根据需要灵活地自动扩展存储。Flexible autogrow of storage as needed. 最多支持 100 TB 存储空间。Supports up to 100 TB of storage. 使用本地 SSD 存储作为本地缓冲池缓存和本地数据存储。Uses local SSD storage for local buffer-pool cache and local data storage. 使用 Azure 远程存储作为最终的长期数据存储。Uses Azure remote storage as final long-term data store.
I/O 吞吐量(近似值)I/O throughput (approximate) 单一数据库和弹性池:每个 vCore 提供 500 IOPS,最大 40000 IOPS。Single database and elastic pool: 500 IOPS per vCore up to 40000 maximum IOPS.
托管实例:取决于文件大小Managed instance: Depends on size of file.
每个核心提供 5000 IOPS,最大 200,000 IOPS5000 IOPS per core up to 200,000 maximum IOPS 超大规模是具有多个级别缓存的多层体系结构。Hyperscale is a multi-tiered architecture with caching at multiple levels. 有效 IOPs 将取决于工作负荷。Effective IOPs will depend on the workload.
可用性Availability 1 个副本,无读取缩放副本1 replica, no read-scale replicas 3 个副本,1 个读取缩放副本3 replicas, 1 read-scale replica 1 个读写副本加 0-4 个读取缩放副本1 read-write replica, plus 0-4 read-scale replicas
备份Backups 读取访问异地冗余存储 (RA-GRS),7-35 天(默认为 7 天)Read-access geo-redundant storage (RA-GRS), 7-35 days (7 days by default) RA-GRS,7-35 天(默认为 7 天)RA-GRS, 7-35 days (7 days by default) Azure 远程存储中基于快照的备份。Snapshot-based backups in Azure remote storage. 还原使用这些快照进行快速恢复。Restores use these snapshots for fast recovery. 备份瞬间完成,不会影响计算 I/O 性能。Backups are instantaneous and don't impact compute I/O performance. 还原速度很快,不基于数据操作的大小(需要几分钟,而不是几小时或几天)。Restores are fast and aren't a size-of-data operation (taking minutes rather than hours or days).
内存中In-memory 不支持Not supported 支持Supported 不支持Not supported

Azure 混合权益Azure Hybrid Benefit

在基于 vCore 的购买模型的预配计算机层级中,可以使用适用于 SQL Server 的 Azure 混合权益交换现有许可证,以获得 SQL 数据库的折扣价格。In the provisioned compute tier of the vCore-based purchasing model, you can exchange your existing licenses for discounted rates on SQL Database by using Azure Hybrid Benefit for SQL Server. 借助这项 Azure 权益,可以使用附带软件保障的本地 SQL Server 许可证,将 Azure SQL 数据库的成本最多节省 30%。This Azure benefit allows you to save up to 30 percent on Azure SQL Database by using your on-premises SQL Server licenses with Software Assurance.

定价

使用 Azure 混合权益,可以选择仅为底层 Azure 基础结构付费且将现有的 SQL Server 许可证用于 SQL 数据库引擎自身(基本计算定价),或者可以选择同时为底层基础结构和 SQL Server 许可证付费(许可证涵盖的定价)。With Azure Hybrid Benefit, you can choose to pay only for the underlying Azure infrastructure by using your existing SQL Server license for the SQL database engine itself (Base Compute pricing), or you can pay for both the underlying infrastructure and the SQL Server license (License-Included pricing).

可以使用 Azure 门户或下列 API 之一来选择或更改许可模型:You can choose or change your licensing model by using the Azure portal or by using one of the following APIs:

从基于 DTU 的模型迁移到基于 vCore 的模型Migrate from the DTU-based model to the vCore-based model

迁移数据库Migrate a database

将数据库从基于 DTU 的购买模型迁移到基于 vCore 的购买模型,与在基于 DTU 的购买模型中的标准和高级服务层级之间进行升级或降级的操作类似。Migrating a database from the DTU-based purchasing model to the vCore-based purchasing model is similar to upgrading or downgrading between the standard and premium service tiers in the DTU-based purchasing model.

从基于 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*
高级Premium 业务关键Business critical 横向Lateral 可按任意顺序迁移,但需确保 vCore 大小适当*Can migrate in any order, but need to ensure appropriate vCore sizing*
标准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

* 标准层中的每 100 个 DTU 至少需要 1 个 vCore,高级层中的每 125 个 DTU 至少需要 1 个 vCore。* Every 100 DTUs in the standard tier require at least 1 vCore, and every 125 DTUs in the premium tier require at least 1 vCore.

迁移故障转移组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 的数据库转换为基于 vCore 的数据库Use database copy to convert a DTU-based database to a vCore-based database

可将采用基于 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