[MSSQL_2016] Latch?

Hits: 233

跨年連假結束後，今天工作時主管發現，ETL process在假日碰到了這個問題

pyodbc.ProgrammingError: (‘42000’, ‘[42000] [Microsoft][ODBC Driver 13 for SQL Server][SQL Server]等候緩衝閂類型 3 (資料庫識別碼 2，頁>面 (6:5499840)) 時發生逾時。 (845) (SQLExecDirectW)’)

他在12/29 07:40執行時有問題，但是下午14:00執行時這個問題就消失了，希望我能解決這個問題。搜尋了一下之後，發現這應該是latch(緩衝閂) time out的關係，google後發現Microsoft有文件：

處理序正在等候取得閂鎖。造成這個問題的原因可能是由於 I/O 作業花費太多時間才完成。這種錯誤通常是其他工作封鎖了系統處理序所造成的結果。在某些情況下，這項錯誤可能是硬體故障的結果。

關鍵字：I/O作業花費太多時間

解決方法

1. 減少工作負載。
2. 查看錯誤記錄檔或事件記錄檔中相關聯的 I/O 失敗。I/O 失敗通常表示磁碟功能有問題。
3. 查看錯誤記錄檔，找出沒有產量的工作和其他重大錯誤。
4. 如果經常發生諸如判斷提示之類的重大錯誤，請解決這些問題。

竟然看起來是I/O太費時間，那就來找看看這段期間最費時的I/O吧，搜尋了一下，找到這段語法：

SELECT
    c.connect_time, 
    s.host_name, 
    s.login_name, 
    st.text, 
    c.last_write, 
    s.total_scheduled_time,
    s.total_elapsed_time
FROM        sys.dm_exec_connections c
INNER JOIN  sys.dm_exec_sessions s ON c.session_id = s.session_id
CROSS APPLY sys.dm_exec_sql_text(c.most_recent_sql_handle) AS st
where connect_time <= '2018-12-28'
ORDER BY    total_scheduled_time desc , connect_time desc

備註：這段查詢出來的結果，可以看出特定時間的query所佔時間，但無法將歷史的查詢紀錄通通列出，若要如此作，必須使用SQL Profiler或SQL trace，來記錄歷史查詢紀錄

執行結果

還不確定怎麼解讀，例如說第1筆的查詢，是我每天都在執行的store procedure，但為什麼connect_time是2018-12-14，而last_write又是2018-12-23

參考資料

SQL Server 說明
Latch的詳細介紹

文獻閱讀

Introduction to Latches in SQL Server

A latch is a lightweight synchronization object used by the Storage Engine of SQL Server to protect internal memory structures that can’t be accessed in a true multi-threaded fashion.

Latches were first introduced in SQL Server 7.0, when Microsoft first introduced row-level locking

In the context of SQL Server this means that multiple threads can concurrently read a shared data structure, like a page in memory, but writing to that shared data structure must be performed single-threaded.