執行 DBCC TRACEON (3502, 3504, 3605, -1) 時如何解釋日誌

我一直在使用 DBCC Traceon（3502、3504、3605、-1），因為在部落格中推薦它用於發現與 I/O 相關的性能問題。我正在執行 MS SQL Server 2008 R2 SP1

我的 SQL 日誌文件中的結果看起來像這樣（數字有點捏造）：

即將記錄檢查點結束

最後一個目標未完成 2，avgWriteLatency 40ms

平均吞吐量：0.67 MB/秒，I/O 飽和度：79，上下文切換 201

FlushCache：在 1447 毫秒內用 69 次寫入清理了 125 個 Buf（避免了 0 個新的髒 buf）

ckpt dbid 9 第一階段結束 (8)

即將開始記錄檢查點。

我真的不知道如何閱讀這篇文章，或者以一種我從中得到任何真正有意義的方式來分解它。

“最後一個目標未完成”是什麼意思？

平均寫入延遲是否意味著每次寫入所需的成本時間？或寫入之間的時間？40ms 似乎很高，物理驅動器是 1TB，並且配置了 RAID5。

什麼是 I/O 飽和度？

它與上下文開關有什麼關係。我假設上下文切換與多任務處理有關。在作業/寫入之間切換。

刷新記憶體。我意識到這與清除記憶體有關。什麼是BUF？這些數據頁需要寫入嗎？什麼是骯髒的Bufs？為什麼要避免它們？

詳細的細分將不勝感激。

您打開的跟踪標誌將告訴您檢查點在幕後做什麼。

• 3502：當檢查點開始和結束時寫入錯誤日誌
• 3504：寫入關於寫入磁碟的內容的錯誤日誌資訊
• 3605：允許跟踪列印到錯誤日誌

有關上述內容的更多詳細資訊，請參閱 Paul Randall 的部落格文章。此外，Fine Tuning for Optimal Performance有一個很好的資訊——尤其是在 Search of Spikes部分。

一些真正的內部閱讀：

1. 工作原理：何時將 FlushCache 消息添加到 SQL Server 錯誤日誌？
2. 工作原理：SQL Server 檢查點 (FlushCache) 未完成的 I/O 目標
3. SQL Server 檢查點問題

我建議您不要直接關注檢查點行為，而是查看 DMV 和 Perfmon（與磁碟相關）-

1. sys.dm_io_virtual_file_stats
2. 物理磁碟對象：平均。磁碟隊列長度
3. 平均 磁碟秒/讀取
4. 平均 磁碟秒/寫
5. 物理磁碟：%磁碟時間
6. 平均 磁碟讀取/秒
7. 平均 磁碟寫入/秒

您可以參考調查 I/O 瓶頸

引用自：https://dba.stackexchange.com/questions/44899