我们有一个带有最新 CU 的 SQL Server 2016 SP2 Enterprise，数据库文件分布在不同的磁盘上。
所以我们有数据、日志、临时数据库和系统数据库，它们都有自己的驱动器。日期和日志只包含一个文件。
这些驱动器在全闪存 SAN 上都有自己的 LUN。
为了监控延迟，我每 15 分钟捕获sys.dm_io_virtual_file_stats一次，然后使用之前的快照计算延迟。
对于写入延迟，我使用以下计算：
(io_stall_write_ms - lag (io_stall_write_ms,1,0) over (order by checkdate))/(num_of_writes - lag (num_of_writes,1,0) over (order by checkdate)) write_latency
我的平均写入延迟为 10 毫秒，但是当我启动 perfmon（持续时间设置为 900 秒）并监控平均值时。同一驱动器在同一时间段内的磁盘秒/写入平均写入延迟仅为 3 毫秒。
我还在捕获同一时期的等待统计信息，当我查看 PAGEIOLATCH_EX 等待并计算每次等待所用的时间时，我也得到了大约 3 毫秒的值。
我认为 io_stall_write_ms 表示与 avg 相同。磁盘秒/写还是我错过了什么？
有人可以解释这种行为吗？
我认为你关于这两个数字应该匹配的结论是公平的。写入延迟的测量应该提供与“逻辑磁盘”➡“平均磁盘秒/写入”性能计数器
sys.dm_io_virtual_file_stats类似的数字。确保您尽可能地比较“苹果与苹果”。该 Perfmon 计数器的默认设置是向您显示所有磁盘的延迟，因此请确保您选择了您感兴趣的磁盘（而不是“Total”）：
同样，在 SQL Server DMV 端，请确保您只聚合和比较同一磁盘上文件的数据。这
sys.dm_io_virtual_file_stats是为您提供每个文件的数据，这些数据可能跨多个磁盘。可能只是不同测量方式之间的采样率差异导致了问题。例如，您每 15 分钟获取一次 DMV 数据。但大概您正在查看默认 Perfmon 的实时输出，它将显示 100 秒内的平均值。可能只是在 15 分钟间隔内存在异常值，导致 DMV 的平均值高于您在 Perfmon 中看到的平均值。要尝试排除这种情况，您可以（至少暂时）更频繁地对虚拟文件统计信息进行采样，以查看数字是否匹配得更好。
我预计，根据您在 Perfmon 和等待统计中看到的与延迟相关的较低值，您不会主动遇到磁盘延迟问题，您只是对从不同工具获得的差异测量感到好奇。
如果您遇到问题，您可能需要更深入地了解“SQL Server 和磁盘写入之间发生了什么”。微软高层 Sean Gallardy 在这里非常深入地讨论了这一点：慢速检查点和 15 秒 I/O 警告对闪存存储
在阅读了 Sean Gallardy 的帖子后，我使用 Perfmon 设置了 StorPort 跟踪。如何配置您在此处找到的跟踪并使用StorPort-Trace-Reader分析结果。
结果表明确实存在一些延迟。
接下来，我使用Windows Performance Recorder来跟踪“Minifilter I/O 活动”。使用Windows 性能分析器，我发现病毒扫描程序造成了麻烦，即使在进行排除时，也花了很多时间在这些微过滤器上。
卸载病毒扫描程序后，问题得到解决。现在我们正在搜索病毒扫描程序导致问题的原因。