不存在的数据库的数据库 ID - 超时等待出现在错误日志中的页面上的缓冲区闩锁

Question

背景： 我最近开始在一家拥有许多不同州的数据库的新商店。我今天早上到达（刚刚被添加到 SQL DBA 邮件组）找到一封关于昨晚在其中一台服务器上失败的 CHECKDB 作业的电子邮件（我被警告过有问题）。

我不会在这里详述这件事的细节，它似乎归结为等待缓冲区锁存器的一些超时 - 就其本身而言，很难说出为什么会这样，因为应该有（并且似乎有一直）昨晚运行时很少使用系统。

日志中持续存在超过 15 秒的 I/O 请求问题，并且 vmware 人员说存储存在通信问题（持续的网络问题），所以这在某种程度上解释了我认为的问题。

重要提示：我今天早上重新运行了 CHECKDB，它完全很快，发现了 0 个错误，据我所知，自从昨晚失败以来没有发生任何事情，所以（如果我错了，请纠正我），我在那里非常有信心没有数据库问题，昨晚是一个异常，可能是由网络或存储问题引发的（当网络人员回复我时，我会了解更多关于这个......如果他们这样做的话）。

实际点： 在日志中，就在昨晚的 CHECKDB 作业失败的地方，等待缓冲区闩锁的超时 - 对我来说奇怪的是它应该尝试的页面的数据库 ID闩锁是 11，并且实例上没有具有该 ID 的数据库 - ID 最多只能达到 10。

接下来是 CHECKDB 行，发现 1 个错误，修复了 0 个，指向具有分割点的内部数据库快照（请参阅下面的错误日志）

具体问题：

1. 为什么会有对不存在的数据库 ID 的引用（内部数据库快照是否在某个时候被分配了一个数据库 ID，这就是它所指的内容）？
2. 有没有办法找出有问题的数据库快照是什么（这与 CHECKDB 的工作方式有关，还是其他原因）？
3. 有没有办法找到有问题的快照发生了什么（因为当我今天早上再次运行 CHECKDB 时，这显然不是问题）。

错误日志：

01/04/2017 23:50 spid101 Unknown DBCC CHECKDB (zenworks_UAL) WITH no_infomsgs 由 ARTSLOCAL\svc_zcmsql 执行发现 1 个错误并修复了 0 个错误。已用时间：0 小时 28 分 51 秒。内部数据库快照具有分割点 LSN = 00adf51f:00019bf4:0001 和第一个 LSN = 00adf51f:00019bf3:0001。

01/04/2017 23:50 spid101 未知 无法读取和锁存页 (1:2067184)，锁存类型为 SH。闩锁失败。

01/04/2017 23:50 spid101 未知错误：8966 严重性：16 状态：2。

2017 年 1 月 4 日 23:50 spid101 未知等待缓冲区闩锁时发生超时 -- 键入 2 bp 00000004FFFF4A80 页 1:2067184 stat 0xc2040d数据库 ID：11分配单元 Id：0/276006080708070607080708060708080806080808080876180878067080880878008780806718088088080 0x100000001a 拥有任务 0x000000015BA6A088。没有继续等待。

注意： 据了解，在昨晚的故障和我今天早上运行 CHECKDB 之间，没有其他人在使用数据库或运行任何重要的东西。该系统正在使用中，但并不显着。日志中没有显示任何内容。

确认一下，没有 ID 11 的数据库，而且我认为从来没有（而且我可以肯定，在昨晚和今天早上之间我不能

询问：

SELECT db_name(11)

结果：

NULL

询问：

SELECT * FROM sys.databases

结果：

????????????????????????????????????
?        name        ? database_id ?
????????????????????????????????????
? master             ?           1 ?
? tempdb             ?           2 ?
? model              ?           3 ?
? msdb               ?           4 ?
? ReportServer       ?           5 ?
? ReportServerTempDB ?           6 ?
? z_xxxxxx_L         ?           7 ?
? z_xxxxxx_p         ?           8 ?
? S_xxxxxx_t         ?           9 ?
? z_xxxxxx_t         ?          10 ?
????????????????????????????????????

