調查/故障排除 I/O 峰值

我們在支持生產 SQL Server 的 SAN 上遇到了一些相對較大的 I/O (IOPS) 峰值。

尖峰似乎在每小時之後的確切時間下降。我們已經調查了每個已知的計劃任務源（SQL 代理、備份、計劃的 SSRS 報告等），但到目前為止找不到任何規律或原因。

我們也使用了 Activity Monitor，但迄今為止它還沒有給出任何答案。

如何確定 I/O 峰值的來源？是否有有助於查明問題的監控工具（商業或其他）？

去年我遇到過幾次類似的問題，每次都是由於外部問題，通常是防病毒軟體配置不正確的排除項。我會檢查這個。

同時，以下查詢將讓您檢查來自 SQL Server 的物理 IO 級別：

SELECT a.io_stall, a.io_stall_read_ms, a.io_stall_write_ms, a.num_of_reads, 
a.num_of_writes, 
--a.sample_ms, a.num_of_bytes_read, a.num_of_bytes_written, a.io_stall_write_ms, 
( ( a.size_on_disk_bytes / 1024 ) / 1024.0 ) AS size_on_disk_mb, 
db_name(a.database_id) AS dbname, 
b.name, a.file_id, 
db_file_type = CASE 
                  WHEN a.file_id = 2 THEN 'Log' 
                  ELSE 'Data' 
                  END, 
UPPER(SUBSTRING(b.physical_name, 1, 2)) AS disk_location 
FROM sys.dm_io_virtual_file_stats (NULL, NULL) a 
JOIN sys.master_files b ON a.file_id = b.file_id 
AND a.database_id = b.database_id 
ORDER BY a.io_stall DESC 

特別注意 IO_Stalls、Reads 和 Writes。此查詢來自連結

好吧，這裡可能會是一個有點爭議的建議，但是您是否考慮過執行伺服器端跟踪來監控高讀取或寫入？您只需要在已知的問題發生時間附近安排一次和幾分鐘，然後您就可以開始查詢問題了。公平地說，這也應該在 Activity Monitor 中被選中，因此如前所述，可能是您的 IO 問題與 SQL Server 無關。至少如果它沒有出現任何問題，您可以將此作為證據提供給您的 SAN 管理員。

另外，您使用的是什麼版本的 SQL Server？如果是 2008 年或 2012 年，您可以使用擴展事件來執行此操作，這將比伺服器端跟踪更輕量級。

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