為什麼會話成為頭塊
我正在解決一個似乎是隨機的問題
問題有時是應用程序（動態 SL）凍結
當應用程序凍結時，我注意到 SQL 活動監視器中有一個被阻止的對象和一個頭部阻止程序
在我有限的理解中，head blocker 意味著會話目前正在執行並且正在鎖定資源，並且另一個會話也需要該資源。所以需要訪問該資源的所有會話都無法繼續，因此我在活動監視器中看到的“被阻止”
我的問題是在我見過的五種情況下，head blocker 任務狀態實際上是空白的。通常任務狀態是“正在執行”或“暫停”現在未執行的會話如何成為頭阻塞器？
我在想我對 head blocker 的理解可能是錯誤的。但請啟發我 ELI5 風格:)
5個案例中的每一個。我只是殺死了head blocker的程序。然後每個人都不再凍結了。
我希望找出這個頭部阻滯劑的來源並提出解決方案
當我點擊頭部阻擋器的詳細資訊時。我只看到
select @@identity請指教？
謝謝
實際上，為了阻止會話，只需鎖定其他想要的資源。它實際上不必做任何事情。例如，如果您執行以下命令
BEGIN TRANSACTION UPDATE MyTable SET Col1 = 'ABC'並且不要執行 COMMIT ，那麼您將保持事務處於打開狀態。會話沒有做任何事情，實際上它不會出現在
sys.dm_exec_requests. 然而，鎖將繼續被持有並繼續阻止其他會話。您可以在 中找到有關未結交易的資訊sys.dm_tran_session_transactions。下一點是您看到的命令。那隻是會議的最後一批。如果您打開一個事務並通過它執行多個批處理，您很可能會持有早期命令的鎖，這些命令不會出現。
我在以下連結中更詳細地寫了這兩件事：
使用 sys.dm_exec_sql_text 找出阻塞有時是有缺陷的。
此外，第一個連結將包含有關如何查找誰在執行/執行有問題的事務的資訊。我經常發現，如果登錄名是共享登錄名或 SQL ID，我可以使用
sys.dm_exec_sessions.