在上个星期,我有两个例子,一个扩展事件会话的DROP命令花了一天的时间来完成,等待:PREEMPTIVE_XE_CALLBACKEXECUTE。
更多的背景信息:在第一个例子中,我运行了一个to命令来删除会话,一天后它就完成了。使用sp_whoisactive,我看到查询正在等待PREEMPTIVE_XE_CALLBACKEXECUTE。
在此期间,对象资源管理器( Object )收集元数据的查询被阻止,并收到锁定超时,但没有其他抱怨(至少我当时是这么想的)。
我试图在周五取消另一次会议,同样的行为也发生了,但它并没有像第一次事件那样在一天后就消失了。相反,我今早发现客户端应用程序无法连接。它被DROP EVENT SESSION查询所阻塞。
重新启动SQL服务清除了阻塞查询。
我找不到任何有助于诊断这种等待类型的东西.为什么我的活动时间不会像他们应该的那样下降。你能帮上忙吗?
服务器信息:带有R2的SQL 2008 SP2企业
发布于 2013-07-01 17:15:23
我相信这个问题是在服务器2008 R2 SP2累积更新#1 (10.50.4260)中解决的:
KB #2511963 -修复:如果查询更改或停止扩展事件会话,则Server 2008或Server 2008 R2中的查询将停止响应
他们没有提到你的具体等待类型,但我见过其他人,他们说这个修复解决了他们的问题。因此,如果您在SP2上没有CU (10.50.4000),那么至少应该考虑这个CU,或者更高的CU (2008年年R2 SP2的最新CU是CU7。 (10.50.4286))。
https://dba.stackexchange.com/questions/45529
复制相似问题