非常慢的硬盘性能

我怀疑RAID5是主要的罪魁祸首。 每个块写入你的数组可能会导致一个读取，然后两个写 – 充其量（如果额外的块已经读入caching），这将是两个写。 最重要的是，如果您的事务日志和数据文件位于同一个arrays上，则每次写入数据库时​​都会执行两次写操作（一次写入日志，一次写入数据文件） – 而家庭系统则是这种情况所以在你自己的比较中不会有太大的差异，否则就会增加任何性能上的差异。

您的家庭驱动器可能已打开其caching，这将有助于通过稍微重新sorting写入，以减less头部移动来提高性能。 开启预读可以帮助您减less与写操作的争用，但这取决于您的查询强加的确切的I / O模式。

出于写入性能的原因，RAID10通常build议用于数据库而不是5。

当你说“相同的数据” – 是一个系统运行从另一个备份和恢复的数据库？ 如果这两个数据库的历史有所不同，则可能是较慢的一个需要更新其索引统计信息（意外的查询速度问题可能是bas统计信息导致查询规划人员select不太理想的path的结果否则会）。

另外，在这两种环境下，您的CPU /内核数量是否一样？ 前一段时间，我看到SQL Server 2000在使用两个CPU时要花费较长的时间来运行磁盘瓶颈查询，而不是在使用这个CPU时要花费更长的时间。我推测，因为它试图将负载分成两个CPU，由于两个线程从磁盘上的不同位置一起读取而造成的I / O争用（我最近没有见过这种情况，所以它可能是该版本+ SP中的一个错误，但是它可能是值得的如果您在低核心环境中提供明确的索引提示（如果查询计划人员可以select更适合于额外的核心，或尝试手动重新优化提示），请尝试将其删除。

直写式caching可能是一个性能问题。 每次写入caching必须立即写入磁盘。 写回caching可以等待将数据写入磁盘的最佳时间。 根据硬件的不同，这可能需要电池备份（在arrays控制器上），并且如果电池不存在或需要更换，某些控制器会禁用写入caching。 您可能需要validationarrayscaching是否已启用。 一些控制器不会使这一点非常明显。

我们的BI数据集市有严重的IO问题。 根据惠普的支持，我发现有人安置了configuration在RAID 5中的硬盘驱动器，并重新构build了奇偶校验。 我仍然不知道开始重build的是什么。

造成这么多的麻烦，但一旦重build完成，我的performance回来了。 这可能不是最有洞察力的答案，但这是你应该考虑的问题之一。