Azure SQL 数据库“超大规模”常见问题解答

超大规模数据库是 SQL 数据库中的数据库，由超大规模横向扩展存储技术提供支持。 一个“超大规模”数据库支持最多 100 TB 的数据，提供高吞吐量和高性能，可以快速缩放以适应工作负荷要求。 连接、查询处理、数据库引擎功能等功能的工作原理与 Azure SQL 数据库中的其他任何数据库一样。

“超大规模”服务层级仅适用于在 Azure SQL 数据库中使用基于 vCore 的购买模型的单一数据库。 它在基于 DTU 的购买模型中不可用。

根据资源限制比较中所述的数据库可用性、存储类型性能和最大存储大小区分基于 vCore 的服务层级。

超大规模服务层级适用于希望获得高性能和高可用性、快速备份和还原、快速存储和计算可伸缩性的所有客户。 这包括从小型开始并不断增长的客户、运行大型任务关键型数据库的客户、转向云以实现应用程序现代化的客户以及已经在 Azure SQL 数据库中使用其他服务层级的客户。 使用“超大规模”服务层级，可以：

• 数据库大小可以从 10 GB 增长到 100 TB。
• 计算从 2 个 vCore 到 128 个 vCore 的 vCore 资源
• 快速进行数据库备份，无需考虑数据库大小（备份基于存储快照）。
• 快速进行数据库还原，无需考虑数据库大小（从存储快照还原）。
• 无论数据库大小和 vCore 数目如何，都可提高日志吞吐量。
• 使用一个或多个只读副本的读取扩展，用于卸载只读工作负载，或用作热备用服务器数据库。
• 在恒定时间内快速纵向扩展计算，以便提高适应繁重工作负荷的能力；然后在恒定时间内纵向缩减。 无论数据库大小如何，对于预配计算，缩放操作只需要几分钟时间；对于无服务器计算，缩放操作需要不到一秒钟的时间。
• 用于支付用于无服务器计算的内容的选项，其中计算是根据使用情况进行计费的。

“超大规模”服务层级在提供 Azure SQL 数据库的所有区域中都可用。

是的。 有关每个服务器的数据库数量的详细信息和限制，请参阅服务器上单一和共用数据库的 SQL 数据库资源限制。

“超大规模”体系结构提供高性能和吞吐量，同时支持大型数据库。

“超大规模”根据工作负荷需求，提供快速的可伸缩性。

• 增加/减少

  使用“超大规模”数据库，可以纵向扩展按 CPU、内存等资源来衡量的主要计算大小，然后在恒定的时间内将其减少。 因为是远程存储，所以纵向扩展和缩减不是数据大小操作。

  对无服务器计算的支持提供自动纵向扩展和缩减功能，并且根据使用情况对计算进行计费。

• 缩小/扩大

  借助超大规模，可以使用三种次要副本来满足读取扩展、高可用性和异地复制要求。 这包括：

  • 最多四个高可用性副本的计算大小与主副本的计算大小相同。 这些副本用作热备用服务器副本，以快速从主要副本进行故障转移。 你还可以使用这些副本从主副本中卸载读取工作负载。
  • 最多 30 个命名副本的计算大小与主要副本的计算大小相同或不同，以满足各种读取扩展场景的需求。
  • 其他 Azure 区域中的异地复制副本，用于防止区域中断和启用地理读取扩展。

可以。

否，对于其他任何 MSSQL 数据库，应用程序编程模型保持不变。 可以照常使用连接字符串和其他常规方式，以与“超大规模”数据库进行交互。 应用程序使用超大规模数据库后，它将可以利用次要副本等功能。

在主要副本上，默认的事务隔离级别为 RCSI（已提交读快照隔离）。 在读取扩展次要副本上，默认隔离级别为“快照”。 这与在其他任何 Azure SQL 数据库中相同。

自 2023 年 12 月 15 日起，新的简化定价生效后，新创建的超大规模数据库、所有无服务器超大规模数据库和所有超大规模弹性池的计算价格都已降低。 使用新的简化定价，无需应用 Azure 混合权益 (AHB) 即可获取同等的节省。 Azure 混合权益 (AHB) 只能应用于具有预配计算的较旧（2023 年 12 月 15 日之前创建）超大规模单一数据库。 对于那些较旧的数据库，AHB 仅适用到 2026 年 12 月，之后这些数据库也将按照新的简化定价进行计费。 有关详细信息，请参阅超大规模定价博客和 Azure SQL 数据库超大规模 - 更低、更简单的定价！。

