我对 Azure SQL 数据库的 WaitStats 分析显示 WRITELOG 和 HADR_SYNC_COMMIT 作为计数器的最高等待。这是一个 Premium 250 eDTU 资源。
脚本
SELECT TOP (10) wait_type,
CAST (([wait_time_ms] / 1000.0) AS DECIMAL (16, 2)) AS [WaitS],
CAST (100.0 * [wait_time_ms] / SUM([wait_time_ms]) OVER () AS DECIMAL (16, 2)) AS [Percentage]
FROM sys.dm_db_wait_stats
ORDER BY [Percentage] DESC;
我在 AZure SQL 数据库中找不到很多关于如何解决这个问题的信息。
任何帮助表示赞赏。
谢谢
WRITELOG 正在等待提交以将事务的日志记录硬化到磁盘,而 HADR_SYNC_COMMIT 正在等待提交以将事务的日志记录通过网络发送到辅助副本并硬化到磁盘。所以他们是非常非常相似的等待。
两者都表明您的应用程序正在提交大量事务,可能太多了。
而且,您的日志文件位于本地闪存驱动器上,延迟非常低,因此遭受大量 WRITELOG 等待表明您的应用程序中需要修复一些问题。
如果您有任何进程在紧密循环中运行单行的 INSERT、UPDATE 或 DELETE,请考虑将它们包装在显式事务中,这样您只需等待事务日志在最后刷新。
与往常一样, Query Store是您的朋友,可以通过查询向您显示等待,您也可以在sys.dm_exec_session_wait_stats中按会话分析等待,以查看工作负载的哪些部分正在遭受这些等待。
通过将会话经过时间和 cpu 时间与等待时间进行比较,您可以更好地了解客户端等待的时间。例如