Answer 1

此问题是主机上大量 I/O 的典型症状。也许此时 SAN 上正在发生多个备份、DBCC 和其他“维护”活动。

\n\n

与您的 VMware 人员合作，确保 SQL Server VM 使用适用于 VM 中存在的 LUN 的 PVSCSI 适配器。VMware 的SQL Server 最佳实践文档对 SCSI 适配器有这样的描述：

\n\n

\n

利用 VMware 半虚拟化 SCSI (PVSCSI) 控制器作为数据和日志 VMDK 的虚拟 SCSI 控制器。

\n\n

PVSCSI 控制器是适用于 vSphere 上 I/O 密集型应用程序的最佳 SCSI 控制器。默认情况下，该控制器的队列深度为 64（每设备）和 254（每控制器）（LSI Logic SAS 控制器大小的两倍）。每个设备和每个控制器的 PVSCSI 控制器\xe2\x80\x99 队列深度也可以分别增加到 254 和 1024，从而为虚拟化工作负载提供更多的 I/O 带宽。请参见配置磁盘以使用 VMware 准虚拟 SCSI (PVSCSI) 适配器 (1010298)。

\n\n

另请参阅如何增加 VMware vSphere 环境中的队列深度。

\n\n

笔记：
\n 虽然增加虚拟 SCSI 控制器的默认队列深度对基于 SQL Server 的 VM 有利，但如果配置不当，该配置也可能会对整体性能产生意外的不利影响。

\n\n

VMware 强烈建议客户咨询并与适当的存储供应商\xe2\x80\x99s 支持人员合作，评估此类更改的影响，并获取支持虚拟 SCSI 控制器队列深度增加所需的建议或其他调整。

\n

\n\n

使用多个 vSCSI 适配器。将操作系统、数据和事务日志放置到单独的 vSCSI 适配器上，可以通过在多个目标设备之间分配负载并允许操作系统级别上有更多队列来优化 I/O。\n将 I/O 负载分散到所有 PVSCSI 适配器上，以帮助优化来自访客的 I/O。在需要许多数据和事务日志磁盘的情况下，将操作系统启动磁盘设置为也使用 PVSCSI 会很有帮助。

\n\n

我会检查 SQL Server 默认跟踪以查看 DatabaseID 11 是否显示。

\n\n

这会将默认跟踪读取到临时表中：

\n\n

DECLARE @trcfilename VARCHAR(1000);\n\nSELECT @trcfilename = path \nFROM sys.traces \nWHERE is_default = 1;\n\nIF OBJECT_ID(N\'tempdb..#trctemp\', N\'U\') IS NOT NULL\nBEGIN\n    DROP TABLE #trctemp;\nEND\n\nSELECT *\nINTO #trctemp\nFROM sys.fn_trace_gettable(@trcfilename, default) tt;\n

\n\n

这将显示任何跟踪事件DatabaseID = 11。

\n\n

SELECT tt.DatabaseID\n    , tt.DatabaseName\n    , tt.StartTime\n    , tt.HostName\n    , tt.LoginName\n    , tt.ApplicationName\n    , te.name\nFROM #trctemp tt\n    LEFT JOIN sys.trace_events te ON tt.EventClass = te.trace_event_id\nWHERE tt.DatabaseID = 11 --missing database ID\nORDER BY tt.StartTime DESC;\n

\n\n

DBCC CHECKDB (db_name)将创建数据库的内部快照。您可以将快照文件视为附加到实际数据库文件的 NTFS 备用数据流。所以，如果你跑到dir C:\\some\\path /r哪里C:\\some\\path，您将看到如下列出的内部数据库快照文件：

\n\n

2018-03-29 03:06 PM 402,653,184 Test_DB.mdf\n 402,653,184 Test_DB.mdf:MSSQL_DBCC25:$DATA\n

\n\n

在上面的示例中，您可以看到我有一个包含名为Test_DB.mdf. 还有一个名为 的备用数据流Test_DB.mdf:MSSQL_DBCC25:$DATA。通过关联中的现有数据库 ID sys.databases，我可以推断出25DBCC25是快照的数据库 ID。

\n