超大规模支持所有工作负荷类型，其中包括 OLTP、混合 (HTAP) 和分析（数据市场）工作负荷。

如果目前运行的是使用 SQL Server 作为数据仓库的交互式分析查询，“超大规模”是很好的选择，因为能以较低费用托管中小型数据仓库（例如几 TB 到 100 TB），并且只需对 T-SQL 代码进行极少量的更改，即可将 SQL Server 数据仓库工作负载迁移到“超大规模”。

如果正在大规模运行包含复杂查询且持续引入速率超过 100 MB/s 的数据分析，或者正在使用 Parallel Data Warehouse (PDW)、Teradata 或其他大规模并行处理 (MPP) 数据仓库，则 Azure Synapse Analytics 或 Microsoft Fabric 可能是最佳选择。

目前没有。 但是，可以纵向缩减计算和副本数，以在非高峰时段降低成本，或者使用无服务器根据使用情况自动缩放计算。

对于读取工作负载，可以创建计算大小高于主副本计算大小（更多内核和内存）的命名副本。 有关可用计算大小的详细信息，请参阅超大规模存储和计算大小。

对于读取工作负载，使用命名副本可以实现此操作。

可以使用 Azure 门户或 REST API 将 HA 次要副本的数目缩放为 0 到 4 个。 此外，可以为大量读取扩展方案创建多达 30 个的命名副本。

在超大规模数据库中，数据复原能力是在存储级别提供的。 只需一个副本（主副本）即可提供复原能力。 计算副本关闭后，系统自动创建一个新副本，且不会丢失数据。

但是，如果只有主要副本，则故障转移后可能需要一两分钟才能创建新副本，而在 HA 次要副本可用的情况下则需要几秒钟。 新副本最初将具有冷缓存，这可能会导致存储延迟更高并导致故障转移后查询性能立即降低。

对于需要高可用性且故障转移影响最小的任务关键应用，应至少预配一个 HA 次要副本，以确保有一个热备用副本可用作故障转移目标。

100 TB。

在超大规模计算层中，事务日志实际上是无限的，限制是日志的活动部分不能超过 1TB。 日志的活动部分增长的原因可能是长时间运行的事务，或者是更改数据捕获处理无法跟上数据更改的速度。 避免不必要的长时间运行的大型事务，这样就不会超出此限制。 除这个限制外，你不需要担心在日志吞吐量高的系统上耗尽日志空间。 但是，可能为连续主动写入工作负荷限制日志生成速率。 峰值持续日志生成速率为 100 MB/秒。

tempdb 数据库位于本地 SSD 存储，其大小与预配的计算大小（内核数）成比例。 tempdb 的大小不可配置，并且由你管理。 若要确定数据库的 tempdb 大小上限，请参阅超大规模存储和计算大小。

你的数据库会随着你插入/引入更多数据自动增长。

10 GB。 超大规模数据库的创建初始大小为 10GB，并根据需要以 10GB 区块的增量增长。

每个数据文件以 10 GB 增量增长。 多个数据文件可能会同时增长。

在“超大规模”数据库中，数据文件存储在 Azure 标准存储中。 数据完全缓存在本地 SSD 存储中远离计算副本的页面服务器上。 此外，计算副本在本地 SSD 和内存中均有数据缓存，以便降低从远程页面服务器提取数据的频率。

否。 数据文件会自动添加到 PRIMARY 文件组。 创建其他文件组的常见原因不适用于超大规模存储体系结构或更广泛的 Azure SQL 数据库。

否。

是的，数据库和文件收缩操作目前以预览版提供。 有关预览版的详细信息，请参阅超大规模 Azure SQL 数据库的收缩。

是，与在其他任何 Azure SQL DB 数据库中相同。 其中包括行、页和列存储压缩。

是的。 与给定表格关联的数据页可在多个数据文件中出现，它们均属于相同文件组。 MSSQL 数据库引擎使用按比例填充策略在数据文件间分布数据。

