限制 CPU、内存和磁盘后在哪里寻找瓶颈

Question

我有一个每天晚上运行的数据库作业来创建一个仓库表。使用我的新数据库服务器和 SAN，我将过程从 4 1/2 小时缩短到 35 分钟。我已经将它优化为通过实验在最短的时间内运行（WITH INDEX NOLOCK、FORCE ORDER、LOOP JOIN、MAXDOP 0）。我对改进感到满意，但我讨厌不知道为什么查询需要这么长时间。我完全可以接受瓶颈，只要我知道它们在哪里。当此查询运行时，在很长一段时间内，明显的资源都未得到充分利用。SQL Server 在这些时候在做什么？

Answer 1

执行计划和统计信息 IO 会告诉你所有你需要知道的关于正在发生的事情。

SQL Server 可能出现瓶颈的地方有四个，您列出了其中三个。磁盘（逻辑和物理 IO）、RAM 或 CPU。在那之后，它只是产生比实际需要更多的逻辑 IO 的蹩脚代码。

有了所有这些调整提示，您可能已经有一些需要清理的代码。您需要查看查询的执行计划（如果愿意，可以发布）并查看查询中的问题所在。当启用 set statistics io on 时，您可以通过查看输出来查看 IO 是逻辑（缓存命中）还是物理（磁盘命中）。

Answer 2

试试这个查询：select * from sys.dm_exec_requests where session_id>50。这将显示所有当前正在执行的用户查询。查看wait_type、last_wait_type 和wait_resource 以了解您的查询正在等待什么。

也可以使用：select * from sys.dm_os_waiting_tasks where session_id>50。这将显示您所有排队的任务。此查询还返回一个 wait_type 列。如果 CPU 使用率低，则给人的印象是 SQL 没有做任何事情。大多数情况下，SQL 将等待另一个与 CPU 无关的资源被释放。可以通过上面的查询完成内部外观。

您可以在此处阅读更多相关信息。

Answer 3

很可能它正在运行逻辑读取，为下一次插入/创建/任何类型的操作做准备。我的 DW 遇到了完全相同的问题，其中代码会在一段时间内无所事事。那一次的最终结果是，一个维度表达到了数据库中的任何阈值，这使得有时需要更长的时间来拉取数据；即使强制执行查询计划也不能解决问题。重构查询并添加新索引使其非常满意。

如果可以并且不会显着影响生产，请尝试在相关代码后面运行分析器跟踪并收集 SHOWPLAN 结果。这应该表明您是否有索引问题，或者可能会从重写中受益的查询。