相关疑难解决方法(0)

作为我之前关于对 Sharepoint 站点进行性能故障排除的问题的后续问题，我想知道我是否可以对 CXPACKET 等待做些什么。

我知道下意识的解决方案是通过将 MAXDOP 设置为 1 来关闭所有并行性 - 听起来是个坏主意。但另一个想法是在并行开始之前增加成本阈值。执行计划成本的默认值 5 相当低。

所以我想知道是否已经写了一个查询，可以找到执行计划成本最高的查询（我知道你可以找到那些执行持续时间最长的查询等等 - 但是执行计划成本是否可以在某处检索，也是？），这也会告诉我这样的查询是否已并行执行。

有没有人手头有这样的脚本，或者可以向我指出相关的 DMV、DMF 或其他系统目录视图的方向以找出这一点？

我有一个正在处理数百万条记录的 SQL Server 2008 查询。查询在一个由作业每晚运行的过程中。当我第一次将它放在服务器上时，查询可能需要一整天才能运行，但在一周左右的时间内它会下降到不到一个小时——没有我的任何干预。它以某种方式自我修复。

该查询在 tempdb 中运行，在它自行修复之前，当我检查它的性能统计信息时，我发现以下内容：CXPACKET：20,700 秒或 66% 的等待时间。
PAGEIOLATCH:_SH 2,500 或等待时间的 8%。
LOGBUFFER：1500 秒或等待时间的 5% IO_COMPLETION：1500 秒或等待时间的 5%

我尝试调整索引等，当 CXPACKET 为 77% 的等待时间时，上面的统计数据比我第一次运行时有所改进。我阅读了故障排除技巧，其中说我应该将我的 tempdb 拆分为每个 CPU 的一个文件。我有一个双 cpu 32 位 W2K8 系统，所以我将 tempdb 分成 2 个文件，并将每个文件的大小大大增加到 150 GB，每次 10% 自动增长，但它们没有增长，所以我认为大小足够了。

当我在查询运行时查看服务器时，我可以看到 CPU 没有固定并且徘徊在其容量的 <10% 左右。固定的是DISK IO。机器只有一个磁盘。

事不宜迟，下面是导致问题的两个查询（第一个查询曾经是后者的子查询 - 请参阅下面的解释）：

insert into #ttcbm(tradeId1, tradeId2)
select distinct tp.tradeid tradeId1, tp1.tradeid tradeId2
from #tradeP tp
join #tradeP tp1    
on tp.cmbId = tp1.cmbId
and tp.qs_plyrid = tp1.qs_plyrid    
and tp.tradeId > tp1.tradeId …