是的。 可以将 Azure SQL 数据库中的现有数据库迁移到“超大规模”服务层级。 对于概念证明 (POC)，我们建议创建数据库的副本，并将副本迁移到“超大规模”。

将现有数据库移动到超大规模所需的时间包含复制数据所需的时间以及在复制数据期间重播在源数据库中进行的更改所需的时间。 数据复制时间与数据大小成正比。 如果移动在写入活动较少的时间段内进行，则重播更改所需的时间会较短。

在将现有数据库迁移到“超大规模”服务层级中获取用于在 Azure 门户、Azure CLI、PowerShell 和 Transact-SQL 中将现有 Azure SQL 数据库迁移到“超大规模”服务层级的示例代码。

通过反向迁移到“常规用途”服务层级，最近将 Azure SQL 数据库中的现有数据库迁移到“超大规模”服务层级的客户可以迁移回来，前提是超大规模无法满足他们的需求。 虽然反向迁移是由服务层级更改发起的，但它本质上是不同体系结构之间的数据规模的操作。 与迁移到超大规模类似，如果在写入活动较少的时间段内进行反向迁移，速度会更快。 了解反向迁移的限制。

如果先前已将现有的 Azure SQL 数据库迁移到“超大规模”服务层级，可以在最初迁移到“超大规模”服务层级后的 45 天内，将其反向迁移到“常规用途”服务层级。 如果要将数据库迁移到另一个服务层级（例如“业务关键”），请先反向迁移到“常规用途”服务层级，然后修改服务层级。 反向迁移涉及到一定规模的数据操作。

无法将“超大规模”服务层级中创建的数据库迁移到其他服务层级。

了解如何从超大规模反向迁移，包括反向迁移的限制和受影响的备份策略。

是的。 超大规模尚不支持部分 Azure SQL 数据库功能。 如果为数据库启用其中部分功能，则可能会阻止迁移到超大规模，或者这些功能将在迁移后停止运作。 我们预期这些限制是暂时性的。 有关详细信息，请参阅已知限制。

是的。 可以使用大量现有的迁移技术迁移到“超大规模”，包括事务复制，以及任何其他数据移动技术（批量复制、Azure 数据工厂、Azure Databricks、SSIS）。 另请参阅支持许多迁移方案的 Azure 数据库迁移服务。

迁移到“超大规模”造成的停机时间与将数据库迁移到其他 Azure SQL 数据库服务层级造成的停机时间相同。 可以使用事务复制尽量减少大小最多几 TB 的数据库的故障时间迁移。 对于非常大的数据库（10 TB 以上），可以考虑使用 ADF、Spark 或其他批量数据移动技术实现迁移流程。

“超大规模”每秒能够使用 100 MB 的新数据/更改的数据，但将数据移入 Azure SQL 数据库中的数据库所需的时间也会受到可用网络吞吐量、源读取速度和目标数据库服务级别目标的影响。

可让客户端应用程序从 Azure 存储中读取数据并将数据加载到“超大规模”数据库（就像对 Azure SQL 数据库中的任何其他数据库执行的操作一样）。 Azure SQL 数据库当前不支持 Polybase。 作为提供快速加载的替代方法，你可以使用 Azure 数据工厂，或通过适用于 SQL 的 Spark 连接器在 Azure Databricks 中使用 Spark 作业。 SQL 的 Spark 连接器支持批量插入。

还可以使用 BULK INSERT 或 OPENROWSET 从 Azure Blob 存储批量读取数据：批量访问 Azure Blob 存储中的数据的示例。

“超大规模”数据库中不支持简单恢复或批量日志记录模式。 提供高可用性和时点恢复需要完整恢复模式。 但是，相比于其他 Azure SQL 数据库服务层级而言，“超大规模”日志体系结构提供更佳的数据引入速率。

不是。 “超大规模”是对称多处理 (SMP) 体系结构，而不是大规模并行处理 (MPP) 或多主数据库体系结构。 只能创建多个副本来横向扩展只读工作负荷。

是的。 Azure 数据库迁移服务支持许多迁移方案。

