我们的主数据库服务器是一个8核盒，内存为8GB。 CPU是Xeon E7330 @ 2.4GHz。它运行Windows Server 2003 R2（x64版）和SQL Server 2005
我想做一些测试，所以我在另一台全新的服务器上安装了SQL Server 2005，这是一个8核的盒子，内存为4 GB。它有一个Xeon X5460 @ 3.16GHz并运行Windows Server 2003 R2 Standard。我安装了SQL Server 2005，并将主数据库的备份还原到它上面，并对所有表执行了更新统计。
我正在测试的进程多次执行相同的存储过程。我很震惊地从分析器中发现这个在主服务器上持续时间= 0或1执行的proc一直在执行，持续时间超过130.这实质上使得辅助服务器无法进行测试，因为它太慢了。
没有其他应用程序在这两个框中运行，只有SQL服务器。与主数据库服务器不同，测试服务器只让我访问它。
我无法相信这两台机器之间的规格差异解释了这种巨大的性能差异。任何人都可以建议我可能需要更改的设置吗？
更新问题答案：
在测试服务器上查看任务管理器，CPU运行速度为10％，只有一个核心甚至显示活动
测试服务器上的任务管理器（4GB RAM）显示运行SQL Server的“PF Usage 2.01GB”。在主服务器（8GB RAM）上显示“PF Usage 6.67GB”。如何让测试盒上的SQL Server使用更多的RAM？也许这会有所作为
另一个更新：
主服务器具有带15,000 RPM驱动器的RAID-5。测试盒有一个带有10,000 RPM驱动器的RAID-5。
答案 0 :(得分：3)
32位操作系统意味着您的进程有2 GB 虚拟地址空间。标准版操作系统也意味着没有AWE扩展。因此，与生产测试机器相比，您的测试机器将严重缺乏RAM。您的缓冲池将受到过早驱逐页面的影响，您的执行计划将无法为大量查询选择散列连接等等。我怀疑这解释了整个差异，我确信必须有更多的东西在起作用。你说在查询期间只有10个CPU使用率，你的MAXDOP设置是否在测试服务器上有任何机会？您是否比较了两台机器上sp_configure的输出？ （确保你也启用'高级选项'。）
您可以在SSMS查询窗口中使用SET STATISTICS IO ON和SET STATISTICS TIME ON在两台计算机上运行相同的问题查询吗？每次运行2-3次并记下结果。它是否显示相同数量的逻辑读取但物理读取数量差异很大？这将指向RAM不足以缓存所需的页面。 IS的逻辑读取数量差异很大？这可能意味着您在测试时得到了糟糕的执行计划。
查询是否写入密集？如果是这样，您是预先扩展测试数据库还是由日志增长和数据库增长事件阻止执行？
有很多地方可以缩小问题范围，比如SQL性能计数器，sys.dm_os_wait_stats，请检查sys.dm_exec_requests wait_type和wait_resource。
答案 1 :(得分：0)
您要么生成了不同的计划，要么存在一些硬件差异。对于硬件，您可以检查磁盘秒数/ [读取，写入]（编辑以澄清 - 您在perfmon中执行此操作）并查看您是否与缓存有很大差异（例如，高性能控制器）。
对于计划差异，只需查看执行计划。 还要设置统计信息io，看看你是否正在进行物理读取而不是逻辑读取。也许mem的不同之处在于保持数据集不适合辅助内存但不适合主机。
答案 2 :(得分：0)
是内存缓存中的数据了吗？还是全部从磁盘读取
答案 3 :(得分：0)
虽然您可能无法在32位服务器上使用AWE，但可以通过将/ 3GB开关添加到boot.ini文件来为SQL Server提供更多内存。查看联机丛书，它应该为您提供更多信息。