你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

Azure SQL 托管实例资源限制概述

适用于:Azure SQL 托管实例

本文概述了 Azure SQL 托管实例的技术特征和资源限制,并提供了有关如何请求提高这些限制的信息。

注意

有关支持的功能和 T-SQL 语句的差异,请参阅功能差异T-SQL 语句支持。 有关 Azure SQL 数据库和 SQL 托管实例的服务层级之间的一般差异,请查看常规用途业务关键服务层级。

硬件配置特征

SQL 托管实例的某些特征和资源限制取决于底层基础结构和体系结构。 SQL 托管实例可部署在多个硬件配置上。

注意

Gen5 硬件已重命名为标准系列 (Gen5)。

各种硬件配置具有不同的特征,如下表所述:

标准系列 (Gen5) 高级系列 内存优化高级系列
CPU Intel® E5-2673 v4 (Broadwell) 2.3 GHz、Intel® SP-8160 (Skylake) 和 Intel® 8272CL (Cascade Lake) 2.5 GHz 处理器 Intel® 8370C (Ice Lake) 2.8 GHz 处理器 Intel® 8370C (Ice Lake) 2.8 GHz 处理器
vCore 数目
vCore=1 LP(超线程)
21 – 80 个 vCore 21 – 128 个 vCore 4-128 个 vCore
最大内存(内存/ vCore 比率) 每个 vCore 5.1 GB - 上限 408 GB
添加更多 vCore 以获得更多内存。
每个 vCore 7 GB,最多 80 个 vCore - 上限 560 GB 每个 vCore 13.6 GB,最多 64 个 vCore - 上限 870.4 GB
最大内存中 OLTP 存储 实例限制:每个 vCore 0.8 - 1.65 GB 实例限制:每个 vCore 1.1 - 2.3 GB 实例限制:每个 vCore 2.2 - 4.5 GB
实例保留存储上限2 常规用途:最多 16 TB
业务关键:最多 4 TB
常规用途:最多 16 TB
业务关键:最多 5.5 TB
常规用途:最多 16 TB
业务关键:最多 16 TB

1 只能在实例池中部署 2-vCore 实例。
2 具体取决于 vCore 的数量

注意

如果工作负载需要的存储大小大于适用于 Azure SQL 托管实例的资源限制,请考虑使用 Azure SQL 数据库的“超大规模”服务层级

对内存优化高级系列硬件和 16 TB 存储的区域支持

对 16 TB 存储的支持与对内存优化高级系列硬件的支持具有相同的可用性。 目前仅在以下特定区域提供对内存优化高级系列硬件和 16 TB 存储的支持:

地域 支持内存优化高级系列硬件和 16 TB 存储的区域
欧洲 法国中部、德国中西部、意大利北部、北欧、波兰中部、瑞典中部、瑞士北部、英国南部、西欧
中东、非洲 卡塔尔中部
美洲 巴西南部、加拿大中部、美国中部、美国东部、美国东部 2、美国中北部、美国中南部、美国西部、美国西部 2、美国西部 3
亚太区 澳大利亚东部、澳大利亚东南部、中国北部 3、印度中部、印度南部、东亚、日本东部、东南亚

内存中 OLTP 可用空间

业务关键服务层中,内存中的 OLTP 空间量取决于 vCore 数和硬件配置。 下表列出了可用于内存中 OLTP 对象的内存限制。

vCore 数 标准系列 (Gen5) 高级系列 内存优化高级系列
4 个 vCore 3.14 GB 4.39 GB 8.79 GB
6 个 vCore - 6.59 GB 15.32 GB
8 个 vCore 6.28 GB 8.79 GB 22.06 GB
10 个 vCore - 12.11 GB 30.94 GB
12 个 vCore - 15.43 GB 39.82 GB
16 个 vCore 15.77 GB 22.06 GB 57.58 GB
20 个 vCore - 28.70 GB 75.34 GB
24 个 vCore 25.25 GB 35.34 GB 93.09 GB
32 个 vCore 37.94 GB 53.09 GB 128.61 GB
40 个 vCore 52.23 GB 73.09 GB 164.13 GB
48 个 vCore - 95.34 GB 199.64 GB
56 个 vCore - 117.58 GB 244.13 GB
64 个 vCore 99.9 GB 139.82 GB 288.61 GB
80 个 vCore 131.68 GB 184.30 GB 288.61 GB
96 个 vCore 空值 184.30 GB 288.61 GB
128 个 vCore 空值 184.30 GB 288.61 GB

服务层特征

SQL 托管实例有两个服务层级:常规用途业务关键

重要

