applies to：
Azure SQL Managed Instance
本文概述了Azure SQL Managed Instance的技术特征和资源限制，并提供有关如何请求提高这些限制的信息。
注意
有关支持的功能和 T-SQL 语句的差异，请参阅功能差异和 T-SQL 语句支持。 有关Azure SQL Database和SQL Managed Instance服务层级之间的常规差异，请查看 General Purpose 和 Business Critical 服务层级。
硬件配置特征
本节内容：
SQL Managed Instance具有依赖于底层基础结构和体系结构的特性和资源限制。 可以在多个硬件代系上部署SQL Managed Instance。
各代硬件具有不同的特性，如下表所述：
| 功能 | 标准系列 (Gen5) | 高级系列 | 内存优化高级系列 |
|---|---|---|---|
| 中央处理器 | 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 -80 vCore | 4-64 个 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 Managed Instance可用资源限制的存储大小，请考虑 Azure SQL Database Hyperscale 服务层级。
区域支持内存优化高级系列硬件和具有 16 TB 存储的高级系列硬件
对配备 16 TB 存储的高级系列硬件的支持与对内存优化高级系列硬件的支持具有相同的可用性。 要了解更多信息，请查看 内存优化高级系列硬件和具有 16 TB 存储的高级系列硬件的区域支持。
内存中 OLTP 可用空间
在业务关键服务层中，内存中的 OLTP 空间量取决于 vCore 数和硬件配置。 下表列出了可用于内存中 OLTP 对象的内存限制。
| vCore 数 | 标准系列 (Gen5) | 高级系列 | 内存优化高级系列 |
|---|---|---|---|
| 4 个 vCore | 3.14 吉字节 | 4.39 吉字节 | 8.79 吉字节 |
| 8 个 vCore | 6.28吉字节 | 8.79 吉字节 | 22.06 吉字节 |
| 16 个 vCore | 15.77 吉字节 | 22.06 吉字节 | 57.58 吉字节 |
| 24 个 vCore | 25.25 吉字节 | 35.34 吉字节 | 93.09 吉字节 |
| 32 个 vCore | 37.94 吉字节 | 53.09 吉字节 | 128.61 吉字节 |
| 40 个 vCore | 52.23 吉字节 | 73.09 吉字节 | 164.13 吉字节 |
| 64 个 vCore | 99.9 吉字节 | 139.82 吉字节 | 288.61 吉字节 |
| 80 个 vCore | 131.68 吉字节 | 184.30 吉字节 | - |
服务层特征
SQL Managed Instance有两个服务层：常规用途和业务关键层。
重要
业务关键服务层级提供可用于只读工作负荷的SQL Managed Instance（次要副本）的附加内置副本。 如果可以隔离读写查询和只读/分析/报告查询，则能够以相同的价格获得两倍的 vCore 和内存。 次要副本可能滞后于主要实例几秒，因此它旨在卸载不需要确切的当前数据状态的报告/分析工作负荷。 在下表中，只读查询是在辅助副本上执行的查询。
本节内容：
vCore 数目
| 硬件代系 | 常规用途 | 业务关键 |
|---|---|---|
| 标准系列 (Gen5) | 21， 4， 8， 16， 24， 32， 40， 64， 80 | 4、8、16、24、32、40、64、80 |
| 高级系列 | 21， 4， 8， 16， 24， 32， 40， 64， 80 | 4、8、16、24、32、40、64、80 |
| 内存优化高级系列 | 4、8、16、24、32、40、64 | 4、8、16、24、32、40、64 |
1 只能在实例池中部署 2-vCore 实例。
最大内存
| 硬件代系 | 常规用途 | 业务关键 |
|---|---|---|
| 标准系列 (Gen5) | 20.4GB - 408 GB 5.1 GB/vCore |
20.4GB - 408 GB 每个副本上的 5.1 GB/vCore |
| 高级系列 | 28 GB - 560 GB 7 GB/vCore |
28 GB - 560 GB 7 GB/vCore，每个副本上最多 80 个 vCore1 |
| 内存优化高级系列 | 54.4 GB - 870.4 GB 13.6 GB/vCore |
54.4 GB - 870.4 GB 13.6 GB/vCore，每个副本上最多 64 个 vCore1 |
1 对于高级系列硬件，此内存与 vCore 的比率仅适用于最多 80 个 vCore；对于内存优化高级系列，则仅适用于最多 64 个 vCore。 对于高于 80 的高级系列 vCore，最大内存上限为 560 GB；对于高于 64 的内存优化高级系列 vCore，最大内存上限为 870.4 GB。
最大实例存储大小（保留）
下表列出了基于每个硬件生成和服务层的 vCore 数的最大存储大小：
| 硬件代系 | 常规用途1 | 业务关键2 |
|---|---|---|
| 标准系列 (Gen5) | - 4 个 vCore 2 TB - 8 个 vCore 8 TB - 其他大小 16 TB |
- 1 TB，适用于 4、8、16 个 vCore - 2 TB（适用于 24 个 vCore） - 32、40、64、80 个 vCore 4 TB |
| 高级系列 | - 4 个 vCore 2 TB - 8 个 vCore 8 TB - 其他大小 16 TB |
- 1 TB（适用于 4 个、8 个 vCore） - 2 TB（适用于 16 个、24 个 vCore） - 32 个 vCore 4 TB - 40、64、80 个 vCore 5.5 TB |
| 内存优化高级系列 | - 4 个 vCore 2 TB - 8 个 vCore 8 TB - 其他大小 16 TB |
- 1 TB（适用于 4 个、8 个 vCore） - 2 TB（适用于 16 个、24 个 vCore） - 32 个 vCore 4 TB - 40 个 vCore 5.5 TB - 64 个 vCore 16 TB |
1 在“常规用途”服务层级中， tempdb 使用本地 SSD 存储。
2 在业务关键服务层级中， tempdb 与数据和日志文件共享本地 SSD 存储。
tempdb大小可以增大到当前可用的实例存储大小。
服务层特征比较
| 功能 | 常规用途 | 业务关键 | |
|---|---|---|---|
| 最大数据库大小 | 最大为当前可用实例大小（具体取决于 vCore 数）。 | 最大为当前可用实例大小（具体取决于 vCore 数）。 | |
最大 tempdb 数据库大小 |
限制为 24 GB/vCore (96 - 1,920 GB) 和当前可用的实例存储大小。 添加更多 vCore 以获得更多 tempdb 空间。日志文件大小限制为 120 GB。 |
不超过当前可用的实例存储大小。 | |
最大 tempdb 文件数 |
128 | 128 | |
| 每个实例的数据库数目上限 | 提供 100 个用户数据库，除非已达到实例存储大小限制。 | 提供 100 个用户数据库，除非已达到实例存储大小限制。 | |
| 数据库文件数上限 | 每个实例 280 个，除非达到实例存储大小或 Azure高级磁盘存储分配空间限制。 | 除非已达到实例存储大小限制，否则为每个数据库 32,767 个文件。 | |
| 最大数据文件大小 | 每个数据文件的最大大小为 8 TB。 对于大于 8 TB 的数据库，请至少使用两个数据文件。 | 最大为当前可用实例大小（具体取决于 vCore 数）。 | |
| 最大日志文件大小 | 限制为 2 TB 和当前可用的实例存储大小。 | 限制为 2 TB 和当前可用的实例存储大小。 | |
| 数据/日志 IOPS（近似值） | 500 - 7500（每个文件） * 增加文件大小以获得更多 IOPS |
16 K - 320 K （4000 IOPS/vCore） 添加更多 Vcore 以获得更好的 IO 性能。 |
|
| 数据吞吐量（近似值） | 100 - 250 MiB/秒（每个文件） * 增加文件大小以获得更好的 IO 性能 |
无限制。 | |
| 日志写入吞吐量限制（每个实例） | 4.5 MiB/秒（每个 vCore） 最大为 120 MiB/秒（每个实例） 每个数据库 22 - 65 MiB/秒（具体取决于日志文件大小） * 增加文件大小以获得更好的 IO 性能 |
4.5 MiB/秒（每个 vCore） 最大为 192 MiB/秒 |
标准系列： 4.5 MiB/秒（每个 vCore） 最大 96 MiB/秒 高级系列和内存优化高级系列： 每个 vCore 12 MiB/秒 最大为 192 MiB/秒 |
| 存储 IO 延迟（大约1） | 5-10 毫秒 | 1-2 毫秒 | |
| 内存中 OLTP | 不支持 | 可用大小取决于 vCore 数 | |
| 最大会话数 | 30000 | 30000 | |
| 最大并发辅助进程数 | 105 * vCore 数目 + 800 | 105 * vCore 数目 + 800 | |
| 使用只读副本卸载只读的查询工作负荷 | 0 | 1（包括在价格中） | |
| 计算隔离 | 不支持，因为“常规用途”实例可能与其他实例共享物理硬件 |
标准系列（Gen5）： 支持具有 64 个或更多 vCore 的配置 高级系列：支持具有 64 个或更多 vCore 的配置 内存优化高级系列：支持具有 64 个 vCore 的配置 |
|
| 可用性副本 | 备用节点有助实现高可用性 | 四个高可用性副本，1 也是读取扩展副本 | |
| 启用了故障转移组的只读副本 | 另外一个只读副本。 总共两个可读副本，其中包含主要副本。 | 另外两个只读副本，总共三个只读副本。 总共四个可读副本，其中包含主要副本。 | |
| 定价/计费 |
vCore、保留存储和备份存储收费。 IOPS 不收费 |
vCore、保留存储和备份存储收费。 IOPS 不收费。 |
|
| 折扣模型 | 企业和即用即付开发/测试订阅 |
企业和即用即付开发/测试订阅 |
1 这是一个平均范围。 尽管绝大多数 IO 请求持续时间将归入范围顶部，但超出范围的离群值也可能存在。
IOPS
对于业务关键服务层级，可用的 IOPS 由 vCore 数决定：
业务关键服务层级：使用公式 (4000 IOPS/vCore) 来确定 IOPS 限制。
下表列出了根据 vCore 数提供的最大 IOPS：
| vCore 数目 | 业务关键 |
|---|---|
| 4 | 16,000 |
| 8 | 32,000 |
| 16 | 64,000 |
| 24 | 96,000 |
| 32 | 128,000 |
| 40 | 160,000 |
| 64 | 256,000 |
| 80 | 320,000 |
常规用途层中的文件 IO 特征
在常规用途服务层中，每个数据库文件都将获得专用 IOPS 和吞吐量，具体取决于文件大小。 较大的文件会获得更多的 IOPS 和吞吐量。 下表显示了数据库文件的 IO 特征：
| 文件大小 | >=0，<=129 GiB | >129 和 <=513 GiB | >513 和 <=1025 GiB | >1025 和 <=2049 GiB | >2049 和 <=4097 GiB | >4097 GiB 和 <=8 TiB |
|---|---|---|---|---|---|---|
| 每个文件 |
500 | 2300 | 五千 | 7500 | 7500 | 7500 |
| 每个文件 |
100 MiB/秒 | 150 MiB/秒 | 200 MiB/秒 | 250 MiB/秒 | 250 MiB/秒 | 250 MiB/秒 |
如果注意到某个数据库文件的 IO 延迟较高，或者发现 IOPS/吞吐量即将达到限制，可以通过增大文件大小来提高性能。
最大日志写入吞吐量也存在实例级别的限制（请查看上表以获取值，例如 22 MiB/秒），因此，你可能无法达到日志文件的最大文件吞吐量，因为你即将达到实例吞吐量限制。
数据和日志存储
以下因素会影响用于数据和日志文件的存储量，并适用于“常规用途”和“业务关键”层级。
- 在常规用途服务层级中，
tempdb使用本地 SSD 存储，此存储成本包含在 vCore 价格中。 - 在业务关键服务层级中，
tempdb与数据和日志文件共享本地 SSD 存储，tempdb存储成本包含在 vCore 价格中。 - 必须以 32 GB 的倍数指定SQL Managed Instance的最大存储大小。
重要
在这两个服务层级中，将针对为 SQL 托管实例配置的最大存储大小收费。
若要监视SQL Managed Instance消耗的实例存储大小总数，请使用 storage_space_used_mbmetric。 若要使用 T-SQL 监视数据库中单个数据文件和日志文件的当前已分配和已用存储大小，请使用 sys.database_files 视图和 FILEPROPERTY(... , 'SpaceUsed') 函数。
提示
在某些情况下，可能需要收缩数据库来回收未使用的空间。 有关详细信息，请参阅 DBCC SHRINKFILE。
备份和存储
为数据库备份分配存储，以支持SQL Managed Instance的 时间点还原（PITR）和长期保留（LTR）功能。 此存储独立于数据和日志文件存储，并单独计费。
PITR：在“常规用途”和“业务关键”层级中，各个数据库备份将自动复制到读取访问异地冗余 (RA-GRS) 存储。 创建新备份时，存储大小动态递增。 存储将由完整备份、差异备份和事务日志备份使用。 存储消耗量取决于数据库变化率以及为备份配置的保留期。 可以在 1 到 35 天内为每个数据库配置一个单独的保留期，SQL Managed Instance。 提供与配置的最大数据大小相等的备份存储量，不收取额外费用。
LTR：你还可以选择将完整备份的长期保留期配置为最多 10 年。 如果设置了 LTR 策略，则这些备份将自动存储在 RA-GRS 存储中，但你可以控制备份的复制频率。 为了满足不同的符合性要求，可为每周、每月和/或每年备份选择不同的保留期。 所选配置决定了多少存储用于 LTR 备份。 有关详细信息，请参阅 长期保留 - Azure SQL Database和 Azure SQL Managed Instance。
其他特征注意事项
当前可用实例存储大小是预留实例大小与已用存储空间之差。
与最大存储大小限制进行比较的实例存储大小同时包括用户数据库和系统数据库中的数据和日志文件大小。 可以使用 sys.master_files 系统视图来确定数据库使用的空间总量。 错误日志不会持久保存，不包括在大小中。 备份不包括在存储大小中。
常规用途层中的吞吐量和 IOPS 也取决于 file 大小，并且不受SQL Managed Instance显式限制。
最大实例 IOPS 取决于工作负荷的文件布局和分布。 例如，如果你创建 7 个 1-TB 文件（每个文件最大 5K IOPS）和 7 个小文件（小于 128 GB，每个文件 500 IOPS），并且工作负载可以使用所有文件，则每个实例可以处理 38500 IOPS (7x5000+7x500)。 某些 IOPS 还用于自动回退。
tempdb文件的名称不能超过 16 个字符。
在本文中找到有关SQL Managed Instance池中
支持的区域
SQL Managed Instance只能在 supported regions 中创建。 若要在当前不支持的区域中创建SQL Managed Instance，可以发送支持请求。
区域资源限制
注意
有关订阅的区域可用性的最新信息，请首先查看选择区域。
支持的订阅类型可以包含每个区域的有限数量的资源。 SQL Managed Instance每个Azure区域有两个默认限制（可以通过创建特殊的 support 请求来按需增加，具体取决于订阅类型：
- Subnet 限制：在单个区域中部署SQL Managed Instance实例的最大子网数。
- vCore 单元限制：可跨单一区域的所有实例部署的 vCore 单元数上限。 一个 GP vCore 使用一个 vCore 单元，一个 BC vCore 使用 4个 vCore 单元。 实例总数不受限制，只要在 vCore 单元限制内即可。
注意
这些限制是默认设置，不是技术限制。 如果在当前区域中需要更多实例，可以创建特殊支持请求，以根据需要提高限制。 或者，可以在另一个Azure区域中创建新的SQL Managed Instance实例，而无需发送支持请求。