我们在生产中遇到性能问题。
QA和DEV环境在同一物理服务器上有两个实例：Windows 2003 Enterprise SP2，32 GB RAM，1个四核3.5 GHz Intel Xeon X5270（4核x64），SQL 2005 SP3（9.0.4262），SAN驱动器
产品：Windows 2003 Datacenter SP2，64 GB RAM，4双核1.6 GHz Intel Family 80000002，Model 6 Itanium（8核IA64），SQL 2005 SP3（9.0.4262），SAN驱动器，Veritas Cluster
我看到过多的信号等待百分比（> 250％）和页面读取次数（> 50次）和页面写入次数（> 25次）都很高。
我在QA和PROD上都testing了这个查询，它有相同的执行计划，甚至相同的统计信息：
SELECT top 40000000 * INTO dbo.tmp_tbl FROM dbo.tbl GO 扫描计数1，逻辑读取429564，物理读取0，预读读取0，lob逻辑读取0，lob物理读取0，lob预读取0。
正如你所看到的，只是逻辑读取而已：QA：0:48 Prod：2:18
所以这似乎是一个处理器相关的问题，但我不知道下一步该去哪里，有什么想法？
谢谢，
亚伦
这是由两个问题引起的 – prod和QA之间的索引不一致，以及configuration不当的maxdop。
Prod服务器上还有其他事情吗？ 看起来QA服务器只有这个查询运行，而Prod系统必须同时为其他查询运行CPU。 如何比较QA和Prod中的elapsed_time和worker_time ？
另外，确保计划完全相同，包括DOP。
对于您可能在SAN上进行调查的事情，我有几点build议：
您是否看到生产SAN上显着的页面I / O闩锁等待？
数据库是否在繁忙的共享卷上login？
在前一种情况下，可能存在与SAN控制器相关的SANconfiguration或其他性能问题。 我在IBM鲨鱼硬件上看到过这种情况; 转移到DS8000大大缓解了这个问题。
在后一种情况下，你可能会遇到随意寻求破坏日志写入活动的问题。 日志写入是大量连续写入大量顺序的过程。 在安静的磁盘上，这是很快的，因为磁盘访问模式大部分是顺序的。 在繁忙的磁盘上，其他磁盘通信将顺序日志写入随机写入，这是慢得多的。 这可能会使日志驱动器变成一个重要的性能瓶颈。
请注意，在事务提交之前，SQL Server需要将日志写入刷新到磁盘，而大多数SAN供应商已经注册了一个authentication程序，以确保控制器能够遵守该标准。 这意味着，如果您的日志驻留在繁忙的共享卷上，则无法caching大量内存。
“所以这似乎是一个处理器相关的问题，但我不知道下一步该去哪里，有什么想法？
对于我来说，3.5GHz Core 2架构CPU可能比1.6GHz Itanium（不是Intel家族80000002最初的Itanium 2系列，Fanwood或Madison？）快100％，这似乎不是不合理的。 如果你需要更多的速度，看看CPU升级，也许到一个X5600系列至强。