近一段时间观察，监控发现一数据库的 每秒批处理请求数（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 该账户的几个会话。执行后很快降下来！
版权声明：本文为博主原创文章，未经博主允许不得转载。
却还是，会愚蠢的选择相互敌视的方式。即使背脊相抵，
