今天早上醒来，我们的群集已关闭。它马上回来了。我发现日志错误日志的条目有关IO的时间超过15秒。我们的监控服务器试图ping服务器并发生超时错误。
我检查了一个监控工具，看看早上4:30发生了什么。似乎是在我们的一个大型数据库上更新了统计数据。该工具显示我们的磁盘已被最大化。我看到其中一个磁盘的繁忙时间非常高。
现在，sqlagent正在按字母顺序逐步完成其他所有数据库。我们确实有自动更新统计信息 - 但我认为这是根据需要进行的。我现在没有启用任何统计更新作业（我知道 - 并且作业监视器没有显示任何正在运行的作业），所以我不确定是什么造成这种情况。
http://support.microsoft.com/default.aspx?scid=kb;en-us;195565 - 证实了我对自动调节器所需性质的看法。
同样的事情也发生在昨晚6:30左右 - 在同一个大型数据库 - 一些精选的统计员来自...陈述。
磁盘位于SAN上，我们正在运行最新版本的sql 2005.
答案 0 :(得分：0)
如果你得到15秒io错误，我会在较低级别开始诊断，检查最近是否更新了与io相关的驱动程序，例如Powerpath emulex等。当我在错误的io子系统之前遇到此错误并且不是直接SQL时，那就是使磁盘处于负载状态并显示问题的组件。
答案 1 :(得分：0)
15秒错误并不总是正确的，有时是由CPU时间漂移引起的，请参阅Event ID 833: I/O requests taking longer than 15 seconds。验证I / O请求确实花费了那么长时间（注意OS perfmon计数器遭受同一时间漂移问题）。
过时的统计数据是每个人都喜欢的，并且首先要归咎于任何性能问题，但实际上它们很少是根本原因。可以通过调查问题查询的执行计划来诊断错误的统计信息，它们显示为估计的行数与范围和扫描运算符上的实际行数之间的显着差异。
如果您认为必须每晚进行完整的更新统计（我怀疑），那么必须规划您的I / O子系统以支持所需的容量，如果数据库很大，则必须读取具有完整扫描的更新统计信息整个数据库一次，所以要做出相应的计划，包括从SAN到SQL的I / O带宽。