|
|
【問題描述】
我們可能會在數據庫的錯誤日志里，發現這么一條信息:
A time-out occurred while waiting for buffer latch -- type 4, bp 000000097BFDEDC0, page 1:19239, stat 0xc00009, database id: 5, allocation unit Id: 72057615247867904, task 0x0000000005E594C8 : 0, waittime 300, flags 0x1018, owning task 0x0000000000169DC8. Not continuing to wait.
我們的問題是，這個錯誤到底是什么含義，在什么情況下會報上面的錯誤，以及如何解決？
【背景介紹】
Latch是SQL Server內部用來同步資源訪問的一個數據結構。和操作系統的Critical Section或ReaderWriterLock類似。Latch保護了那些想保護的資源，使得訪問同步有序。比方說，當某個線程獲得某個資源的Latch的獨占使用權時候，別的線程如果也需要訪問這個Latch，則它必須等待。
從大的方面來講，有兩種Latch，一種叫Buffer Latch，另外一種叫I/O Latch。
我們先來簡短介紹一下I/O Latch。當SQL Server從硬盤上讀取一個頁時，會先在內存預留該頁的空間。并且在該預留空間的某一個位BUF_IO設為1。如果數據從硬盤讀寫完成，則該位設為0。從硬盤讀取頁的期間，其他也需要訪問該頁的線程當然要等待，等待類型為PAGEIOLATCH_SH，直到讀寫完成，BUF_IO被設為0為止。因此，如果我們看到大量PAGEIOLATCH_SH等待，則基本可以斷定問題是出在磁盤性能上面。
另外一種Latch則稱為Buffer Latch，用來保護內存里的數據結構，如Index, Data Pages, B樹中的Non-Leaf頁。當進程需要讀取一個內存里的數據頁時，該進程要先獲取該數據頁上的Buffer Latch。有各種類型的Latch，包括獨占Latch(PAGELATCH_EX)和共享Latch(PAGELATCH_SH)。
下面來演示，為什么我們需要Latch。如下圖所示，我們在頁面100上，已經存放了兩條記錄。
如果沒有Latch鎖的話，某進程在頁面100上，插入如下數據：INSERT VALUES(3, 300)，其結果如下：
這時，另外一個進程要在頁面100上，插入如下數據: INSERT VALUES(4, 400), 因為沒有Latch鎖，所以會覆蓋之前的數據。導致數據插入出問題。
正確的做法是，我們要在第一個線程進行操作時，加獨占Latch鎖。第二個線程必須要等待，直到第一個線程操作完成。如下圖所示:
開始第一條記錄插入，隨后修改m_freedata(值為141)以及Row的指針(值為126)，在此期間，第二條插入語句處于等待Latch狀態。第一條記錄插入完成后，釋放獨占Latch鎖。
第二條記錄開始插入，插入期間也會加獨占Latch鎖，以防止其他進程修改或讀取頁。完成后，也隨即釋放Latch鎖。最后結果如圖所示。由于有Latch鎖，所以數據的插入可以有序的進行。
【LATCH申請模式】
Latch在申請的時候有以下幾種模式，
- KP – Keep Latch 保證引用的結構不能被破壞
- SH – Shared Latch 讀數據頁的時候需要
- UP – Update Latch 更改數據頁的時候需要
- EX – Exclusive Latch 獨占模式，主要用于寫數據頁的時候需要
- DT – Destroy Latch 在破壞引用的數據結構時所需要
下表顯示各種Latch申請的兼容模式：
Y表明是兼容的，如果兩個線程都去讀某頁，則他們都會去申請SH鎖，因為SH鎖是兼容的，則兩個線程都不會互相妨礙。而N表明是不兼容的，必須要等待。直到前面一個Latch被釋放為止。
【LATCH等待類型】
Latch的等待主要有三種。
- Buffer (BUF) Latch 用來保護索引或數據頁，也包括PFS, GAM, SGAM和IAM數據頁，等待類型是PAGELATCH_*模式。
- Non-buffer (Non-BUF) Latch 除了上述數據結構以外的其他內存結構，等待類型是LATCH_*模式。
- IO Latch 保護數據從磁盤到頁面的讀寫過程，等待類型是PAGEIOLATCH_*模式。
我們可以查詢下面的語句了解一下具體的等待種類：
SELECT * FROM sys.dm_os_wait_stats WHERE wait_type like '%Latch%'
it知識庫：Buffer Latch Timeout的解析，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
