SQL Server 2008-R2 數據庫上有很多短期阻塞
尋求專家就短期封鎖提供建議，我們現在已經看到了將近一周。
DB 是 15 TB，而這個表 B 中我們有很多阻塞 - 幾乎沒有 300 個是 2 TB。
在使用 sp_whoisactive 時，我看到查詢在 3-4 秒內被阻塞，有些在 9-10 秒內被阻塞，但是因為這些查詢幾乎在一天中來來去去，連接超過 2-3 千，這會導致應用程序中出現很多錯誤。
已完成故障排除：
- 更新了 NC 指數的統計數據，我們只有一個 NC 和一個 C 指數。
- 從哨兵檢查時，我們可以看到這些被阻塞的語句都是上面提到的那個表的插入語句。
以下是一些指標：
- 等待過去 3-4 小時的統計數據，其中阻塞直到開啟
- PAGELATCH_EX –> 51.1 % 總等待數 730 513 153.5
- PAGELATCH_SH –> 23 % 等待總數 343 538 769.7
- 執行緒池 –> 18 % 總等待數 257 222 894.4
- BATCHES/sec 平均：8612.6
- CPU 和記憶體 –> 遠低於門檻值，因為我們有 256 個邏輯處理器和 612 GB RAM
- 檢查點頁數/秒 –> 1706
- 懶惰寫 –> 0
- 日誌刷新/秒 1844.4
- 事務/秒 9074
根據大衛查詢的結果：下面的 Note@ 在我們進行節點故障轉移後 15 分鐘執行
wait_type wait_time_ms_per_sec PAGELATCH_EX 733024.4 PAGELATCH_SH 328846.4 CPU_USED 7131.4 WRITELOG 6484.4 DBMIRROR_EVENTS_QUEUE 4973.6 DBMIRRORING_CMD 1456.6 OLEDB 990.2 TRACEWRITE 984.2 SOS_SCHEDULER_YIELD 280.6 THREADPOOL 254 ASYNC_NETWORK_IO 45.4 LATCH_EX 9.4 PAGEIOLATCH_EX 7.6 PREEMPTIVE_OS_GETPROCADDRESS 3.4 MSQL_XP 3.2 DBMIRROR_SEND 1.4 PREEMPTIVE_OS_DELETESECURITYCONTEXT 1 PAGELATCH_UP 0.4 PREEMPTIVE_OS_WAITFORSINGLEOBJECT 0.4 PREEMPTIVE_OS_AUTHORIZATIONOPS 0.2 PREEMPTIVE_OS_AUTHENTICATIONOPS 0.2 SOS_RESERVEDMEMBLOCKLIST 0.2 CMEMTHREAD 0.2請提供其他故障排除建議，如果需要任何其他指標，請告訴我。
Edit@ 我們正在使用 MAXDOP 8 並且 par’sm 的成本門檻值設置為 default-5
更新：沒有進行任何更改，當我們在夜間看到連接中斷時，突然問題似乎消失了，並且現在檢查沒有阻塞。以下是目前的統計數據
OLEDB 11883.8 WRITELOG 11732.2 DBMIRROR_EVENTS_QUEUE 4969.8 CPU_USED 4093.75 DBMIRRORING_CMD 1457.2 TRACEWRITE 1080.2 PAGEIOLATCH_SH 333.4 PAGELATCH_EX 237.4 PAGELATCH_SH 31.4 ASYNC_NETWORK_IO 30.2 SOS_SCHEDULER_YIELD 6 LATCH_EX 4.4 DBMIRROR_SEND 1.6 PREEMPTIVE_OS_AUTHENTICATIONOPS 1.4 MSQL_XP 1.2 PREEMPTIVE_OS_GETPROCADDRESS 1.2 PAGELATCH_UP 0.4 PREEMPTIVE_OS_DECRYPTMESSAGE 0.4 SOS_RESERVEDMEMBLOCKLIST 0.4 PREEMPTIVE_OS_DELETESECURITYCONTEXT 0.2 PREEMPTIVE_OS_WAITFORSINGLEOBJECT 0.2 CMEMTHREAD 0.2 PREEMPTIVE_OS_AUTHORIZATIONOPS 0.2 PREEMPTIVE_OS_CRYPTACQUIRECONTEXT 0.2 PREEMPTIVE_OS_NETVALIDATEPASSWORDPOLICY 0.2不確定它是如何以及為什麼會發生的，就像今天看到的那樣，我們沒有看到那麼多連接，也沒有看到阻塞。但那是肯定的它很快就會彈出
更新@它的背面和看起來同樣的等待
這：
wait_type wait_time_ms_per_sec PAGELATCH_EX 733024.4 PAGELATCH_SH 328846.4 CPU_USED 7131.4 WRITELOG 6484.4表明你有一個閂鎖爭用問題，而且只有一個閂鎖爭用問題。
自從
@ 下面是在我們進行節點故障轉移後 15 分鐘執行的
CPU_USED 行應該是準確的。因此，您的工作負載每秒只能使用 7 秒的 CPU 時間。這就像只在 7 個核心上執行。同時，您有 1000 秒的頁面鎖定時間，這意味著您平均有 1000 個會話等待鎖定一個頁面，並且只有 7 個會話執行有用的工作。
您還在一個非常大的伺服器上執行非常舊的軟體。這台伺服器的吞吐量非常高，表明它支持的操作很重要。還要考慮您的使用者名。因此，您應該強烈考慮與 Microsoft 支持或在此類事情上具有專業知識的合作夥伴進行合作。
也就是說，下一步是確定閂鎖等待的來源。通常，它們要麼位於數據庫中表的熱頁上，要麼位於 TempDb 中的系統頁上。sys.dm_exec_requests.wait_resource 應該告訴你哪個。
如果是 tempdb，則建議減少 SQL Server tempdb 中的分配爭用。
如果您的數據庫中有一個表，則發布該表的 DDL（包括索引）和阻塞查詢的詳細資訊。
這裡有一份關於診斷和解決 SQL 2008 上的閂鎖爭用的白皮書：診斷和解決 SQL Server 上的閂鎖爭用
51% 的等待是由PAGELATCH_EX引起的，23% 是由PAGELATCH_SH引起的。
在這篇文章中有一些關於這種等待類型的有價值的資訊。我在這裡引用一點
這種等待類型是當執行緒等待訪問記憶體中的數據文件頁面（通常是表/索引中的頁面）時，它可以修改頁面結構（EX = 獨占模式）。右側邊欄中的鎖存器白皮書描述了所有鎖存器模式及其與其他鎖存器模式的兼容性。
PAGELATCH_XX 爭用的常見原因是：
- tempdb 中的分配點陣圖爭用（PAGELATCH_UP 用於嘗試更改同一點陣圖的多個執行緒），以及在極端負載下，
在使用者數據庫中
- 表/索引插入熱點（PAGELATCH_EX 用於插入同一頁面的執行緒，可能 PAGELATCH_SH 用於從該頁面讀取的執行緒）
- 來自隨機插入的過多頁面拆分（PAGELATCH_EX 用於嘗試在頁面上插入/更新行的執行緒，可能 PAGELATCH_SH 用於
從該頁面讀取的執行緒）
sqlperformance.com上有一篇關於PAGELATCH_XX等待故障排除的長文章 ，涵蓋了上述前兩種情況，基本上從所涉及的頁面資源確定爭用的原因，並從那裡進一步排除故障。第三種情況的故障排除涉及確定哪個索引正在經歷頁面拆分，然後通常實施填充因子和定期索引維護。您可以在此部落格文章中獲取從頁面資源（來自 sys.dm_os_waiting_tasks）中辨識表的工作流。