每秒異常高的寫入次數
我在我們的一個 OLTP 伺服器上遇到了一些非常奇怪的行為。只是為了提供一些背景知識，我們有一個“OLTP”，它有許多大而寬的表。我們有 560 個表，其中有 100 多個列，不幸的是，由於它是一個外包應用程序，我對數據庫設計幾乎無能為力。
因此，下圖顯示了每秒的頁面讀取和寫入。在凌晨 4 點左右，我們有一個很大的讀取峰值，這是我們知道的 Qlikview 的負載。但是，頁面讀取總體上往往偏低，我認為它們仍然高於每秒 90 頁的門檻值，但與寫入相比問題不大。另一方面寫入，因為圖表顯示的值高於每秒 500 頁的正常實例要高得多。
自 2018 年 10 月 15 日以來，對於絕大多數數據擷取間隔，以下內容已適用
- 其中 Lazywrites per second 大於 1。
- 頁面預期壽命通常也很高。我們確實有在我們知道的早上（凌晨 4 點）值下降的情況，但是除了奇怪的例外，我們幾乎總是高於建議的門檻值 7500 秒（記憶體/4）*30。
- Buffer Cache Hit Ratio 也非常健康，達到或接近 99%。
- 最後，我們幾乎沒有任何與記憶體相關的等待，Resource_Semaphore 為 0 秒，CMEM_THREAD 自 2018 年 10 月 27 日以來累積了 60 秒。
- Memory grants pending 的值為 0，Memory grantsstanding 為 1，數據自 2018 年 10 月 27 日起收集。
在我看來，這些因素排除了記憶體壓力是一個問題，但我似乎無法解釋每秒寫入次數的奇怪峰值。在我看來，這與我們的數據庫設計有關。我們確實有非常寬的表，可以經常插入/更新/刪除。我們還有許多數據類型低效的寬索引。
從我提供的數據和圖表來看，是否有跡象表明他們的高寫入歸因於什麼，或者有什麼指標可以用來解釋峰值？
版本：
Microsoft SQL Server 2014 (SP2-GDR) (KB4019093) - 12.0.5207.0 (X64)
Jul 3 2017 02:25:44 版權所有 (c) Microsoft Corporation Standard Edition (64-bit) on Windows NT 6.3 (Build 9600:) (管理程序）
數據源
- 上圖取自 solarwinds，我假設的數據是從 sys.dm_os_performance_counters 收集的
- 我引用的所有其他計數器數據都來自 sys.dm_os_performance_counters，以定期間隔擷取，等待統計數據取自 sys.dm_os_wait_stats。
謝謝
從開源sp_BlitzCache開始（免責聲明：我是該項目的維護者。）它是一個腳本，可以分析您的記憶體執行計劃以找到最佔用資源的計劃，然後告訴您這些查詢中的設計問題。您不必提前進行任何設置 - 只需安裝 sp_BlitzCache 然後執行它：
sp_BlitzCache @SortOrder = 'writes'滾動結果集，直到到達“Writes”列：
這將向您顯示哪些查詢的寫入次數最多。您可以向後滾動到左側以查看查詢、它們的執行計劃和它們的反模式警告，然後與您的開發人員一起改進它們。（或者它們可能是完全正常的：例如，根據您的指標，這可能只是有人將數據記錄到表中的情況。）
是否有任何跡象表明他們的高寫入歸因於什麼，或者有什麼指標可以用來解釋峰值？
頁面寫入只是表明數據庫正在被更改。
對行的每個更改最終都將包含在頁面寫入中，由 Lazy Writer 和 Checkpoint 程序在後台處理。
糟糕的數據庫設計會影響寫入的行與寫入的頁面的比率不同。IE 如果您要插入到具有隨機 GUID 上的聚集索引的表中，則每一行將被插入到不同的頁面上，可能每行需要寫入一頁。