请参阅 Azure SQL 数据库的 SLA。 建议为关键工作负载添加 HA 次要副本。 这可实现快速故障转移，并立即降低故障转移后的潜在性能影响。

是的。

是的，超大规模支持区域冗余配置。 为超大规模启用区域冗余配置至少需要 1 个 HA 次要副本并使用区域冗余或异地区域冗余存储。

是的。 超大规模弹性池当前处于预览状态。

对于超大规模数据库，没有传统的完整、差异和事务日志备份。 但有数据文件的定期存储快照，每个文件都有单独的快照节奏。 生成的事务日志会按原样保留，时长为配置的保留期。 在还原时，相关事务日志记录将应用于还原的存储快照。 无论快照节奏如何，这都会让数据库处于事务一致状态，使其在保留期内的指定时间点前不丢失任何数据。 实际上，超大规模中的数据库备份是连续的。

是的。

时间点还原的 RPO 为 0 分钟。 无论数据库大小如何，大多数时间点还原操作都在 60 分钟内完成。 对于较大的数据库，如果该数据库在还原时间点之前（直到还原时间点）进行了大量写入活动，则还原时间可能会更长。 发出还原时更改存储冗余可能会导致还原时间更长，因为还原是数据大小，因此时间将与数据库大小成正比。

不是。 备份由存储子系统管理，并使用存储快照。 它们不会影响用户工作负荷。

是的。 如果使用异地冗余存储，则完全支持异地还原。 这是新数据库的默认设置。 与时间点还原不同，异地还原需要数据大小操作。 将并行复制数据文件，因此此操作的持续时间主要取决于数据库中最大文件的大小，而不是数据库总大小。 如果将数据库还原到与源数据库的区域配对的 Azure 区域中，则异地还原时间会明显缩短。

是的。 可以为超大规模数据库设置异地复制。

否。 “超大规模”数据库的存储格式不同于任何 SQL Server 发行版，你不控制备份且无权访问备份。 要将数据移出超大规模数据库，可以使用任何数据移动技术（即 Azure 数据工厂、Azure Databricks、SSIS 等）提取数据。

是的。 自 2022 年 5 月 4 日起，所有新数据库的备份将根据使用的备份存储和选择的存储冗余按 Azure SQL 数据库定价页面中的费率收费。 对于 2022 年 5 月 4 日之前创建的超大规模数据库，仅当备份保留期设置为大于七天时，才会对备份收费。 有关详细信息，请参阅超大规模备份和存储冗余。

自动备份中详细介绍了如何测量备份存储大小。

为确定备份存储费用，请定期计算备份存储大小，并乘以备份存储速率和距上次计算的小时数。 若要估算某个时间段的备份费用，请将该时间段内每小时的可计费备份存储大小乘以备份存储费率，然后将所有小时的金额加总。 若要以编程方式查询多个一小时内的相关 Azure Monitor 指标，请使用 Azure Monitor REST API。 无服务器计算层级中的备份计费与预配计算层级中的备份计费相同。

在数据库中添加、修改或删除大量数据的工作负载的备份成本更高。 相反，主要进行只读的工作负载的备份成本可能较低。

自动备份中详细介绍了如何最大限度地降低备份存储成本。

对于任何“超大规模”计算大小，事务日志吞吐量上限设置为 100 MB/秒。 实现此速率的能力取决于多种因素，包括但不限于工作负载类型、客户端配置和性能以及在主要计算副本上是否有足够的计算容量以此速率生成日志记录。

IOPS 和 IO 延迟根据工作负荷模式而异。 如果正在访问的数据缓存在计算副本上的 RBPEX 中，你将会看到与“业务关键”层级或“高级服务”层级类似的 IO 性能。

否。 计算节点与存储层分离。 这消除了备份对性能的影响。

由于存储是共享的，并且主要计算副本和次要计算副本之间没有发生直接物理复制，因此添加次要副本不会直接影响主要副本的吞吐量。 但可能会在主要副本上限制连续和激进的写入工作负载，以便将日志应用到次要副本和页面服务器上。 这可避免次要副本的读取性能不佳以及故障转移到 HA 次要副本后恢复时间过长。

