今天使用xp_readerrorlog第一次在新服务器查询一个死锁信息，结果一直在运行，即使kill了也一直在运行：
（分别在2个服务器实例中运行，其中一个已经kill）
exec xp_readerrorlog 0,1,NULL,'2015-01-07 22:13:10','2015-01-07 22:13:11','ASC'
而下面这个执行是正常的，结果很快出来：
exec xp_readerrorlog 0,'deadlock victim','2015-04-01','2015-04-10','desc'
操作系统： Microsoft Windows Server 2008 R2 Enterprise （64） Service Pack 1
sqlServer：Microsoft sql Server 2008 (RTM) Microsoft Corporation Enterprise Edition (64-bit) (Build 7601: Service Pack 1)
select p.spid,p.waittime,p.lastwaittype,p.cpu,p.open_tran,p.status,p.cmd,s.text from master.dbo.sysprocesses p cross apply sys.dm_exec_sql_text(p.sql_handle) s where spid=55 --where spid=374 --haved killed
发现该session的执行时间，cpu一直累增，而且一直在运行。
监视器查看，cpu都增加了20%~30%！！！批处理也多了100以上！~
服务器64G内存限制sqlserver为55G，其他服务器最少都剩余6~7G，但是这两台执行的可用内存只有不到2G！~
找到一篇文章：Why does PREEMPTIVE_OS_GETPROCADDRESS Show a Large Accumulation?
说是sqlServer 2008 的一个bug，是执行扩展存储过程导致类型PREEMPTIVE_OS_GETPROCADDRESS不断地累计时间。
按上面所说的，计算扩展存储过程执行的大致时间：
declare @WaitTime bigint select @WaitTime = wait_time_ms from sys.dm_os_wait_stats where wait_type = 'Msql_XP' select @WaitTime - wait_time_ms from sys.dm_os_wait_stats where wait_type = 'PREEMPTIVE_OS_GETPROCADDRESS'
2个实例的结果也只有不到300毫秒。而且，等待类型PREEMPTIVE_OS_GETPROCADDRESS当前并没有增加。
select * from sys.dm_os_wait_stats where wait_type='PREEMPTIVE_OS_GETPROCADDRESS'
没有增加，两种可能的结果：
1. 扩展存储过程执行完了；
2. 扩展存储过程仍然在执行（因为正在执行时，数据是没有计算到DMV中的）
下面执行了一批的查询，发现该session都是正在运行中的，task、thread、work都是在运行同一个对象。
select * from sys.dm_exec_sessions where session_id=55 select * from sys.dm_exec_connections where session_id=55 select * from sys.dm_exec_requests where session_id=55 select * from sys.dm_os_tasks where task_address=0x00000000005DD948 and session_id=55 select * from sys.dm_os_workers where worker_address=0x00000008B58FC1A0 select * from sys.dm_os_threads where thread_address=0x000007FFFFF594A8
到底是不是bug？是不是还在运行？怎么撤销？难道要重启sqlServer服务才能解决？
（当前状态仍是上面的图一样，只是时间、cpu在不断增加。仍在寻找答案！~）
最后的解决办法，重启了服务！~cpu和批处理一下就将下来了！（内存等平稳了再确定）~后台会话也不在了！~
为了验证，再执行一次扩展存储过程！~结果又上来了！~
exec xp_readerrorlog 0,'ASC'
果然还是无法解决啊，之得重启服务，到时测试看看再打补丁吧！~
第三方的扩展存储过程在数据库中还真是难管理！~
终极解决：
