在 SQL Server 中禁用资源调控器

Question

禁用资源调控器后是否应该重新启动 SQL Server？最佳做法是什么？

为什么我问这个，因为我担心 SQL Server 中现有的打开会话。如果我们只禁用资源调控器而不重新启动 SQL 服务，它们的行为（在 CPU、内存和 IO 方面）是否会更改为默认值？

例如，如果某个特定会话由于资源调控器而被限制为使用系统总内存的 30%。所以如果我们现在单独禁用资源调控器，它会立即开始使用超过 30% 吗？

Answer 1

我经常在不重新启动 SQL Server 的情况下更改资源调控器设置。我不知道在更改资源调控器设置后是否需要重新启动 SQL Server，分类器功能更改除外。了解以下几点可能会有所帮助：

• 将会话分配给资源调控器工作负载组后，即使分类器功能发生变化，它也会留在那里。
• 我从未见过资源调控器设置的查询计划编译帐户。
• 查询执行的某些方面是在查询执行开始时决定的，例如 MAXDOP 和查询内存。请注意，有一些例外情况并非总是如此，例如某些类型的索引创建或以批处理模式执行的查询。

当更改应用于查询时（无论它是否“即时”），完全回答的精确答案可能超出了此处的答案范围。我建议弄清楚您关心什么并根据需要进行测试，以说服自己 SQL Server 所做的工作适合您的工作负载。例如，考虑通过资源调控器工作负载组配置可用的 MAXDOP 限制。对于几乎所有查询，MAXDOP 是在查询执行时决定的，因此我不希望禁用资源调控器来更改当前正在执行的查询的 MAXDOP。但是，为会话启动的下一个查询将不再受 MAXDOP 的限制。但是，如果在具有并行计划的查询期间多次执行标量 UDF，会发生什么情况？我希望 MAXDOP 可能会针对该查询进行更改，但我从来没有测试过，也不想测试它。如果我不得不猜测，我怀疑以下所有内容都会“立即”更新：

• MIN_CPU_PERCENT
• MAX_CPU_PERCENT
• CAP_CPU_PERCENT
• MIN_IOPS_PER_VOLUME
• MAX_IOPS_PER_VOLUME
• 重要性
• REQUEST_MAX_CPU_TIME_SEC
• GROUP_MAX_REQUESTS

并且所有这些仅在下一个查询开始执行后更新：

• MIN_MEMORY_PERCENT
• MAX_MEMORY_PERCENT
• 亲和力
• REQUEST_MAX_MEMORY_GRANT_PERCENT
• REQUEST_MEMORY_GRANT_TIMEOUT_SEC
• MAX_DOP