1

从阅读中，我可以看到Work_Queue可以安全地忽略等待，但我没有找到太多关于logcapture_wait. 这来自 BOL，“等待日志记录可用。在等待连接生成新日志记录或读取不在缓存中的日志时等待 I/O 完成时可能发生。如果日志扫描赶上日志的末尾或正在从磁盘读取。”

两个 SQL Server 的平均磁盘秒/写入基本上为 0，所以我猜这种等待类型可以安全地忽略吗？

以下是主要的前 10 次等待：

wait_type   pct running_pct
HADR_LOGCAPTURE_WAIT    45.98   45.98
HADR_WORK_QUEUE 44.89   90.87
HADR_NOTIFICATION_DEQUEUE   1.53    92.40
BROKER_TRANSMITTER  1.53    93.93
CXPACKET    1.42    95.35
REDO_THREAD_PENDING_WORK    1.36    96.71
HADR_CLUSAPI_CALL   0.78    97.49
HADR_TIMER_TASK 0.77    98.26
PAGEIOLATCH_SH  0.66    98.92
OLEDB   0.53    99.45

以下是次要等待的前 10 名：

wait_type   pct running_pct
REDO_THREAD_PENDING_WORK    66.43   66.43
HADR_WORK_QUEUE 31.06   97.49
BROKER_TRANSMITTER  0.79    98.28
HADR_NOTIFICATION_DEQUEUE   0.79    99.07
4

2 回答 2

2

不要通过查看总等待时间来解决服务器上的问题。如果您想解决导致问题的原因，那么您需要查看当前的等待。您可以通过查询 sys.dm_os_waiting_tasks 或获取所有等待（如您在上面所做的那样），等待 1 分钟，再次获取所有等待，然后减去它们以查看在那一分钟内实际发生的等待。

有关更多信息，请参阅我所做的网络广播：使用 DMV 进行故障排除

除此之外，HADR_LOGCAPTURE_WAIT 是一种后台等待类型，不会影响任何正在运行的查询。你可以忽略它。

于 2013-08-04T00:35:51.873 回答
0

不，您不能简单地忽略“HADR_LOGCAPTURE_WAIT”。当 SQL 正在等待生成一些新的日志数据或尝试从日志文件中读取数据时存在一些延迟时，就会发生这种等待类型。日志文件上的内部和外部碎片或缓慢的存储也可能导致这种等待类型。

于 2016-07-19T16:55:39.700 回答