SqlServer 批处理（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) s
where nt_username='cdwbcb'

数据库中保持了该用户的6个连接会话。奇怪的是，这些session的事务已经关闭（open_tran=0），处于空闲状态（status=sleeping），但是仍有命令等待执行（cmd=AWAITING COMMAND）！如果 open_tran=1 还可以理解，这个就无法解释了，还不清楚这个连接是个什么样的状态。

暂时的解决方法：kill 该账户的几个会话。执行后很快降下来！

版权声明：本文为博主原创文章，未经博主允许不得转载。

SqlServer 批处理（Batch Requests/sec）过高追踪处理

标签：