你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
适用于：
Azure SQL 数据库
Azure SQL 数据库超大规模是一个经济高效的高性能云数据库。
Azure SQL 数据库基于 SQL 数据库引擎。 超大规模与其他Azure SQL 数据库服务层级不同：
- 与其他服务层级不同，Hyperscale 无需支付 SQL 软件许可费用，因此对于高性能数据库，它相比 Azure SQL 数据库 的其他服务层级具有显著的价格优势。
- 超大规模体系结构 是不同的：它为读取和写入提供几乎即时的备份、快速还原和高吞吐量。
- 超大规模架构可按需快速扩展计算资源，无需迁移数据。
- 读取扩展策略非常简单，支持多达 30 个命名副本，并且每个副本的计算资源都可独立配置；此外，还提供内置的高可用性副本，以及可在全球范围内配置的异地副本。
“超大规模”服务层级适用于所有工作负载类型。 “超大规模”中的计算和存储资源大大超出了Azure SQL 数据库“常规用途”和“业务关键”层中可用的资源。
可以轻松地将 Azure SQL 数据库 中的现有数据库转换到超大规模，或者从任何 SQL Server 数据库迁移到超大规模。 若要将其他数据库迁移到 Azure SQL 数据库，请参阅 Azure 数据库迁移指南。
“超大规模”服务层级目前仅适用于Azure SQL 数据库，不适用于Azure SQL 托管实例。
“超大规模”服务层级具有哪些功能
Azure SQL 数据库中的“超大规模”服务层级提供以下附加功能：
- 快速扩展 — 在需要时扩展计算资源以应对繁重负载，在不需要时再缩减计算资源。
- 快速横向扩展 - 预配一个或多个只读副本，以减轻读取工作负荷并将这些副本用作热备用服务器。
- 使用无服务器计算时，将根据使用情况自动对计算进行纵向扩展、缩减和计费。
- 使用弹性池优化了一组具有不同资源需求的超大规模数据库的价格/性能。
- 自动缩放存储，支持高达 128 TB 的数据库或 100 TB 弹性池大小。
- 无论数据卷如何，由于更高的事务日志吞吐量和更快的事务提交速度，整体性能更高。
- 快速数据库备份（基于文件快照），无论大小如何，都不会对计算资源产生 I/O 影响。
- 在几分钟内快速完成数据库还原或复制（基于文件快照），而不是需要花费数小时或数天。
“超大规模”服务层级消除了传统上云数据库中出现的许多实际限制。 当大多数其他数据库受单个节点中可用资源的限制时，“超大规模”服务层级中的数据库则没有此类限制。 它具备灵活的存储体系结构，存储可按需增长。 实际上，不会使用定义的最大大小创建“超大规模”数据库。 “超大规模”数据库会按需扩大，你仅需为所分配的存储容量付费。 对于读取密集型工作负载，“超大规模”服务层级通过按需预配其他副本来减轻读取工作负载，从而实现快速横向扩展。
此外，创建数据库备份或纵向扩展/横向扩展所需的时间不再与数据库中的数据卷相关。 几乎可以即时备份“超大规模”数据库。 还可以在几分钟内将预配的计算层中的数据库扩展或缩减至数十TB，或使用无服务器自动调整计算能力。 此功能使你无需担心受初始配置选项的约束。
有关“超大规模”服务层级计算大小的详细信息，请参阅服务层级特征。
有关基于 vCore 的购买模型中的“常规用途”服务层级和“业务关键”服务层级的详细信息，请参阅常规用途服务层级和业务关键服务层级。 有关基于 vCore 的购买模型与基于 DTU 的购买模型的比较，请参阅 Compare vCore 和基于 DTU 的购买模型Azure SQL 数据库。
哪些群体应考虑使用“超大规模”服务层级
超大规模服务层级适用于需要更高性能和可用性、快速备份和还原以及快速存储和计算可伸缩性的所有客户。 超大规模非常适合迁移到云以现代化其应用程序的客户，或者对于已在Azure SQL 数据库中使用其他服务层级的客户。 超大规模服务层级支持广泛的数据库工作负载（从纯 OLTP 到纯分析）。 它针对 OLTP 和混合事务与分析处理 (HTAP) 工作负载进行了优化。
“超大规模”定价模型
对于高性能数据库，“超大规模”为其他Azure SQL 数据库服务层级提供了显著的价格优势。 有关更多信息，请参阅博客：Ignite 2023 上发布的 Azure SQL 数据库 超大规模定价公告。 有关定价更改详细信息，请参阅博客：Azure SQL 数据库超大规模 - 更低、简化的定价！
超大规模服务层级仅在 vCore 模型中 可用，并且有两个计算层。 超大规模计费基于预配的或无服务器计算层：
预配的 计算层：
vCore 计算成本反映了为应用程序持续预配的总计算容量。 “超大规模”计算单位按副本计费。
无服务器 计算层：
无服务器计算是基于使用情况计费的。 有关详细信息，请参阅 Azure SQL 数据库 的无服务器计算层。
配置超大规模数据库时，不会指定最大数据大小。 在“超大规模”层中，根据实际分配为存储付费。 存储会自动分配 10 GB 到 128 TB，并根据需要增长。 更多信息请参见 “我的数据库规模增长了多少？
缩放和性能优势
超大规模将主数据库引擎与为数据提供长期存储和持久性的组件分开。 此体系结构允许你快速缩放计算资源，而无需移动数据，以及独立于计算缩放存储（高达 128 TB）。 有关更多详细信息，包括体系结构关系图，请参阅 “超大规模”体系结构。
- 超大规模体系结构能快速启动/关闭其他只读计算节点，拥有重要的读取扩展功能，还可以释放主计算节点，以满足更多请求。
- 你可以为二级节点配置计算，或者使用 无服务器计算。 无论哪种情况，都可以由于超大规模共享存储体系结构而快速纵向扩展或缩减它们。
- Hyperscale 中的辅助高可用计算节点副本遵循主节点的计算层级，从而实现低影响的故障转移。
- 使用无服务器计算节点时，主计算节点或辅助计算节点会根据工作负荷需求自动缩放。
主Azure SQL 数据库超大规模数据库同时处理读取和写入工作负荷，但作为应用程序策略的一部分，可以轻松创建只读副本：
- 可以根据可用性和可伸缩性要求，将 高可用性次要副本 总数从 0 调整为 4。
- 最多可以创建 30 个命名副本，以支持读取扩展工作负荷。
- 通过使用异地副本，可以在 Azure 全球数据中心之间实现异地分配的读取扩展。
“超大规模”中的数据库高可用性
与所有其他服务层级一样，“超大规模”保证已提交事务的数据持久性，而不管计算副本的可用性如何。 由于主要副本不可用而导致的停机时间取决于故障转移的类型（计划内或计划外），是否配置区域冗余，以及是否至少存在一个高可用性副本。 在计划的故障转移（如维护事件）中，系统在启动故障转移之前创建新的主副本，或使用现有的高可用性副本作为故障转移目标。 在计划外故障转移（如主要副本发生硬件故障）中，系统使用高可用性副本作为故障转移目标（如果存在），或者从可用计算容量池中创建新的主要副本。 对于后一种情况，停机持续时间更长，因为需要执行额外的步骤来创建新的主要副本。
可以选择 一个维护时段 ，使有影响力的维护事件可预测且对工作负荷造成的影响较小。
有关超大规模 SLA，请参阅 SLA for Azure SQL 数据库。
缓冲池和弹性缓冲池扩展
在Azure“数据库超大规模”中，计算和存储之间存在不同的分离。 存储包含一个数据库中的所有数据库页，并且随着数据库的增长，可以分配在多台计算机上。 但是，计算节点仅缓存最近使用的内容。 计算中的最热门页面会以一种称为缓冲池 (BP) 的结构存储在内存中。 它还存储在本地 SSD（即弹性缓冲池扩展 (RBPEX)）中，这样，如果计算进程重新启动，便可以更快地检索数据。
在云系统中，计算可以根据需要移动到不同的计算机。 计算层可以有多个副本。 一个副本是主要副本，接收所有更新，而另一个副本是次要副本。 如果主要副本失败，系统会在称为故障转移的流程中将高可用性次要副本之一提升为主要副本。 次要副本的 BP 和 RBPEX 中可能没有为主要工作负荷优化的缓存。
连续启动
持续预热是一个用于收集所有计算副本中访问频率最高（最热）的页面信息的过程。 该过程聚合此信息，高可用性次要副本使用与典型客户工作负荷对应的最热页面列表。 此流程持续用最热门页面填充 BP 和 RBPEX，以跟上客户工作负荷的变化。
如果没有持续预热，BP 和 RBPEX 都不会被新的高可用副本继承，而只会在用户工作负载运行期间重建。 连续启动可以节省时间并避免性能不一致，因为无需等待缓存再次完全冻结。 通过连续启动，新的高可用性次要副本将立即开始启动其 BP 和 RBPEX。 这将有助于在发生故障转移时使性能保持更加一致。
连续启动是双向的：高可用性次要副本将缓存主要副本中正在使用的页面，而主要副本将缓存来自次要副本工作负荷的页面。
超大规模配置计算层目前提供连续启动。
备份和还原
超大规模数据库的备份和还原操作是基于文件快照的。 此方法使这些操作几乎瞬间完成。 由于超大规模体系结构使用存储层进行备份和还原，因此减少了对计算副本的处理负担和性能影响。 有关详细信息，请参阅 “超大规模备份和存储冗余”。
超大规模数据库的灾难恢复
若要将Azure SQL 数据库中的“超大规模”数据库还原到当前托管的数据库以外的区域，请执行 geo-restore。 此方法适用于灾难恢复操作、演练、重定位或任何其他原因。 仅当选择异地冗余存储（RA-GRS）进行存储冗余时，异地还原才可用。
有关详细信息，请参阅 将超大规模数据库还原到其他区域。
比较资源限制
基于 vCore 的服务层在数据库可用性、存储类型、性能和最大存储大小方面有所不同。 下表描述了这些差异：
| ㅤ | 常规用途 | 业务关键 | 超大规模 |
|---|---|---|---|
| 最适用于 | 面向预算的均衡计算和存储选项。 | 事务率高、I/O 延迟低的 OLTP 应用程序。 通过使用多个热备副本，实现对故障的高复原能力及快速故障转移。 | 所有新的和现代化 OLTP 和 HTAP 工作负荷的推荐和默认服务层。 最适合各种工作负荷，包括具有高度可扩展存储和读取扩展要求的工作负荷。 通过允许配置多个高可用性次要副本，提供更高的故障复原能力。 |
| 计算大小 | 2 - 128 个 vCore | 2 - 128 个 vCore | 2 到 192 个 vCore3 |
| 存储类型 | 高级远程存储（每个实例） | 超快的本地 SSD 存储（每个实例） | 具有本地 SSD 缓存的分离的存储（每个计算副本） |
| 存储大小 | 1 GB - 4 TB | 1 GB - 4 TB | 10 GB - 128 TB |
| 最大 IOPS | 每个 vCore 提供 320 IOPS，最大 16,000 IOPS | 每个 vCore 提供 4,000 IOPS，最大 327,680 IOPS | 每个 vCore 支持 5,500 IOPS，最大本地 SSD 支持 544,000 IOPS。 超大规模是具有多个级别缓存的多层体系结构。 有效的 IOPS 取决于工作负荷。 |
| 内存/vCore | 5.1 GB | 5.1 GB | 5.1 GB 或 10.2 GB |
| 备份 | 可以选择本地冗余 (LRS)、区域冗余 (ZRS) 或异地冗余 (GRS) 存储 1-35 天保留期（默认为 7 天），最长提供 10 年的长期保留期 |
可以选择本地冗余 (LRS)、区域冗余 (ZRS) 或异地冗余 (GRS) 存储 1-35 天保留期（默认为 7 天），最长提供 10 年的长期保留期 |
可以选择本地冗余 (LRS)、区域冗余 (ZRS) 或异地冗余 (GRS) 存储 1-35 天保留期（默认为 7 天），最长提供 10 年的长期保留期 |
| 可用性 | 一个副本，无读取扩展副本。 区域冗余 HA | 三个副本，一个读取扩展副本。 区域冗余 HA | 多个副本，最多 4 个读取扩展副本。 区域冗余 HA |
| 定价/计费 |
vCore、保留存储和备份存储收费。 IOPS 不收费。 |
vCore、保留存储和备份存储收费。 IOPS 不收费。 |
收取每个副本 的 vCore、分配的数据存储和备份存储的费用。 IOPS 不收费。 |
| 折扣模型1 |
Azure 预留 Azure 混合权益2 企业和即用即付开发/测试套餐订阅 |
Azure 预留 Azure 混合权益2 企业和即用即付开发/测试套餐订阅 |
由于超大规模没有 SQL 软件许可证费1，因此Azure 混合权益不适用于新的超大规模数据库2。 |
| 内存中表 | 否 | 是的 | 否 |
1 从 2023 年 12 月开始，超大规模 SQL 数据库已可享受更简化的定价。 有关详情，请查看超大规模定价博客。
2 自 2023 年 12 月起，Azure 混合权益不适用于新的超大规模数据库或开发/测试订阅。 具有预配计算的现有超大规模单一数据库可以继续使用Azure 混合权益来节省计算成本，直到 2026 年 12 月。 有关详细信息，请查看超大规模定价博客。
3 目前，160 和 192 个 vCore 选项是预览功能。
计算资源
下表比较了 Azure SQL 数据库超大规模不同硬件配置和计算层中的计算资源。 有关非超大规模 Azure SQL 数据库，请参阅 vCore 购买模型 - Azure SQL 数据库。
| 硬件配置 | CPU | 内存 |
|---|---|---|
| 标准系列 (Gen5) | 预配计算 - Intel® E5-2673 v4 （Broadwell） 2.3 GHz， Intel® SP-8160（Skylake）*、Intel® 8272CL（Cascade Lake） 2.5 GHz*、Intel® Xeon® Platinum 8370C（Ice Lake）*、AMD EPYC™ 7763v（米兰）*、AMD EPYC 9004（基因a）*、Intel® Xeon® Platinum 8573C（绿绿急流）* 处理器 - 最多预配 128 个 vCore（超线程） 无服务器计算 - Intel® E5-2673 v4 （Broadwell） 2.3 GHz， Intel® SP-8160（Skylake）*、Intel® 8272CL（Cascade Lake） 2.5 GHz*、Intel® Xeon® Platinum 8370C（Ice Lake）*、AMD EPYC™ 7763v（米兰）*、AMD EPYC 9004（基因a）*、Intel® Xeon® Platinum 8573C（绿绿急流）* 处理器 - 自动缩放为 80 个 vCore（超线程） - 内存与 vCore 比率根据工作负载需求动态适应内存和 CPU 使用率，每个 vCore 可能高达 24 GB。 例如，在给定的时间点，工作负载可能使用 240 GB 内存以及仅 10 个 vCore，并依此进行计费。 |
预配计算 - 每个 vCore 5.1 GB - 最多预配 625 GB 无服务器计算 - 自动缩放到每个 vCore 24 GB - 自动缩放到最大 240 GB |
| 高级系列 | 预配计算 - Intel® Xeon® Platinum 8370C（Ice Lake）*、AMD EPYC™ 7763v（Milan）*、AMD EPYC 9004（Genoa）*、Intel® Xeon® Platinum 8573C（Emerald Rapids）* 处理器 - 支持配置至多 192 个 vCore（超线程）。 |
每个 vCore 5.2 GB |
| 高级系列内存优化 | 预配计算 - Intel® Xeon® Platinum 8370C（Ice Lake）*、AMD EPYC™ 7763v（Milan）*、AMD EPYC 9004（Genoa）*、Intel® Xeon® Platinum 8573C（Emerald Rapids）* 处理器 - 预配最多 80 个 vCore（超线程）。 |
每个 vCore 10.2 GB |
* 对于给定的计算大小和硬件配置，无论 CPU 类型（Intel® Broadwell、Skylake、Ice Lake、Cascade Lake、Green Rapid 或 AMD 米兰、吉诺亚），资源限制都是相同的。 在 sys.dm_user_db_resource_governance 动态管理视图中，数据库的硬件代数使用：
- Intel® SP-8160（Skylake）处理器被显示为 Gen6
- Intel® 8272CL （Cascade Lake）显示为第七代
- Intel® Xeon® Platinum 8370C （Ice Lake） 或 AMD EPYC™ 7763v （米兰） 显示为 Gen8
- AMD EPYC™ 9004（Genoa）显示为 Gen9 或 Intel® Xeon® Platinum 8573C（Emerald Rapids）显示为 Gen10
创建和管理超大规模数据库
可以使用Azure门户、Transact-SQL、PowerShell 和Azure CLI来创建和管理超大规模数据库。 有关详细信息，请参阅快速入门：创建超大规模数据库。
| 运算 | 详细信息 | 了解详细信息 |
|---|---|---|
| 创建“超大规模”数据库 | 超大规模数据库仅可通过基于 vCore 的购买模型使用。 | 查找在 |
| 将现有数据库转换为“超大规模” | 可以将现有数据库转换为Azure SQL 数据库“超大规模”层。 转换持续时间取决于数据的大小。 | 有关详细信息，请参阅将现有数据库转换为超大规模。 |
| 将超大规模数据库反向迁移到“常规用途”服务层级 | 如果以前将现有Azure SQL 数据库迁移到“超大规模”，可以在原始迁移到“超大规模”后的 45 天内将数据库反向迁移到“常规用途”服务层级。 如果要将数据库迁移到另一个服务层（例如业务关键），请先反向迁移到常规用途服务层级，然后更改服务层。 |
了解如何从超大规模反向迁移，包括反向迁移的限制。 |
限制
这些限制目前适用于“超大规模”服务层级。 产品团队正积极努力消除尽可能多的这些限制。
| 问题 | 说明 |
|---|---|
| 当 TDE 被禁用时，收缩被阻止 | 目前，禁用透明数据加密（TDE）时，Azure SQL 数据库“超大规模”不支持数据库和文件收缩操作。 |
| 从其他服务层级还原数据库 | 无法将非超大规模数据库还原为“超大规模”数据库。 也不能将超大规模数据库还原为非超大规模数据库。 对于从其他Azure SQL 数据库服务层级迁移到“超大规模”的数据库，预迁移备份将保留到源数据库的 备份保留期期间，包括长期保留策略。 可以通过 命令行在数据库的备份保留期内还原迁移前备份。 可以将这些备份还原到任何非超大规模服务层级。 |
| 迁移包含内存中 OLTP 对象的数据库 | 超大规模支持内存中 OLTP 对象的子集，包括内存优化表类型、表变量和本机编译模块。 但是，如果要迁移的数据库中存在任何内存中 OLTP 对象，则不支持从“高级”和“业务关键”服务层级迁移到“超大规模”。 若要将此类数据库迁移到“超大规模”，必须删除所有 In-Memory OLTP 对象及其依赖项。 迁移数据库后，可以重新创建这些对象。 超大规模目前不支持持久的和非持久的内存优化表，必须将这些表更改为为磁盘表。 |
| 数据库完整性检查 |
DBCC CHECKDB和DBCC CHECKFILEGROUP目前不受支持用于 Azure SQL 数据库 超大规模数据库。 作为变通方法，可以使用 DBCC CHECKTABLE ('TableName') WITH TABLOCK。 有关 Azure SQL 数据库 中数据完整性管理的详细信息，请参阅 Azure SQL 数据库 中的数据完整性。 |
| 弹性作业 | 不支持使用超大规模数据库作为作业数据库。 但是，弹性作业可以像Azure SQL 数据库中的任何其他数据库一样以超大规模数据库为目标。 |
| 数据同步 | 不支持将超大规模数据库用作中心或同步元数据数据库。 但是，“超大规模”数据库可以是数据同步拓扑中的成员数据库。 |
| 超大规模服务层级高级系列硬件 | 高级系列和内存优化的高级系列硬件当前不支持无服务器计算层。 无服务器仅在标准系列 (Gen5) 硬件上受支持。 |
| 区域可用性 | 超大规模服务层级高级系列和高级系列内存优化硬件在有限的Azure区域中可用。 有关列表，请参阅超大规模高级系列可用性。 |