你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
管理专用 SQL 池的计算资源
本文介绍如何在 Azure Synapse Analytics 中管理专用 SQL 池（以前称为 SQL DW）的计算资源。 可通过暂停专用 SQL 池来降低成本，或者根据性能需求缩放专用 SQL 池。
什么是计算管理？
专用 SQL 池的体系结构对存储和计算进行了分隔，允许每一项单独进行缩放。 因此，可以独立于数据存储，根据性能需求缩放计算资源。 还可以暂停和恢复计算资源。
此体系结构的自然结果是，计算和存储的定价是分开的。 如果有一段时间不需要使用专用 SQL 池，可以通过暂停计算来节省计算成本。
缩放计算资源
通过调整专用 SQL 池的数据仓库单位 (DWU) 设置，可以横向扩展或还原计算资源。 添加更多的 DWU 后，加载和查询性能可线性提高。
有关横向扩展的步骤，请参阅 Azure 门户、PowerShell 或 T-SQL 的快速入门。 也可以使用 REST API 执行横向扩展操作。
为了执行缩放操作，专用 SQL 池首先会终止所有传入的查询，并会回滚事务以确保一致的状态。 缩放只会在事务回滚完成后发生。 对于缩放操作，系统会从计算节点分离存储层、添加计算节点，然后将存储层重新附加到计算层。
每个专用 SQL 池存储为在计算节点之间平均分布的 60 个分布区。 添加更多计算节点可提高计算能力。 随着计算节点的增加，每个计算节点的分布区数目会减少，因此可为查询提供更高的计算能力。 同样，减少 DWU 会减少计算节点数目，从而减少用于查询的计算资源。
下表显示了当 DWU 数发生变化时，每个计算节点的分布区数目如何变化。 DW30000c 提供 60 个计算节点，实现的查询性能比 DW100c 高得多。
| 数据仓库单位数 | 计算节点数 | 每个节点的分布区数 |
|---|---|---|
| DW100c | 1 | 60 |
| DW200c | 1 | 60 |
| DW300c | 1 | 60 |
| DW400c | 1 | 60 |
| DW500c | 1 | 60 |
| DW1000c | 2 | 30 |
| DW1500c | 3 | 20 |
| DW2000c | 4 | 15 |
| DW2500c | 5 | 12 |
| DW3000c | 6 | 10 |
| DW5000c | 10 | 6 |
| DW6000c | 12 | 5 |
| DW7500c | 15 | 4 |
| DW10000c | 20 | 3 |
| DW15000c | 30 | 2 |
| DW30000c | 60 | 1 |
找到数据仓库单位的适当大小
若要体验横向扩展带来的性能优势（尤其是对于较大的数据仓库单位），可以至少使用 1 TB 的数据集。 若要确定专用 SQL 池的最佳 DWU 数目，请尝试纵向扩展和缩减。 加载数据后，使用不同数量的 DWU 运行几个查询。 由于缩放很快就能完成，可以在一个小时或更少时间内尝试一些不同级别的性能。
关于找到 DWU 数目的建议：
- 对于开发中的专用 SQL 池，可以从较小的 DWU 数目开始。 DW400c 或 DW200c 是一个不错的起点。
- 监视应用程序性能，将所选 DWU 数目与观测到的性能变化进行比较。
- 采用线性缩放，确定需要以多大的增量来增加或减少 DWU。
- 继续进行调整，直到达到业务要求的最佳性能级别。
何时横向扩展
横向扩展 DWU 会影响性能的以下方面：
- 以线性方式改善系统的扫描、聚合和 CTAS 语句性能
- 增加用于加载数据的读取器和编写器数量
- 并发查询和并发槽的最大数量
关于何时横向扩展 DWU 的建议：
- 执行繁重的数据加载或转换操作时，可以横向扩展以更快速地获取数据。
- 高峰业务时段，可以横向扩展以容纳更大数量的并发查询。
如果横向扩展无法提高性能怎么办？
添加 DWU 会增加并行度。 如果工作在计算节点之间均匀拆分，则更高的并行度可以提高查询性能。 有几种原因会导致横向扩展不能改变性能。 数据可能在分布区中扭曲，或者查询可能引入了大量的数据移动操作。 若要调查查询性能问题，请参阅排查性能问题。
暂停和恢复计算
暂停计算资源会导致存储层从计算节点分离。 将从帐户中释放计算资源。 暂停计算资源时，不会产生计算费用。 恢复计算资源会将存储重新附加到计算节点，并且恢复计算费用。
当暂停专用 SQL 池时：
- 计算和内存资源返回到数据中心的可用资源池中。
- 暂停期间，数据仓库单位的费用为零。
- 不影响数据存储，数据保持不变。
- 所有正在运行的或已排队的操作都会被取消。
- DMV 计数器将重置。
当恢复专用 SQL 池时：
- 专用 SQL 池将获取 DWU 设置的计算和内存资源。
- DWU 的计算费用会恢复。
- 数据可用。
- 专用 SQL 池联机后，需要重启工作负载查询。
如果希望随时可访问专用 SQL 池，请考虑将其纵向缩减到最小大小，而不是暂停。
有关暂停和恢复步骤，请参阅 Azure 门户或 PowerShell 的快速入门。 也可以使用暂停 REST API 或恢复 REST API。
暂停或缩放之前清空事务
在启动暂停或缩放操作之前，我们建议先让现有事务完成。
当暂停或缩放专用 SQL 池时，用户一发起暂停或缩放请求，系统就会在后台取消查询。 取消简单的 SELECT 查询是很快的操作，对于暂停或缩放实例所花费的时间几乎没有什么影响。 但是，事务性查询（将修改数据或结构）可能无法快速地停止。 按定义，事务性查询必须完全完成或回退更改。
回滚事务性查询已完成的任务可能需要很长时间，甚至比查询应用原始更改更久。 例如，如果取消的删除行查询已经运行一小时，系统可能需要一个小时重新插入已删除的行。 如果在事务运行中运行暂停或缩放，暂停或缩放操作可能需要一些时间，因为暂停和缩放必须等回滚完成才能继续。
自动执行计算管理
若要自动执行计算管理操作，请参阅使用 Azure Functions 管理专用 SQL 池的计算资源。
每项横向扩展、暂停和恢复操作可能需要几分钟才能完成。 如果自动执行缩放、暂停或恢复操作，我们建议实现相应的逻辑来确保先完成特定的操作，然后再继续其他操作。 通过不同的终结点检查专用 SQL 池状态可以正确实现此类操作的自动化。
若要检查专用 SQL 池状态，请参阅 PowerShell 或 T-SQL 的快速入门。 还可以使用 REST API 检查专用 SQL 池状态。
权限
缩放专用 SQL 池需要 ALTER DATABASE 中所述的权限。 暂停和恢复需要 SQL DB 参与者角色，具体而言是 Microsoft.Sql/servers/databases/action。