5
我負責在IIS和SQL Server 2005（500個併發用戶，1TB數據，8個IIS服務器）上運行的第三方應用程序（無法訪問源代碼）。我們最近開始發現數據庫上存在嚴重的阻塞（在生產中運行該應用程序幾個月沒有問題）。這種情況在一天中隨機發生，大約每30分鐘一次，並且每次都會影響20到100次會話。所有的會議最終都會導致申請超時，會議中止。SQL Server 2005阻塞問題（ASYNC_NETWORK_IO）
問題消失，然後逐漸重現。該SPID負責阻塞總是具有以下特點：
- WAIT TYPE = ASYNC_NETWORK_IO
- 的SQL正在運行的「（@claimid VARCHAR（15））SELECT者ClaimID，enrollid， 狀態，orgclaimid， primaryclaimid FROM claim WHERE primaryclaimid = @claimid AND primaryclaimid <> claimid）「。這是 相對無害的SQL，應該只返回一個或兩個記錄，而不是 大型數據集。
- 否其他SQL語句已經被 牽扯到了阻塞，只有這個 SQL語句。
- 這是參數化的SQL，其執行計劃被緩存在 sys.dm_exec_cached_plans中。
- 此SPID在聲明表上有一個對象級別的S鎖，因此對聲明表的所有UPDATE/INSERT也都被阻止。
- 主機ID變化。不同的Web服務器負責阻塞會話。例如，有時我們追溯至Web服務器1，有時web服務器2.
當我們追溯在封閉牽連的Web服務器，我們看到以下內容：
- 總有一些 應用程序相關的錯誤在 事件日誌在Web服務器上，鏈接 從主機ID和主機進程ID 從SQL會話。
- 錯誤消息各不相同，通常有一些 種SystemOutofMemory。 （這些 錯誤信息似乎是類似於我們在 以前看到沒有這種戲劇性 後果 錯誤消息。我們認爲在之前發生 ，但並沒有導致阻塞。 爲什麼是現在？）
- 網絡服務器上的網絡 適配器或SQL服務器上的 沒有已知問題。
（在任何情況下由違規查詢返回的記錄集將很小。）
事情排除：
- 指標定期進行碎片整理。
- 統計信息定期更新。
- 增加了claim.primaryclaimid統計 的樣本大小。
- 強制緩存 執行計劃的重新編譯。
- 創建一個複合索引與 primaryclaimid，ClaimID的。
- 沒有網絡問題。
- Web服務器上沒有已知的問題。
- 對 Web服務器上的應用程序軟件沒有任何更改。
我們推測事件鏈是這樣的：
- Web服務器進程提交SQL 以上。
- SQL服務器執行SQL，期間 其獲取關於 權利要求表上的鎖。
- Web服務器進程遇到錯誤，並且 死亡。
- SQL服務器會話掛等待 爲Web服務器進程讀取 數據集。需要在索求表的部分得到 X鎖 （任何處理索賠）
- SQL服務器會話 封鎖鎖的要求 表，並保持阻塞，直到他們 全部命中應用程序超時。
故障排除任何建議，同時等待供應商的援助將是最歡迎的。
有沒有辦法強制SQL Server鎖定在這個特定的SQL語句的行/頁級別？ 有沒有辦法在ASYNC_NETWORK_IO上只設置一個閾值？
感謝您的快速和翔實的迴應。我們重新檢查了所有網絡服務器上的適配器/物理網絡連接，並相信我們可以排除這一點。與阻塞有關的SQL語句通常會返回一個非常小的數據集（最多3條記錄），不足以使網絡緩衝區溢出併產生延長的ASYNC_NETWORK_IO等待時間。 但是，有一個邊界條件（@claimid =''）會返回數百萬條記錄。這可能會誘發ASYNC_NETWORK_IO，即使在正確配置的Web服務器上也是如此。這是我們接下來要追求的。 – ivankolo 2010-03-12 22:35:14