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作業花費太多時間
解決方法
- 減少工作負載。
- 查看錯誤記錄檔或事件記錄檔中相關聯的 I/O 失敗。I/O 失敗通常表示磁碟功能有問題。
- 查看錯誤記錄檔,找出沒有產量的工作和其他重大錯誤。
- 如果經常發生諸如判斷提示之類的重大錯誤,請解決這些問題。
竟然看起來是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
參考資料
文獻閱讀
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.
Comments