我们正在迁移到功能强大的新 SQL Server（12GB RAM、2 个 4 核 CPU、12 个 15k rpm 驱动器、Gbit 网络）。我们将驱动器分为 4 个分区，分别用于操作系统、数据、日志和全文索引文件。
问题如下：我正在运行一个作业，该作业从单线程控制台应用程序执行 36k 次搜索（表和全文连接的组合）。但服务器并没有给我们的服务器带来负担，而是记录了大约 5% 到 7% 的 CPU 负载，而不是我们旧服务器上的 +-60%。
从仪表板报告来看，我们唯一遇到的等待是偶尔的网络 IO 等待 - 但这种情况时有时无。所以看起来 SQL Server 正在限制我们的连接？
有人可以解释一下这个问题吗？
答案1
好吧，您可以尝试运行 Perfmon 和 SQL Profiler 来更深入地了解这一点。但首先，请告诉我们更多关于您的驱动器配置的信息。您说您有 12 个驱动器，分为 4 个分区。这是否意味着您制作了一个大的 RAID 阵列并将其分成 4 个实际的操作系统级分区，还是您制作了 4 个 RAID 容器，每个容器都有一个操作系统分区？前者是导致性能不佳的良方。
答案2
据我所知，SQL Server 2005 中唯一一个因任何原因限制连接的版本是 Express，而且只有在同时有“很多”连接时才会限制连接。不太可能有人在强大的服务器上安装 Express，也不可能单线程控制台应用程序有多个同时连接。
如果您的查询未并行化，则每个查询将仅在该机器的八个（2x4）核心中的一个上运行，从而实际上浪费了其他七个核心。
如果没有其他瓶颈（换句话说，您的查询所需的所有数据都缓存在 RAM 中，并且没有其他东西阻止查询），您的查询将占用一个核心的 100%。系统上一个“核心”的负载为 12.5%。如果您添加一点磁盘活动，这与您所看到的情况很接近。
当旧服务器达到 60% 时，可能是因为某种原因，旧服务器并行化了（至少一些）查询，而新服务器没有并行化任何查询。
我会使用 Perfmon 查看每个核心处理器的负载。我猜你会发现其中一个核心的负载为 100%，或者非常接近 100%。你可能会发现“繁忙”的核心从一个核心变为另一个核心。如果所有核心都同样繁忙，那么就会发生一些奇怪的事情。在这种情况下，我肯定会寻找数据库文件 I/O 上的等待情况。有一个 DMV 可以解决这个问题。
我还会使用 SSMS 查看应用程序执行的查询的至少一个示例的查询计划。有时，事情会突然出现（“嘿，那个索引去哪儿了？我以为我们在升级后把它放回去了”，或类似的东西。）。
总结：
- 确保您的索引统计信息是最新的。（如果可以，最简单的做法就是重新索引所有内容。）如果您在升级过程中从 SQL2000 升级到 SQL2005，这一点尤为重要。
- 查找阻塞。如果发现阻塞，要问的问题是“为什么这在旧系统上有所不同？”和“我现在如何最大限度地减少阻塞？”
- 如果您需要查询并行化，请确保友好的 DBA 没有将服务器的 MAXDOP 配置设置为 1（默认值为 0）。这可以在服务器级别配置。请参阅最大并行度无论设置如何，您都可以在查询中使用 MAXDOP 关键字强制查询并行化（或不并行化）。
- 查看这 36 个查询的查询计划。调整您的查询和表/索引。
- 重新设计单线程控制台应用程序，以在（可能）其他线程上的不同连接上运行不同的查询，以便您可以一次运行多个查询。 （这显然是最复杂和最不可取的事情，假设您甚至有源代码。）