我正在Service Broker Queue上配置事件通知，以便在发生各种与性能相关的事件时进行记录。其中一个是Missing_Join_Predicate。
此事件的XML有效负载对我来说没有什么用于识别原因（TSQL，查询计划，objectid等）所以在处理队列的过程中我试图使用TransactionID来查询dm_exec_requests和dm_exec_query_plan获取查询计划和TSQL，其中dm_exec_requests.transactionid是事件中的TransactionID。
代码没有数据。
从查询中删除过滤器（即从dm_exec_requests和dm_exec_query_plan收集所有行）显示已返回记录，但没有针对相关TransactionID的记录。
我想做的是什么？我哪里错了？！
答案 0 :(得分：3)
基于跟踪的事件通知（如MISSING_JOIN_PREDICATE）只是对应跟踪事件（Missing Join Predicate Event Class）的逐字翻译，并且具有完全相同的信息。对于这个特定的事件，基本上没有任何有用的信息，<TransactionID>是触发事件的xact id，当你将它出列并处理通知消息时，交易很可能已经完成并且已经消失（yay for基于异步排队的处理）。
使用原始跟踪错误事件时，例如。使用Profiler，您还可以启用SQL:BatchCompleted，适当过滤，然后在行为中捕获JOIN罪魁祸首。但是使用事件通知我没有看到任何可行的方法来自动化该过程，以便您可以查明问题查询和应用程序。使用EN，您最多可以提高对问题的认识，显示导致问题的客户端（应用程序），然后使用其他方法（例如代码检查）来实际查找问题的根本原因。
不幸的是，您会发现有更多事件通知事件遭遇类似问题。