我在 Azure 中有一个 SQL 托管实例，其中发生了一些阻塞/死锁。此数据库位于本地，并且安装了所有脚本，因此我卸载了它们，然后安装了 Azure 特定脚本 (Install-Azure.sql)，这些脚本是从 Brent Ozar 的网站最新下载的。
除了 sp_blitzlock 之外，所有脚本似乎都运行正常。SpBlitz 确实确认了“平均每天有 94 个死锁。要找到它们，请运行 sp_BlitzLock。”
我以系统管理员身份运行它，两个主表都是空白的。（当我以我的 EntraID 帐户运行它时，我遇到了权限问题：消息 50000，级别 11，状态 1，过程 sp_blitzlock，行 335 [批处理启动行 0] 名为 system_health 的会话不存在或当前不活动。
当我以实例 sysadmin 身份运行它时，我没有收到任何错误。数据只是空白。可能没有数据，但考虑到我们在其他地方观察到的情况以及 sp_blitz 确认的情况，我对此表示怀疑。
我下载了最新的 First Responder Kit，并使用 sp_BlitzLock 版本 8.21 和 sp_Blitz 版本 Jul 1 2024 12:00AM。这是 Azure 中的 SQL 托管实例，实例版本为 12.0.2000.8。我只是在 SSMS 中执行 sp_blitzlock; 来运行它。
值得一提的是，我们最近将服务层从“通用”升级到了“业务关键”。这总体上提高了性能和锁定，但我想知道它是否在后台触发了一个新实例，这就是为什么没有出现死锁数据的原因。（但是为什么它会出现在 sp_blitz 中？）
有什么想法吗？
微软讨厌你
从 Azure SQLDB 或托管实例中读取事件文件会给坐位区域（也称为 Sparkling Derriere）带来巨大的、巨大的、令人厌恶的痛苦。
因此，
sp_BlitzLock只能从扩展事件ring_buffer的一部分可靠地获取数据system_health。由于这是内存中的（孩子们说的，是短暂的），它可能会在不合时宜的时候清除，并且您可能无法从中获取所需的数据。您可以尝试设置
sp_BlitzLock一个代理作业来运行并定期轮询有用内容，并将这些内容推送到表中进行适当消化。但是，如果在清除内存后运行，它仍可能会错过一些内容。