4

相关技术：SQL Server 2008 R2 RAID 5 (4 disk) Windows Server 2008

首先，我们的 RAID 5 阵列有一个磁盘部分故障。未检测到故障，但在周末意外断电和 UPS 发生故障后，驱动器指示灯周期性地呈琥珀色闪烁（稳定的琥珀色表示驱动器故障）。停电发生在星期六，在注意到“PAGEIOLATCH_SH”错误并阅读SQL Server 中的 PAGEIOLATCH_SH 等待类型是什么？（除其他外）。我们已经更换了驱动器并让它重建，但我仍然看到错误。

该查询通过一个在基础表上具有多个索引的视图来针对一个大表。我重建了索引，重新保存了视图以期获得更好的执行路径，并简化了查询。什么都没有解决这个问题。该查询自 2006 年以来一直运行没有问题，升级到 SQL Server 2008 或 R2 也没有问题，这两者在首次可用时都已应用。

最初执行计划显示出相当均匀的分布，但现在它显示在第二项“排序（Distinct Sort）”上占多数，在Index Seeks中分配了大约30％。过去的时间在 2 到 10 秒之间，但现在超过 2 分钟。

在这一点上，我不确定如何找出导致问题的原因。我认为要么是我没有找到损坏的数据，要么是查询已将自身重新优化为远非最佳的东西，或者 RAID 出现问题而不会发出任何灯或警告。

我已经完成了 PAGEIOLATCH_SH 和类似问题通常需要的操作，并且索引不仅看起来正确，而且到目前为止已经工作了多年。我还尽我所能确保驱动器正常工作。我的问题基本上是在这种情况下如何诊断问题的根源？

编辑：发现服务器实际上并没有因停电而关闭，但它旁边的机架却发生了。不知道为什么驱动器部分故障，但在这一点上，它似乎与中断是巧合的。

4

1 回答 1

4

你看到很多小PAGEIOLATCH_SH的等待，还是很少的大等待？

select * from sys.dm_os_wait_stats
where wait_type = 'PAGEIOLATCH_SH';

确切的结果是什么（计数、总等待时间、最大等待时间）。

许多小的等待表明查询计划发生了变化。将查询的逻辑读取数与基线数进行比较（如果可能）将证实这一点（逻辑读取数的增​​加）。此外，如果可能的话，比较计划将有助于隔离问题。

很少有大的等待表明确实存在驱动器问题（长时间等待 IO）。ERRORLOG 中记录的错误 833 将证实这一点 ( SQL Server has encountered ... occurrence(s) of I/O requests taking longer than ... seconds to complete)。

于 2011-05-31T19:00:08.383 回答