“业务关键”服务层级提供了 SQL 托管实例的附加内置副本(次要副本),可用于只读工作负载。 如果可以隔离读写查询和只读/分析/报告查询,则能够以相同的价格获得两倍的 vCore 和内存。 次要副本可能滞后于主要实例几秒,因此它旨在卸载不需要确切的当前数据状态的报告/分析工作负荷。 在下表中,只读查询是在辅助副本上执行的查询。

功能 常规用途 业务关键
vCore 数目* 21、4、8、16、24、32、40、64、80 标准系列 (Gen5) :4、8、16、24、32、40、64、80
高级系列:4、6、8、10、12、16、20、24、32、40、48、56、64、80、962、1282
内存优化高级系列:4、6、8、10、12、16、20、24、32、40、48、56、64、802、962、1282
* 相同数量的 vCore 专用于只读查询。
最大内存 标准系列 (Gen5) :20.4 GB - 408 GB (5.1 GB/vCore)
高级系列:28 GB - 560 GB (7 GB/vCore)
内存优化高级系列:54.4 GB - 870.4 GB (13.6 GB/vCore)
标准系列 (Gen5):每个副本 20.4 GB - 408 GB (5.1 GB/vCore)
高级系列:每个副本上 28 GB - 560 GB(7 GB/vCore,最多 80 个 vCore2
内存优化高级系列:每个副本上 54.4 GB - 870.4 GB(13.6 GB/vCore,最多 64 个 vCore2
最大实例存储大小(预留) - 4 个 vCore 2 TB
- 8 个 vCore 8 TB
- 其他大小 16 TB
标准系列 (Gen5)
- 1 TB,适用于 4、8、16 个 vCore
- 2 TB(适用于 24 个 vCore)
- 4 TB(适用于 32 个、40 个、64 个、80 个 vCore)
高级系列
- 1 TB,适用于 4 个、6 个 vCore
- 2 TB,适用于 8 个、10 个、12 个 vCore
- 4 TB,适用于 16 个、20 个 vCore
- 5.5 TB,适用于 24 个、32 个、40 个、48 个、56 个 vCore
- 5.5 TB 或 16 TB(具体取决于区域),适用于 64 个、80 个、96 个、128 个 vCore 3
内存优化高级系列
- 1 TB,适用于 4 个、6 个 vCore
- 2 TB,适用于 8 个、10 个、12 个 vCore
- 4 TB,适用于 16 个、20 个 vCore
- 5.5 TB,适用于 24 个 vCore
- 5.5 TB 或 8 TB(具体取决于区域),适用于 32 个、40 个 vCore4
- 12 TB,适用于 48 个、56 个 vCore
- 16 TB,适用于 64 个、80 个、96 个、128 个vCore
最大数据库大小 最大为当前可用实例大小(具体取决于 vCore 数)。 最大为当前可用实例大小(具体取决于 vCore 数)。
最大 tempdb 数据库大小 限制为 24 GB/vCore (96 - 1,920 GB) 和当前可用的实例存储大小。
添加更多 vCore 以获得更多 tempdb 空间。
日志文件大小限制为 120 GB。
不超过当前可用的实例存储大小。
最大 tempdb 文件数 128 128
每个实例的数据库数目上限 提供 100 个用户数据库,除非已达到实例存储大小限制。 提供 100 个用户数据库,除非已达到实例存储大小限制。
数据库文件数上限 除非已达到实例存储大小或 Azure 高级磁盘存储分配空间限制,否则每个实例最多可有 280 个。 除非已达到实例存储大小限制,否则为每个数据库 32,767 个文件。
最大数据文件大小 每个数据文件的最大大小为 8 TB。 对于大于 8 TB 的数据库,请至少使用两个数据文件。 最大为当前可用实例大小(具体取决于 vCore 数)。
最大日志文件大小 限制为 2 TB 和当前可用的实例存储大小。 限制为 2 TB 和当前可用的实例存储大小。
数据/日志 IOPS(近似值) 500 - 7500(每个文件)
*增加文件大小以获得更多 IOPS
16 K - 320 K (4000 IOPS/vCore)
添加更多 Vcore 以获得更好的 IO 性能。
日志写入吞吐量限制(每个实例) 4.5 MiB/秒(每个 vCore)
最大为 120 MiB/秒(每个实例)
每个数据库 22 - 65 MiB/秒(具体取决于日志文件大小)
*增加文件大小以获得更好的 IO 性能
4.5 MiB/秒(每个 vCore)
最大为 192 MiB/秒
数据吞吐量(近似值) 100 - 250 MiB/秒(每个文件)
*增加文件大小以获得更好的 IO 性能
无限制。
存储 IO 延迟(近似) 5-10 毫秒 1-2 毫秒
内存中 OLTP 不支持 可用大小取决于 vCore 数
最大会话数 30000 30000
最大并发辅助进程数 105 * vCore 数目 + 800 105 * vCore 数目 + 800
只读副本 0 1(包括在价格中)
计算隔离 不支持,因为“常规用途”实例可能与其他实例共享物理硬件 标准系列 (Gen5)
支持具有 64 个或更多 vCore 的配置
高级系列:支持具有 64 个或更多 vCore 的配置
内存优化高级系列:支持具有 64 个或更多 vCore 的配置

1 只能在实例池中部署 2-vCore 实例。
2 对于高级系列硬件,内存与 vCore 的比率仅适用于最多 80 个 vCore;对于内存优化高级系列,则仅适用于最多 64 个 vCore。 对于高于 80 的高级系列 vCore,最大内存上限为 560 GB;对于高于 64 的内存优化高级系列 vCore,最大内存上限为 870.4 GB。
3 仅在主要区域可为上述 CPU vCore 数量的高级系列硬件提供 16 TB 的存储,较小区域的可用存储将限制为 5.5 TB。
4 仅在主要区域可为上述 CPU vCore 数量的高级系列内存优化硬件提供 8 TB 的存储,较小区域的可用存储将限制为 5.5 TB。

一些其他注意事项:

  • 当前可用实例存储大小是预留实例大小与已用存储空间之差。
  • 与最大存储大小限制进行比较的实例存储大小同时包括用户数据库和系统数据库中的数据和日志文件大小。 可以使用 sys.master_files 系统视图来确定数据库使用的空间总量。 错误日志不会持久保存,不包括在大小中。 备份不包括在存储大小中。
  • 常规用途层上的吞吐量和 IOPS 还要取决于未显式受到 SQL 托管实例限制的文件大小。 可以使用故障转移组在不同的 Azure 区域中创建另一个可读副本
  • 最大实例 IOPS 取决于工作负荷的文件布局和分布。 例如,如果你创建 7 个 1-TB 文件(每个文件最大 5K IOPS)和 7 个小文件(小于 128 GB,每个文件 500 IOPS),并且工作负载可以使用所有文件,则每个实例可以处理 38500 IOPS (7x5000+7x500)。 请注意,某些 IOPS 还将用于自动备份。
  • tempdb 文件的名称不能超过 16 个字符。

详细了解本文中 SQL 托管实例池的资源限制

数据和日志存储

以下因素会影响用于数据和日志文件的存储量,并适用于“常规用途”和“业务关键”层级。

  • 在“常规用途”服务层级中,tempdb 使用本地 SSD 存储,此存储成本包含在 vCore 价格中。
  • 在“业务关键”服务层级中,tempdb 与数据和日志文件共享本地 SSD 存储,tempdb 存储成本包含在 vCore 价格中。
  • SQL 托管实例的最大存储大小必须指定为 32 GB 的倍数。

重要

在这两种服务层级中,你将按照为托管实例配置的最大存储大小付费。

若要监视 SQL 托管实例的已消耗实例存储大小总计,请使用 storage_space_used_mb指标。 若要使用 T-SQL 监视数据库中单个数据文件和日志文件的当前已分配和已用存储大小,请使用 sys.database_files 视图和 FILEPROPERTY(... , 'SpaceUsed') 函数。

提示

在某些情况下,可能需要收缩数据库来回收未使用的空间。 有关详细信息,请参阅 DBCC SHRINKFILE

备份和存储

为数据库备份分配存储,以支持 SQL 托管实例的时间点还原 (PITR)长期保留 (LTR) 功能。 此存储独立于数据和日志文件存储,并单独计费。

  • PITR:在“常规用途”和“业务关键”层级中,各个数据库备份将自动复制到读取访问异地冗余 (RA-GRS) 存储。 创建新备份时,存储大小动态递增。 存储将由完整备份、差异备份和事务日志备份使用。 存储消耗量取决于数据库变化率以及为备份配置的保留期。 为每个数据库配置单独的保持期时,可以为 SQL 托管实例配置 1 到 35 天的保持期。 提供与配置的最大数据大小相等的备份存储量,不收取额外费用。
  • LTR:你还可以选择将完整备份的长期保留期配置为最多 10 年。 如果设置了 LTR 策略,则这些备份将自动存储在 RA-GRS 存储中,但你可以控制备份的复制频率。 为了满足不同的符合性要求,可为每周、每月和/或每年备份选择不同的保留期。 所选配置决定了多少存储将用于 LTR 备份。 有关详细信息,请参阅长期备份保留

“常规用途”层级中的文件 IO 特征

在常规用途服务层中,每个数据库文件都将获得专用 IOPS 和吞吐量,具体取决于文件大小。 较大的文件会获得更多的 IOPS 和吞吐量。 下表显示了数据库文件的 IO 特征:

文件大小 >=0 且 <=129 GiB >129 且 <=513 GiB >513 且 <=1025 GiB >1025 且 <=2049 GiB >2049 且 <=4097 GiB >4097 GiB 且 <=8 TiB
每个文件的 IOPS 500 2300 5000 7500 7500 7500
每个文件的吞吐量 100 MiB/秒 150 MiB/秒 200 MiB/秒 250 MiB/秒 250 MiB/秒 250 MiB/秒

如果注意到某个数据库文件的 IO 延迟较高,或者发现 IOPS/吞吐量即将达到限制,可以通过增大文件大小来提高性能。

最大日志写入吞吐量也存在实例级别的限制(请查看上表以获取值,例如 22 MiB/秒),因此,你可能无法达到日志文件的最大文件吞吐量,因为你即将达到实例吞吐量限制。

支持的区域

SQL 托管实例只能在支持的区域中创建。 若要在当前不支持的区域中创建 SQL 托管实例,可以通过 Azure 门户发送支持请求

支持的订阅类型

当前仅支持在以下类型的订阅中部署 SQL 托管实例:

区域资源限制

注意

有关订阅的区域可用性的最新信息,请首先查看选择区域

支持的订阅类型可以包含每个区域的有限数量的资源。 SQL 托管实例的每个 Azure 区域都有两个默认限制(可根据需要在 Azure 门户中创建特殊支持请求),具体要取决于订阅的类型:

  • 子网限制:在单个区域中部署 SQL 托管实例的实例的子网数目上限。
  • vCore 单元限制:可跨单一区域的所有实例部署的 vCore 单元数上限。 一个 GP vCore 使用一个 vCore 单元,一个 BC vCore 使用 4个 vCore 单元。 实例总数不受限制,只要在 vCore 单元限制内即可。

注意

这些限制是默认设置,不是技术限制。 如果在当前区域中需要更多实例,可根据需要在 Azure 门户中创建特殊支持请求,以提高这些限制。 或者,可以在另一个 Azure 区域中创建 SQL 托管实例的新实例,而无需发送支持请求。

下表显示了支持的订阅类型的默认区域限制(可使用支持请求扩展默认限制):

订阅类型 SQL 托管实例子网的默认限制 vCore 单元的默认限制*
CSP 16(在某些区域中为 30**) 960(在某些区域中为 1440**)
EA 16(在某些区域中为 30**) 960(在某些区域中为 1440**)
Enterprise 开发/测试 6 320
即用即付 6 320
即用即付开发/测试 6 320
Azure Pass 3 64
BizSpark 3 64
BizSpark Plus 3 64
Microsoft Azure 赞助 3 64
Microsoft 合作伙伴网络 3 64
Visual Studio Enterprise (MPN) 3 64
Visual Studio Enterprise 3 32
Visual Studio Enterprise (BizSpark) 3 32
Visual Studio Professional 3 32
MSDN 平台 3 32

* 在计划部署时,请考虑业务关键 (BC) 服务层需要的 vCore 容量是常规用途 (GP) 服务层的四 (4) 倍。 例如:1 个 GP vCore = 1 个 vCore 单元,1 个 BC vCore = 4 个 vCore。 若要简化以默认限制为准的消耗量分析,请将区域中部署了 SQL 托管实例的所有子网中的 vCore 单元数进行汇总,并将结果与你的订阅类型的实例单元限制进行比较。 vCore 单元的最大数量限制适用于区域中的每个订阅。 除了跨多个子网部署的所有 vCore 的总和必须小于或等于 vCore 单元数上限外,每个子网没有任何限制。

** 以下区域提供更大的子网和 vCore 限制:澳大利亚东部、美国东部、美国东部 2、北欧、美国中南部、东南亚、英国南部、西欧和美国西部 2。

重要

如果 vCore 和子网限制为 0,则表示订阅类型的默认区域限制未设置。 还可以按照相同的过程(提供所需的 vCore 和子网值)使用配额增加请求来获取特定区域的订阅访问权限。

请求增加配额

如果在当前区域中需要更多实例,请使用 Azure 门户发送扩展配额的支持请求。 有关详细信息,请参阅请求增加 Azure SQL 数据库的配额

后续步骤