是的。 但就像在其他 Azure SQL DB 数据库中一样，连接可能会因非常罕见的瞬态错误而终止，从而可能会中止长时间运行的查询并回退事务。 暂时性错误的其中一个原因是系统将数据库快速转移到不同的计算节点，以确保持续计算和存储资源可用性，或执行计划内维护。 其中的大多数重新配置事件在 10 秒内就能完成。 应通过实现重试逻辑，将连接到数据库的应用程序构建为能够预计并容许这些罕见的暂时性错误。 此外，请考虑配置一个符合工作负载日程安排的维护时段，以避免因计划内维护而发生暂时性错误。

对于大多数性能问题，尤其是根本原因与存储无关的性能问题，可以采取常用的 SQL 诊断和故障排除步骤。 有关特定于“超大规模”的存储诊断，请参阅 SQL 超大规模服务层级性能故障排除诊断。

无服务器数据库可以纵向扩展的最大内存容量为 3 GB/vCore 乘以配置的最大 vCore 数，而预配计算中内存容量则超过 5 GB/vCore 乘以相同的 vCore 数。 有关详细信息，请查看无服务器超大规模资源限制。

无论数据大小如何，在预配计算层级中纵向扩展或缩减都需要长达 2 分钟时间。 在无服务器计算层级中，计算会根据工作负荷需求自动缩放，缩放时间通常为亚秒级，但有时可能需要与缩放预配计算一样长的时间。

否。 在纵向扩展或纵向缩减操作期间，数据库保持脱机状态。

如果在缩放操作结束时发生故障转移，纵向扩展或缩减预配计算会导致连接断开。 在无服务器计算中，自动缩放通常不会导致连接断开，但偶尔也可能发生这种情况。 添加或删除次要副本不会导致主副本上的连接中断。

预配计算中的缩放由最终用户执行。 无服务器计算中的自动缩放由服务执行。

是的。 随着内核数量的增加，计算节点上的 tempdb 数据库和 RBPEX 缓存大小将自动增加。 有关详细信息，请参阅超大规模存储和计算大小。

否。 只有主要计算副本接受读/写请求。 次要计算副本只接受只读请求。

超大规模支持高可用性 (HA) 副本、命名副本和异地副本。 有关详细信息，请参阅超大规模次要副本。

介于 0 和 4 之间。 若要调整副本数目，可以使用 Azure 门户或 REST API。

通过将连接字符串中的 ApplicationIntent 属性设置为 ReadOnly，即可连接到这些额外的只读计算副本。 任何标记为 ReadOnly 的连接都会自动路由到其中一个 HA 次要副本（如果存在）。 有关详细信息，请参阅使用只读副本卸载只读的查询工作负载。

可执行以下 T-SQL 查询：SELECT DATABASEPROPERTYEX ('<database_name>', 'Updateability')。 如果已连接到只读辅助副本，则结果为 READ_ONLY；如果已连接到主要副本，则结果为 READ_WRITE。 必须将数据库上下文设置为你的数据库的名称，而不能设置为 master 数据库的名称。

不是。 只能通过指定 ApplicationIntent=ReadOnly 连接到 HA 次要副本。 但是，可以对命名副本使用专用终结点。

否。 具有只读意向的新连接将重定向到任意 HA 次要副本。

不在预配计算层级中。 HA 次要副本用作高可用性故障转移目标，因此它们的配置需要与主要副本相同，才能在故障转移后提供预期的性能。 在无服务器中，根据每个 HA 副本的单个工作负荷需求自动缩放计算。 每个 HA 次要副本仍可自动缩放到配置的最大核心数，以适应其故障转移后的角色。 命名副本提供独立缩放每个副本的能力。

不是。 tempdb 数据库根据预配的计算大小进行配置，HA 次要副本的大小（包括 tempdb）与主要计算副本相同。 在命名副本中，tempdb 的大小根据副本的计算大小进行了调整，因此可能不同于主副本中 tempdb 的大小。

否。 超大规模数据库计算副本共享存储，这表示所有计算副本会看到相同的表格、索引和其他数据库对象。 如果要使次要副本上的额外索引得到读取优化，必须在主要副本上添加索引。 你仍可以在每个次要副本上创建临时表（表名称前缀为 # 或 ##），用于存储临时数据。 临时表是可读写的。

