SqlServer 批處理（Batch Requests/sec）過高追蹤處理

標籤：

近一段時間觀察，監控發現一資料庫的 每秒批處理請求數（Batch Requests/sec）經常升高持續較長時間，比平時高出幾百，如：

由於一直比較高，以為是正常現象，沒有注意。最近我們老大要求查看原因，所以跟蹤查看，確實是資料庫的非正常請求引起！

先瞭解 批處理（Batch Requestsc）， 批處理簡單理解為同時執行的一批SQL處理語句，一個批處理中可能有多個DML、多個預存程序等等。如在SSMS操作，每個‘GO‘執行前都屬於一個批處理。

開始處理，用最笨的方法，開啟SQL Server profiler  監控 SQL:BatchCompleted （sql批處理完成記錄），但發現不是很多，每秒300左右，看起來正常，所以用 SQL Server profiler 不可行。

既然是批處理過多，批處理跟事務相關，可以開啟效能監控器監控以下兩個計數器：

Batch Requests/sec

Tranactions/sec(_Total)

發現 Tranactions/sec(_Total) 與 Batch Requests/sec 幾乎是一致的，在繼續查看Tranactions/sec ，把每個資料庫都詳細監控，確定只有 Tranactions/sec(master)  是最大的。與 master 串連相關的，如果不是系統的作業引起，可能就是串連引起，串連又有可能是內部的報表串連引起。排除除了SqlServer作業，再監控以下計數器：

Connection Reset/sec

Logins/sec

Logout/sec

只有 Connection Reset/sec 是最頻繁的，Logins/sec 和 Logout/sec 平均都在3左右。Connection Reset/sec 就是串連池串連過來的。

關於 Connection Reset/sec ，可以參考 宋大俠的 Ado.net的串連池

  "The sp_reset_connection stored procedure is used by SQL Server to support remote stored procedure calls in a transaction. This stored procedure also causes Audit Login and Audit Logout events to fire when a connection is reused from a connection pool."

此時可以用 SQL Server profiler  監控以下事件：

Audit Login

Audit Logout

這時監控出來的資料就比較多了！~這個使用者 cdwbcb 不斷從串連池地串連和斷開！非常頻繁，可以確定是該使用者引起的！

接下來就好辦了，開啟SSMS串連到該資料庫，執行以下語句。

select p.*,s.text from master.dbo.sysprocesses p cross apply sys.dm_exec_sql_text(p.sql_handle) swhere nt_username='cdwbcb'

找到相關資料：

資料庫中保持了該使用者的6個串連會話。奇怪的是，這些session的事務已經關閉（open_tran=0），處於空閑狀態（status=sleeping），但是仍有命令等待執行（cmd=AWAITING COMMAND）！如果 open_tran=1 還可以理解，這個就無法解釋了，還不清楚這個串連是個什麼樣的狀態。

暫時的解決方案：kill 該賬戶的幾個會話。執行後很快降下來！

著作權聲明：本文為博主原創文章，未經博主允許不得轉載。

SqlServer 批處理（Batch Requests/sec）過高追蹤處理