[技术文档]怎样诊断Service Broker问题
怎样诊断Service Broker问题
--王成辉翻译整理，转贴请注明出在微软BI开拓者www.windbi.com
--原帖地址
在 我关于Service Broker的第一和第二篇文章里，我说明了怎样在一台有用来存储数据的数据库的服务器上建立一个中央数据库（第一篇文章）以及跨越多个服务器来使用存储 所有数据的单个服务器（第二篇文章）。在这篇文章里，我将讨论可能引发的某些问题以及怎样去诊断它们。
可使用的工具
事件探查器
事件探查器现在有一个完整的事件部分用于Service Broker。注意Service Broker会话总是再两个终端之间完成的。这意味着你需要使用事件探查器去监控两个终端以便获得所发生情况的完全正确的描述。
这些事件包括：
- Broker:Activation 当队列监控器启动一个激活存储过程时触发。
- Broker:Connection 报告Service Broker管理的传输连接的状态。
- Broker:Conversation 报告会话的进度。
- Broker:Conversation Group 当创建或删除会话组时触发。
- Broker:Corrupted Message 当收到损坏的消息时触发。
- Broker:Forwarded Message Dropped 当删除转发的消息时触发。
- Broker:Forwarded Message Sent 当消息成功转发时触发。
- Broker:Message Classify 当已确定消息的路由时触发。
- Broker:Message Undeliverable 无法保留已接收到的消息时触发，该消息应该已传递给了该实例里的某个服务。
- Broker:Queue Disabled 当监测到有害消息时触发。这意味着在Service Broker队列里有连续5个事务回滚。它包含了数据库ID和包含了有害消息队列的队列ID。
- Broker:Remote Message Acknowledgement 当发送或收到消息确认时触发。
- Broker:Transmission 在传输层发生传输错误时触发。错误号和状态值表明了错误源。
- Security Audit:Audit Broker Login 报告Service Broker传输安全相关的审计信息。
- Security Audit:Audit Broker Conversation 报告Service Broker对话安全相关的审计信息。
这些事件中的一些事件有EventSubClass列来提供事件的更多信息，所以要确保包括这些列。通常我简单地选择所有的事件以及所有的列。这为你更好的分析提供了所有你能从跟踪里获得的信息。
目录视图和动态管理视图
有4个DMV用于Service Broker：
- sys.dm_broker_activated_tasks 为Service Broker激活的每个存储过程返回一行。它可以通过spid列和dm_exec_sessions.session_id进行连接。
- sys.dm_broker_connections 为每个Service Broker网络连接返回一行。
- sys.dm_broker_forwarded_messages 为SQL Server实例正在处理转发中的每个Service Broker消息返回一行。
- sys.dm_broker_queue_monitors 为实例里的每个队列监控器返回一行。队列监控器为队列管理激活。
有11个目录视图记录了用来正确地诊断问题的所有必要的信息。重要的是知道去查找什么以及在哪儿查找。这就是为什么我要给出每个目录视图并描述它们使用的情形。
sys.transmission_queue
当诊断Service Broker时，该目录视图是你的第一站。对Service Broker操作而言，Sys.transmission_queue是至关重要的目录视图，因为发送的每条消息都会加到其中，直到目标发回一个确认。如果成功地返回一个确认，那么消息会从视图中消失。如果失败的话，transmission_status列会保留错误信息。如果你的消息没有到达它的目的地，观察该目录视图以了解所发生的事情。
sys.conversation_endpoints
该目录视图为Service Broker参与的每个会话保留一行。在两个终端上conversation_id列具有相同的值。这里要注意，如果你想关闭会话的话，那么你需要使用conversation_handle的值来关闭它，在每个会话终端它的值是不同的。你需要通过conversation_id值来查找它。
列state_desc记录了会话的状态。如果消息不能到达另一个终端，那么从这里你会看到会话的状态一定是‘Conversing’即为了正确的双向运转正在进行‘交谈’。
sys.conversation_groups
该目录视图为每个会话组包含了一行。你不用过多使用该视图，因为在sys.conversation_endpoints里有可用的相同信息。
sys.remote_service_bindings
该目录视图为每个远程服务绑定包含了一行。远程服务绑定用来实现对话安全。这意味着你可以查看哪个服务绑定了哪个用户以及有什么权限。如果你怀疑问题出在对话安全上，那么在紧随事件探查器的运行之后，这是在查看sys.transmission_queue之后第二个要查看的地方。
sys.routes
该目录视图为每个已创建的路由包含了一行。路由用于定位服务的网络地址。在这里你可以搜索是哪个路由在处理哪个远程Service Broker以及路由寿命的相关信息。已终止的路由很难去调试，所以如果你怀疑是路由引起的问题的话就检查这里。路由地址可以是LOCAL、TRANSPORT、IP或计算机的DNS名。
sys.service_contracts
该目录视图为数据库里的每个约定包含了一行。从这里你可能得不到太多的其他帮助。
sys.service_contract_message_usages
该目录视图为每个约定-消息类型对包含一行。它比前一个目录视图更有用。如果你怀疑服务不支持你期望支持的消息类型（例如在创建服务时有个输入错误）或者你设置使用了错误的会话终端，那么你可以在这里检查看看是否正确。
sys.service_contract_usages
该目录视图为每个服务-约定对包含了一行。仅此而已。
sys.service_message_types
该目录视图为每个注册在Service Broker里的消息类型包含一行。如果你怀疑有消息确认问题，那么这里是你应该检查的地方。
sys.service_queue_usages
该目录视图为服务和服务队列之间的每个引用返回一行。服务可能仅和一个队列相关联，而队列可以和多个服务相关联。由于一个队列可以从多个服务接收消息，那么你可以在这里检查看哪个服务绑定到了哪个队列。
sys.services
该目录视图为数据库里的每个服务包含一行。它有助于得到服务的拥有者以及服务使用的队列的更清晰的视图。
如何进行呢？
重要的是要知道终端之间的完整会话是怎样发生的：
1.发起者发送消息
2.目标接收消息
3.目标发回成功接收消息的确认
4.发起者接收确认
两个主要的发起点是sys.transmission_queue和sys.conversation_endpoints。第一个会告诉你当发送消息时发生了什么错误。另一个告诉你你正在发生消息的会话是否合法以及是否被适当的使用。
当你怀疑有问题时，在发起者那端观察这两个视图。如果你还没有发现任何错误，那么为了更清晰的描述，你可以启动事件探查器并用所有的事件跟踪发起者和目标。当调试发送问题时，目录视图是你的助手，而当调试接收问题时事件探查器是你的助手。
如果队列里有任何错误的话，那么也不要忘记观察你的队列。在5个失败的并发事务之后，你会得到被称为损坏的消息具体是什么，该消息发生在你的队列会被禁用之后并且Broker:Queue Disabled事件会触发。如果此事发生，那么你遇到了我曾经遇到过的问题。所以要确保在会话的目标服务器上你的激活存储过程里处理这个错误。
小结
还好我对Service Broker助手系统对象的每个部分能做什么以及哪个情况下该使用哪个做了一一说明。刚开始似乎有点难，但随着你的深入，你会看到在怎样诊断问题上，通常重复使用那些相同的样式。
