我正在尝试减少SQL Server 2012数据库中的CXPACKET等待。
为了做到这一点，我将调整并行度的MAXDOP和成本阈值。见布伦特·奥扎尔的article。
为了衡量这些变化对等待时间的影响，我使用sys.dm_os_wait_stats和this advice跟踪每15分钟的等待时间。我想在调整之前和2周之后需要2周的读数。
但是，我也对跟踪整体查询性能感兴趣。在更改之前和之后查看查询的执行情况的好方法是什么 - 在时间框架之前的2周/之后的2周内？是否有sprocs会给我这些数据？
答案 0 :(得分：1)
CXPACKET等待并不一定表示并行性问题 - 它通常是其他问题的症状。
当一个查询并行时，让我们说10个线程，并且这10个线程中的一个比其他线程花费更长的时间来完成其工作，其他9个线程将累积CXPACKET等待。
您还看到了哪些其他高等待类型？
答案 1 :(得分：1)
在运行大量大型查询的环境中，您总是会看到CXPacket位于等待列表的顶部，这不是问题。唯一的问题是，当你的正常等待开始暴涨时。在这些情况下，通常意味着您的统计数据太远，以至于无法获得准确的执行计划，您需要研究更好的索引维护。
根据你的说法，我没有理由单独根据这一点降低MaxDOP。相反，我会使用最多8个的典型建议，不超过OLTP的单个NUMA节点中的核心数。
在您的情况下，我会根据Query Stats开始使用server-side trace查看最昂贵的查询以及最大的查询。如果您能够调整您在此处看到的最大违规者，那么您将拥有更快的服务器以及更低的CXPacket等待类型。
作为一个免责声明，我是您提到的等待统计文章的作者以及此回复中链接的文章。
请随时回复此问题或在我的博客上回复任何其他人。
答案 2 :(得分：1)
基于以上所述，您似乎可以使用一些实用程序来帮助您监控查询性能。
我可以推荐可以存储历史信息的ApexSQL Monitor（商业工具，但提供免费试用），这样您就可以在减少MAXDOP之前和之后查看详细信息 - 您可以查看整体查询性能。
除此之外，您还可以在本文http://www.sqlshack.com/troubleshooting-the-cxpacket-wait-type-in-sql-server/中找到有关CXPACKET和MAXDOP可能原因的详细说明。以下是文章中的一些重要内容：
在诊断高CXPACKET等待统计值的原因时建议的步骤（在做出任何下意识反应和更改SQL Server上的内容之前）：