我在 Service Broker 队列上配置事件通知以记录各种与性能相关的事件发生时。其中之一是 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 的记录。
我正在尝试做的事情可能吗？我哪里错了？！
基于跟踪的事件通知，如MISSING_JOIN_PREDICATE，只是相应跟踪事件（Missing Join Predicate Event Class）的逐字翻译，并带有完全相同的信息。对于这个特定事件，基本上没有任何有用的信息，这<TransactionID>是触发事件的 xact id，当您将其出列并处理通知消息时，事务很可能已完成并消失（对于基于异步排队的处理） .
使用原始跟踪错误事件时，例如。使用 Profiler，您还可以启用SQL:BatchCompleted，进行适当的过滤，然后在该行为中捕获 JOIN 罪魁祸首。但是对于事件通知，我看不到任何可行的方法来使流程自动化到您可以查明问题查询和应用程序的程度。使用 EN，您最多可以提高对问题的认识，向客户展示导致问题的原因（应用程序），然后使用其他方式（例如代码检查）来实际追查问题的根本原因。
不幸的是，您会发现有更多的事件通知事件存在类似问题。