从在主要副本上提交事务的时间开始算起，到该事务在次要副本上可读的时间为止，数据延迟取决于当前日志生成速率、事务大小、副本上的负载以及其他因素。 小型事务的典型数据延迟为数十毫秒，但数据延迟没有上限。 给定次要副本上的数据始终是事务一致的，因此事务越大所需传播时间越长。 但在给定的时间点，不同次要副本的数据延迟和数据库状态可能不同。 需要立即读取已提交数据的工作负载应在主要副本上运行。

不能，命名副本不能用作主要副本的故障转移目标。 为此，需添加 HA 副本。

由于每个命名副本可能具有不同的服务级别目标，因此可用于不同的用例，因而没有内置方法可将发送到主要副本的只读流量定向到一组命名副本。 例如，你可能有八个命名副本，并且可能只想将 OLTP 工作负载定向到命名副本 1 到 4，而所有 Power BI 分析工作负载使用命名副本 5 和 6，数据科学工作负载使用副本 7 和 8。 根据使用的工具或编程语言，分发此类工作负载的策略可能会有所不同。 有关创建工作负载路由解决方案以允许 REST 后端横向扩展的示例，请参阅 OLTP 横向扩展示例。

不能，由于命名副本使用主副本的同一页面服务器，所以它们必须位于相同的区域。

命名副本不会影响主要副本的可用性。 通常，命名副本不太可能影响主要副本的性能，但如果运行密集型工作负载，则可能会发生此情况。 与 HA 副本一样，命名副本通过事务日志服务与主副本保持同步。 如果命名副本出于任何原因无法以足够快的速度使用事务日志，它将开始请求主要副本减慢（限制）其日志生成，以便它能够跟上进度。 尽管此行为不会影响主要副本的可用性，但可能会影响主要副本上的写入工作负载的性能。 若要避免这种情况，请确保命名副本有足够的资源空余空间（主要是 CPU），以便无延迟地处理事务日志。 例如，如果主服务器正在处理大量数据更改，建议命名副本至少具有与主服务器相同的服务级别目标，以避免副本上的 CPU 出现饱和情况，从而迫使主要副本减慢速度。

命名副本仍可照常进行只读访问。

默认情况下，命名副本没有任何自己的 HA 副本。 要对命名副本进行故障转移，需要先创建新副本，这通常需要大约 1-2 分钟。 但是，命名副本也可以受益于 HA 副本提供的更高的可用性和更短的故障转移。 若要为命名副本添加 HA 副本，可结合使用参数 ha-replicas 和 AZ CLI 或参数 HighAvailabilityReplicaCount 和 PowerShell，也可结合使用 highAvailabilityReplicaCount 属性和 REST API。 可以在创建命名副本期间设置 HA 副本数，并且可在创建命名副本后随时更改（仅通过 AZ CLI、PowerShell 或 REST API）。 命名副本的 HA 副本定价与常规超大规模数据库的 HA 副本相同。

是的。 列主密钥存储在用户数据库中，可以通过执行 SELECT * FROM sys.column_master_keys 查询来进行验证。 命名副本和高可用性次要副本从与主超大规模数据库相同的页面服务器/存储层读取数据。 这两种类型的副本都通过日志服务与主超大规模数据库同步。 密钥更改被视为事务，并自动复制到命名副本和高可用性次要副本。

在命名副本的上下文中执行时，DATABASEPROPERTYEX() 函数可以将 replica_id 映射到其对应的命名副本。 但是，当前无法在从主要副本进行查询时针对 sys.dm_database_replica_states 动态管理视图中的每条记录将 replica_id 链接到其单独的命名副本。 以下示例查询可以在命名副本的上下文中运行，以识别副本名称、副本 ID 和同步详细信息。

  SELECT replica_id, DB_NAME() AS 'Database/Replica name', 
  synchronization_state_desc, log_send_queue_size/1024.0/1024.0 AS log_send_queue_size_gb,
  last_sent_time, last_received_time, last_commit_time, secondary_lag_seconds
  FROM sys.dm_database_replica_states
  WHERE replica_id = DATABASEPROPERTYEX(DB_NAME(),'REPLICAID');

相关内容

有关“超大规模”服务层级的详细信息，请参阅“超大规模”服务层级。