背景
我收到了来自 SQL Profiler 的跟踪日志,该日志在我们托管 SQL 的服务器上运行 15 分钟的时间范围内经历了 100% CPU 占用的情况。我将这些文件导入到名为 的表中TraceTable
。我确实找到了一些与审核注销无关的可能原因,但是,最重要的结果来自审核注销,我想了解为什么读/写/CPU 仅在 15 分钟内如此高。
研究
我读到审核注销的持续时间是涉及时间峰值的一些因素,而不仅仅是跟踪时间范围内的时间。
但我找不到任何东西来解释高读/写/CPU,除了一些一般性的说法,审计注销通常不是性能问题的原因。我还找到了一个答案,它说 CPU 利用率是累积的,就像持续时间一样,但是答案中链接的文章没有明确说明答案所说的内容。我想验证这与我们看到的性能问题无关。
为什么审核注销会显示这些相关统计数据?
这是我运行的查询:
SELECT TOP 100
COUNT(*) AS TotalExecutions,
EventClass,
CAST(TextData as nvarchar(2000)) AS Query ,
SUM(Duration) AS DurationTotal ,
SUM(CPU) AS CPUTotal ,
SUM(Reads) AS ReadsTotal ,
SUM(Writes) AS WritesTotal
FROM
TraceTable
GROUP BY
EventClass,
CAST(TextData as nvarchar(2000))
ORDER BY
CPUTotal DESC
这是最佳结果:
(抱歉,我无权访问 SQL 实例,所以我不知道确切的版本。可以安全地假设它至少是 2014 年,可能更新)
Audit: Logout 上的持续时间、CPU、读取次数等是会话的总计。这是有明确记录的。
因此,这些总计包括该会话过程中生成的其他事件的所有值。