SQLSERVER CXPACKET 等待

--SQLSERVER CXPACKET 等待 2013-6-11
 2 --联机丛书：
 3 --当尝试同步查询处理器交换迭代器时出现。如果针对该等待类型的争用成为问题时，可以考虑降低并行度
 4
 5
 6
 7 --CXPACKET 解释：
 8 --
 9 --当为SQL查询创建一个并行操作时，会有多个线程去执行这个查询。每个查询处理不同的数据集或行集。
10 --
11 --因为某些原因，一个或多个线程滞后，而产生了CXPACKET等待状态。
12 --
13 --有一个组织/协调（organizer/coordinator）线程(Thread 0)，它需要等待所有线程完成并聚合数据来呈现给客户端。
14 --
15 --组织线程必须等待所有线程完成处理才能进行下一步。由于组织线程等待缓慢的线程完成处理所产生的等待，就叫CXPACKET等待。
16 --
17 --请注意，并不是所有的CXPACKET等待类型都是不好的事情。你也许会遇某个CXPACKET等待是完全有意义的案例，有时它也是不可避免的。
18 --
19 --如果你在任何查询上禁止此种等待，那么查询也许会变慢，因为不能为它执行并行操作。
20
21 --减少CXPACKET等待：
22 --
23 --我们不能抛开服务器负载类型来讨论减少CXPACKET等待。
24 --
25 --OLTP: 在纯OLTP系统上，它的事务较短，查询也不长，但是通常很快速。设置
26 --“Maximum degree of Parallelism”（MAXDOP）为1。
27 --
28 --这样做可以确保查询永远不必使用并行方式运行，并且不会导致更多的数据库引擎开销。
29
30 EXEC sys.sp_configure N'cost threshold for parallelism', N'1'
31 GO
32 RECONFIGURE WITH OVERRIDE
33 GO
34
35
36
37 --Data-warehousing / Reporting server: 因为查询执行时间一般较长，建议设置“Maximum degree of Parallelism”（MAXDOP）为0。
38 --
39 --这样大多数查询将会利用并行处理，执行时间较长的查询也会受益于多处理器而提高性能。
40 --
41 --Mixed System (OLTP & OLAP):这样环境会是一个挑战，必须找到正确的平衡点。我采取了非常简单的方法。
42 --
43 --我设置“Maximum degree of Parallelism”（MAXDOP）为2，这样意味着查询仍会使用并行操作但是仅利用2颗CPU。
44 --
45 --然而，我把“并行查询阀值”设置为较高的值，这样的话，不是所有的查询都有资格使用并行，除了那些查询成本较高的查询。
46 --
47 --在一个即有OLTP查询又有报表服务器的系统上，我发现这样做运行得很好。
48 --
49 --在这里我将会设置“‘Cost Threshold for Parallelism’”为25,你可以选择任何值。但你只能通过在系统上做实验来找到合适的值。
50 --
51 --在下面的脚本中，我设置“Max Degree of Parallelism”为2，这样的话，那些具有较高成本的查询(这里是25)，
52 --将会在2颗CPU上执行并行查询。
53 --
54 --同时，不管服务器有多少颗CPU，查询只会选择两颗CPU来执行。
55
56
57 EXEC sys.sp_configure N'cost threshold for parallelism', N'25'  --临界值，当查询成本达到25的时候
58 GO
59 EXEC sys.sp_configure N'max degree of parallelism', N'2'  --使用两颗CPU
60 GO
61 RECONFIGURE WITH OVERRIDE
62 GO
63
64 --------------------------------------------------------
65 --在查询语句中使用maxdop
66 SELECT  COUNT(*)
67 FROM    t1 a
68 INNER LOOP JOIN t1 b ON b.c1 = a.c1
69 OPTION  ( MAXDOP 1 )  --不允许使用并行处理
70 go