“超大规模”服务层级
适用于：
Azure SQL 数据库
Azure SQL 数据库基于 SQL Server 数据库引擎体系结构，该体系结构已根据云环境做出调整，以确保即使在发生基础结构故障时，也仍能提供高可用性。 Azure SQL 数据库的 vCore 购买模型中有三个服务层级选项：
- 常规用途
- 业务关键
- 超大规模
“超大规模”服务层级适用于所有工作负载类型。 其云原生体系结构提供独立、可缩放的计算和存储，以支持最广泛的传统和现代应用程序。 超大规模中的计算和存储资源远远超过了“常规用途”和“业务关键”层级中可用的资源。
注意
- 有关基于 vCore 的购买模型中的“常规用途”服务层级和“业务关键”服务层级的详细信息，请参阅常规用途服务层级和业务关键服务层级。 有关基于 vCore 的购买模型与基于 DTU 的购买模型的比较，请参阅比较基于 vCore 和基于 DTU 的 Azure SQL 数据库购买模型。
- “超大规模”服务层级目前仅可用于 Azure SQL 数据库，不可用于 Azure SQL 托管实例。
“超大规模”服务层级具有哪些功能
Azure SQL 数据库中的“超大规模”服务层级提供了以下附加功能：
- 快速纵向扩展 - 可在不变的时间内纵向扩展计算资源，以在需要时应对繁重的工作负载，然后在不需要时重新纵向缩减计算资源。
- 快速横向扩展 - 可预配一个或多个只读副本，以减轻读取工作负载并将这些副本用作热备用服务器。
- 使用无服务器计算时，将根据使用情况自动对计算进行纵向扩展、缩减和计费。
- 自动缩放存储，支持高达 100TB 的数据库大小。
- 无论数据卷如何，由于更高的事务日志吞吐量和更快的事务提交速度，整体性能更高。
- 快速数据库备份（基于文件快照），无论大小如何，都不会对计算资源产生 I/O 影响。
- 在几分钟内快速完成数据库还原或复制（基于文件快照），而不是需要花费数小时或数天。
“超大规模”服务层级消除了传统上云数据库中出现的许多实际限制。 当大多数其他数据库受单个节点中可用资源的限制时，“超大规模”服务层级中的数据库则没有此类限制。 它具备灵活的存储体系结构，存储可按需增长。 实际上，不会使用定义的最大大小创建“超大规模”数据库。 “超大规模”数据库会按需扩大，你仅需为所分配的存储容量付费。 对于读取密集型工作负载，“超大规模”服务层级通过按需预配其他副本来减轻读取工作负载，从而实现快速横向扩展。
此外，创建数据库备份或纵向扩展/横向扩展所需的时间不再与数据库中的数据卷相关。 几乎可以即时备份“超大规模”数据库。 还可以在几分钟内在预配的计算层中纵向扩展或缩减数十 TB 的数据库，或使用无服务器自动缩放计算。 此功能使你无需担心受初始配置选项的约束。
有关“超大规模”服务层级计算大小的详细信息，请参阅服务层级特征。
哪些群体应考虑使用“超大规模”服务层级
超大规模服务层级适用于需要更高性能和高可用性、快速备份和还原和/或快速存储和计算可伸缩性的所有客户。 这包括迁移到云以对其应用程序进行现代化的客户以及已经在 Azure SQL 数据库中使用其他服务层级的客户。 超大规模服务层级支持广泛的数据库工作负载（从纯 OLTP 到纯分析）。 它针对 OLTP 和混合事务与分析处理 (HTAP) 工作负载进行了优化。
重要
弹性池不支持“超大规模”服务层级。
“超大规模”定价模型
注意
超大规模 Azure SQL 数据库享受的简化定价已经到来！ 查看 Azure SQL 数据库超大规模公告的新定价层，有关定价更改的详细信息，请参阅 Azure SQL 数据库超大规模 - 更低、更简单的定价！。
仅 vCore 模型提供“超大规模”服务层级。 为了适应新的体系结构，它的定价模型与“常规用途”或“业务关键”服务层级略有不同：
预配计算：
“超大规模”计算单位按副本计费。 用户可以根据可用性和可伸缩性要求，将高可用性次要副本总数从 0 调整到 4，并且最多可创建 30 个命名副本来支持各种读取横向扩展工作负载。
无服务器计算
无服务器计算是基于使用情况计费的。 有关详细信息，请参阅 Azure SQL 数据库的无服务器计算层级。
存储：
配置“超大规模”数据库时，无需指定最大数据大小。 超大规模层级中根据实际分配收取数据库存储费用。 存储将在 10GB 和 100TB 之间自动分配，并根据需要以 10GB 的增量增长。
有关“超大规模”服务层级定价的详细信息，请参阅 Azure SQL 数据库定价
比较资源限制
根据数据库可用性、存储类型性能和最大存储大小区分基于 vCore 的服务层级。 下表说明了这些差异：
| 常规用途 | 业务关键 | 超大规模 | |
|---|---|---|---|
| 最适用于 | 提供以预算为导向的平衡计算和存储选项。 | 事务率高、I/O 延迟低的 OLTP 应用程序。 使用多个热备用服务器副本提供较高的故障复原能力和快速故障转移。 | 最广泛的工作负载。 自动缩放存储大小，最大可达 100 TB，快速的垂直和水平计算缩放，快速数据库还原。 |
| 计算大小 | 2 到 80 个 vCore | 2 到 80 个 vCore | 2 到 80 个 vCore1 |
| 存储类型 | 高级远程存储（每个实例） | 超快的本地 SSD 存储（每个实例） | 具有本地 SSD 缓存的分离的存储（每个计算副本） |
| 存储大小1 | 1 GB - 4 TB | 1 GB - 4 TB | 10 GB - 100 TB |
| IOPS | 最大 12,800 IOPS | 最大 204,800 IOPS | 204,800 IOPS（具有最大本地 SSD） 超大规模是具有多个级别缓存的多层体系结构。 有效 IOPS 将取决于工作负荷。 |
| 内存/vCore | 5.1 GB | 5.1 GB | 5.1 GB |
| 可用性 | 一个副本，没有读取扩展，区域冗余 HA | 三个副本，一个读取扩展，区域冗余 HA | 多个副本，多达 4 个读取扩展，区域冗余 HA |
| 备份 | 可以选择本地冗余 (LRS)、区域冗余 (ZRS) 或异地冗余 (GRS) 存储 1-35 天（默认值为七天）的保留期，最长的长期保留期为 10 年 |
可以选择本地冗余 (LRS)、区域冗余 (ZRS) 或异地冗余 (GRS) 存储 1-35 天（默认值为七天）的保留期，最长的长期保留期为 10 年 |
可以选择本地冗余 (LRS)、区域冗余 (ZRS) 或异地冗余 (GRS) 存储 1-35 天（默认值为七天）的保留期，最长的长期保留期为 10 年 |
| 定价/计费 | vCore、保留存储和备份存储收费。 IOPS 不收费。 |
vCore、保留存储和备份存储收费。 IOPS 不收费。 |
收取每个副本 的 vCore、分配的数据存储和备份存储的费用。 IOPS 不收费。 |
| 折扣模型2 | Azure 混合权益3 企业和即用即付开发/测试订阅 |
Azure 混合权益3 企业和即用即付开发/测试订阅 |
Azure 混合权益3 企业和即用即付开发/测试订阅 |
1 “超大规模”服务层级不支持弹性池。
2 从 2023 年 12 月开始，超大规模 SQL 数据库已可享受更简化的定价。 有关详情，请查看超大规模定价博客。
3 从 2023 年 12 月开始，Azure 混合权益将不适用于新的超大规模数据库或开发/测试订阅。 在 2026 年 12 月之前，具有预配计算的现有超大规模单一数据库可以继续使用Azure 混合权益，以节省计算成本。 有关详细信息，请查看超大规模定价博客。
计算资源
| 硬件配置 | CPU | 内存 |
|---|---|---|
| 标准系列 (Gen5) | 预配计算 - Intel® E5-2673 v4 (Broadwell) 2.3 GHz、Intel® SP-8160 (Skylake)1，Intel® 8272CL (Cascade Lake) 2.5 GHz1，Intel® Xeon® Platinum 8370C (Ice Lake)1，AMD EPYC 7763v (Milan) 处理器 - 预配最多 80 个 vCore（超线程） 无服务器计算 - Intel® E5-2673 v4 (Broadwell) 2.3 GHz、Intel® SP-8160 (Skylake)1，Intel® 8272CL (Cascade Lake) 2.5 GHz1，Intel® Xeon® Platinum 8370C (Ice Lake)1，AMD EPYC 7763v (Milan) 处理器 - 自动缩放为 80 个 vCore（超线程） - 内存与 vCore 比率根据工作负荷需求动态适应内存和 CPU 使用率，每个 vCore 的内存可能高达 12 GB。 例如，在给定的时间点，工作负荷可能使用 120 GB 内存以及仅 5 个 vCore，并依此进行计费。 |
预配计算 - 每个 vCore 5.1 GB - 最多预配 415 GB 无服务器计算 - 自动缩放为每个 vCore 24 GB - 自动缩放到最大 120GB |
1 在 sys.dm_user_db_resource_governance 动态管理视图中，使用 Intel® SP-8160 (Skylake) 处理器的数据库的硬件代系会显示为 Gen6，使用 Intel® 8272CL (Cascade Lake) 的数据库的硬件代系会显示为 Gen7，使用 Intel® Xeon® Platinum 8370C (Ice Lake) 或 AMD® EPYC® 7763v (Milan) 的数据库的硬件代系会显示为 Gen8。 对于给定的计算大小和硬件配置，无论 CPU 类型是什么，资源限制都是相同的。 有关详细信息，请参阅单一数据库和弹性池的资源限制。
无服务器仅在标准系列（第 5 代）硬件上受支持。
分布式功能体系结构
超大规模将查询处理引擎与为数据提供长期存储和持久性的组件分隔开来。 这种体系结构允许你按需平滑扩展存储容量（初始目标为 100 TB），并快速扩展计算资源。
下图说明了功能性超大规模体系结构：
详细了解超大规模分布式功能体系结构。
缩放和性能优势
超大规模体系结构能快速启动/关闭其他只读计算节点，拥有重要的读取扩展功能，还可以释放主计算节点，以满足更多写入请求。 此外，由于超大规模体系结构的共享存储体系结构，可快速纵向扩展/横向扩展计算节点。 超大规模中的只读计算节点也可以在无服务器计算层中使用，根据工作负载需求自动缩放计算量。
创建和管理超大规模数据库
可以使用 Azure 门户、Transact-SQL、PowerShell 和 Azure CLI 创建和管理超大规模数据库。 有关详细信息，请参阅快速入门：创建超大规模数据库。
| 操作 | 详细信息 | 了解详细信息 |
|---|---|---|
| 创建“超大规模”数据库 | 仅可通过基于 vCore 的购买模型使用超大规模数据库。 | 在快速入门：在 Azure SQL 数据库中创建超大规模数据库中查找用于创建超大规模数据库的示例。 |
| 将现有数据库升级到超大规模 | 将 Azure SQL 数据库中的现有数据库迁移到“超大规模”层级是与数据大小相关的操作。 | 了解如何将现有数据库迁移到超大规模。 |
| 将超大规模数据库反向迁移到“常规用途”服务层级 | 如果先前已将现有的 Azure SQL 数据库迁移到“超大规模”服务层级，可以在最初迁移到“超大规模”服务层级后的 45 天内，将数据库反向迁移到“常规用途”服务层级。 如果要将数据库迁移到另一个服务层级（例如“业务关键”），请先反向迁移到“常规用途”服务层级，然后更改服务层级。 |
了解如何从超大规模反向迁移，包括反向迁移的限制。 |
“超大规模”中的数据库高可用性
与所有其他服务层级一样，“超大规模”保证已提交事务的数据持久性，而不管计算副本的可用性如何。 由于主要副本不可用而导致的停机时间取决于故障转移的类型（计划内或计划外），是否配置区域冗余，以及是否至少存在一个高可用性副本。 在计划内故障转移（如维护事件）中，系统要么在启动故障转移之前创建新的主要副本，要么使用现有的高可用性副本作为故障转移目标。 在计划外故障转移（如主要副本发生硬件故障）中，系统使用高可用性副本作为故障转移目标（如果存在），或者从可用计算容量池中创建新的主要副本。 对于后一种情况，停机持续时间更长，因为需要执行额外的步骤来创建新的主要副本。
你可以选择一个维护时段，使有影响的维护事件可预测，并减少对工作负载的干扰。
有关“超大规模”SLA，请参阅 Azure SQL 数据库的 SLA。
备份和还原
超大规模数据库的备份和还原操作是基于文件快照的。 这使这些操作几乎可以即时完成。 由于超大规模体系结构利用存储层进行备份和还原，因此大大减少了计算副本的处理负担和性能影响。 有关详细信息，请参阅超大规模备份和存储冗余。
超大规模数据库的灾难恢复
如果在执行灾难恢复操作或演练、重新定位期间或者出于任何其他原因，需要将 Azure SQL 数据库中的某个超大规模数据库还原到其他位置（而不是其当前所在位置），主要方法是执行数据库的异地还原。 只有在为存储冗余选择了异地冗余存储 (RA-GRS) 时，异地还原才可用。
有关详细信息，请参阅将超大规模数据库还原到其他区域.
已知的限制
下面是“超大规模”服务层级的当前限制。 我们正在尽一切努力消除其中的许多限制。
| 问题 | 说明 |
|---|---|
| 从其他服务层级还原数据库 | 无法将非超大规模数据库还原到超大规模数据库，也无法将超大规模数据库还原到非超大规模数据库。 对于从其他 Azure SQL 数据库服务层级迁移到超大规模的数据库，预迁移备份（包括长期备份策略）会在源数据库的备份保持期持续时间内保留。 通过命令行支持在数据库的备份保持期内恢复迁移前备份。 可以将这些备份还原到任何非超大规模服务层级。 |
| 弹性池 | 超大规模目前不支持弹性池。 |
| 迁移包含内存中 OLTP 对象的数据库 | 超大规模支持内存中 OLTP 对象的子集，包括内存优化表类型、表变量和本机编译模块。 但是，如果要迁移的数据库中存在任何内存中 OLTP 对象，则不支持从“高级”和“业务关键”服务层级迁移到“超大规模”。 若要将此类数据库迁移到“超大规模”，必须删除所有内存中 OLTP 对象及其依赖项。 迁移数据库之后，可以重新创建这些对象。 超大规模目前不支持持久的和非持久的内存优化表，必须将这些表更改为为磁盘表。 |
| 收缩数据库 | 超大规模数据库目前不支持 DBCC SHRINKDATABASE、DBCC SHRINKFILE 或在数据库级别将 AUTO_SHRINK 设置为 ON。 |
| 数据库完整性检查 | “超大规模”数据库目前不支持 DBCC CHECKDB。 DBCC CHECKTABLE ('TableName') WITH TABLOCK 和 DBCC CHECKFILEGROUP WITH TABLOCK 可以用作解决方法。 有关 Azure SQL 数据库中数据完整性管理的详细信息，请参阅 Azure SQL 数据库中的数据完整性。 |
| 弹性作业 | 不支持使用超大规模数据库作为作业数据库。 但是，弹性作业可将超大规模数据库用作目标，就如同将 Azure SQL 数据库中的任何其他数据库用作目标一样。 |
| 数据同步 | 不支持将超大规模数据库用作中心或同步元数据数据库。 但是，超大规模数据库可以是数据同步拓扑中的成员数据库。 |