相关技术： SQL Server 2008 R2 RAID 5（4个磁盘） Windows Server 2008
首先，我们的RAID 5阵列有一个磁盘部分失败。没有检测到故障，但在周末意外断电和UPS故障后，驱动器灯定期闪烁琥珀色（稳定的琥珀色表示驱动器故障）。停电发生在星期六，我发现灯光星期二发现“PAGEIOLATCH_SH”错误并阅读帖子What is PAGEIOLATCH_SH wait type in SQL Server?（等等）。我们已经更换了驱动器并让它重建，但我仍然看到错误。
查询是通过一个视图对一个大表，该视图在底层表上有几个索引。我重建了索引，重新保存了视图，希望有更好的执行路径，并简化了查询。什么都没有解决问题。该查询自2006年以来一直没有问题，并且在升级到SQL Server 2008或R2时没有任何问题，这两个问题都是在它们首次可用时应用的。
最初执行计划显示了相当均匀的分布，但现在它显示了第二项“Sort（Distinct Sort）”的大多数，在Index Seeks中有大约30％的分配。过去的时间在2到10秒之间，但现在超过2分钟。
此时我不确定如何隔离导致问题的原因。我认为它或者是我找不到的损坏数据，或者是查询已经将其自身重新优化为远非最佳状态，或者RAID没有引发任何灯光或警告。
我已经完成了PAGEIOLATCH_SH和类似问题通常需要的东西，索引不仅看似正确，而且到目前为止已经工作了多年。我也做了我知道要做的一切，以确保驱动器正常工作。我的问题基本上是如何在这种情况下诊断问题的根源？
编辑：发现服务器实际上并没有断电，但旁边的机架确实没电了。不确定为什么驱动器部分失效，但在这一点上似乎是中断的巧合。答案 0 :(得分：3)
你看到很多小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）。