上周六晚上,我们的网站宕机了大约 10 分钟。日志分析显示,在中断期间而非中断之外,主要 SQL Server(在镜像对中)出现以下错误:
- 2015 年 6 月 6 日 23:14:41,spid [各种],未知,等待闩锁时发生超时:类“ACCESS_METHODS_DATASET_PARENT”id [各种] 类型 4 任务 [各种]:[各种] 等待时间 300 标志 0x1a 拥有任务 [各种各样的]。继续等待。
- 06/06/2015 23:06:54,spid19s,未知,等待页面 (5:159076157) 数据库 ID 6 的缓冲区闩锁类型 3 时发生超时。
- 06/06/2015 23:06:54,spid19s,未知,错误:845 严重性:17 状态:1。
- 06/06/2015 23:06:54,spid19s,未知,等待缓冲区闩锁时发生超时——键入 3 bp 0000000518FA1200 页 5:159076157 stat 0xc0000b 数据库 ID:6 分配单元 ID:72057793340899328 任务 0x0000000518FA1200:0x0000007000等待时间 300 标志 0x100000001a 拥有任务 0x0000000004472BC8。没有继续等待。
第一个错误有一百多个,大部分是在其他错误之前,但也有在其他错误之后,只发生一次。这些错误发生在执行故障转移、应用操作系统更新并故障恢复到原始服务器后约 2 小时。我们已经在这些服务器上运行了大约 2 年,从未见过这个问题。调用服务器的软件最近一次更新是在周四下午(中断前约 55 小时)。
我在这里或通过谷歌发现关于此超时的信息很少。我发现的最接近的是这个问题的第二个答案:https ://stackoverflow.com/questions/3149310/time-out-occurred-while-waiting-for-buffer-latch-type-2-error-in -sql-server,它讨论了与 tempdb 相关并由 2008 年的错误引起的类型 4 闩锁错误,但该错误在 2009 年已解决,即 2008 R2 发布之前。确切的版本报告为:
Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64)
Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)
这些服务器都使用镜像的 Intel Enterprise SSD 来处理所有事情(数据使用双 RAID 10 阵列),并且没有一个驱动器报告问题。tempdb 卷有 200GB 空闲空间。有 20 个 tempdb 文件(这是一个大服务器)。由于对架构、存储过程和调用 SQL 的软件进行了优化,SQL 流量较一年前的峰值大幅下降,因此这可能不是与负载相关的问题。
类型 4 是否确实像许多帖子所表明的那样与 tempdb 相关(错误消息中引用的数据库 6 是我们的主数据库,而不是 tempdb)?我能做些什么来防止这个问题再次发生?