平台 ：运行在Windows 2003 Enterprise，8核心，8GB RAM和内部（！）存储上的带有SP4的SQL 2000 Enterprise。 数据库总共大约100GB。
场景 ：waitstats严重偏向于硬件：
CXPACKET - 35.9% WRITELOG - 18.4% LCK_M_S - 13.2% PAGEIOLATCH_SH - 10.9% NETWORKIO - 10.4% LATCH_EX - 5.6% PAGEIOLATCH_EX - 2.6% LCK_M_IX - 1.5% LCK_M_IS - 1.2% PAGELATCH_UP - 0.1% 我暂时忽略了LATCH和LCKtypes，因为我们在SQL 2005升级期间很快转移到SAN，而且内部驱动器无论如何都是碎片化的。
不过，我担心CXPACKETtypes。 在某些情况下，我有80％的等待时间与此有关。 并行执行计划设置是否需要审查？ （此刻设置为5）。 迁移到SAN是否也解决了这个问题？ 我应该首先担心吗？
提前致谢！
CXPACKET等待状态与并行性有关 – 这是在多个处理器上分割查询的成本。 报告查询可以通过在处理器之间分割更小的块并合并结果而从并行性中受益。
如果您的应用程序是OLTP，则可以通过将实例宽度最大并行度设置为1（仅使用一个处理器执行查询）或更高来进行试验。 默认值是0（所有处理器）。
http://msdn.microsoft.com/en-us/library/aa196725(SQL.80).aspx
CXPACKET也与I / O有关，所以迁移到SAN应该至less可以缓解这个问题。