SQL Server Profiler -- 识别异常

在一个完美的环境中，所有的异常都应该可以被捕捉、处理并记录。有专人定期查看这些日志并创建基于发生的异常的错误报告，使它们可以被及时调试并在将来多能避免再次发生。然而，现实总是可以看到应用程序从数据库到用户界面都会不断地出现各种异常，并且这些异常都没有任何记录。更糟糕的是，应用程序搜索到并消化了这些异常，偶尔也会给用户返回奇怪的数据，而这些用户并不明白发生了什么。为了查明这些情况通常提出分析观察这些异常，以便能够查找并处理这些异常，避免影响太多用户。

跟踪异常十分简单，可以从TSQL模板开始，该模板包括审核登录和审核登出事件以及现存连接事件（这里可以将所有事件都可以移除）。剩下的就是“RPC:Starting”和“SQL:BatchStarting”，这两者都是必须的，用来跟踪引发一个异常的Transact-SQL，不管这个异常是由于SQL批处理还是由于RPC调用引起的。在这种情况下，跟踪启动事件更为重要，而不是去跟踪完成事件，因为某些错误可能导致完成事件无法激发一个给定的查询。

还要往RPC和SQL事件中添加错误和警告类别中的注意、异常和用户错误信息事件。每当一个客户强行断开连接时，注意事件就会被激发，最好的例子就是客户端查询超时，通常暗示性能或阻塞问题。每当一个任意类型的异常发生时，异常事件就会被激发，而当与一个异常合在一起，以消息形式送回关于锁发生事件的额外数据时，用户错误信息事件就会被激发，或者当一系列状态改变时，该事件也会被激发，如用户从一个数据库切换到另一个数据库。

我们也建议为每个选择事件类都添加一个EventSequence列，这将使稍后的查询数据更加简便。建议用来监视异常的一个事件和列的完成事件选择对话框如下。

注意：SQL Server在查询执行进程的各个阶段内部使用异常来发送信息。它的一个警示标志就是没有相应的用户错误信息事件的一个异常事件。如果出现此类情况，并不需要用户处理错误。

在选择了合适的事件后，就可以编辑跟踪并启动此事件了。用户可能要在后台运行这类跟踪，做一些临时收集。通常情况下，在活动忙碌期间收集该数据十分重要，它可以帮助查找用户可能遇到的异常。比如捕捉一些特别的东西来，这类跟踪更像是撒网并希望赶上一些什么，因此计时是必不可少的。用户可能会发现异常，也可能发现不了，但是仅仅因为在一个收集期内没有发现异常就不能认为没有异常，所以要确保经常监视异常。

如果捕捉到数据并将其传送到一张表里，查找发生的异常就是一个问题了：

1. 在先于断开连接的同一个spid上的所有注意事件（事件类16），以及Transact-SQL或RPC事件（事件类分别是13和10）。

2. 所有异常事件（事件类33）和紧随其后的一个用户错误信息事件（事件类162），以及在先于异常的同一个spid上的Transact-SQL或RPC事件。

所有前后相随的逻辑都可以用EventSequence列编码，建议在跟踪管理加入这个列。下面的查询使用这个逻辑查找出所有的用户异常和断开连接、相关错误信息及造成故障的查询：

如果已经收集了大量的事件，就可以通过在跟踪表上的EventSequence列创建索引来提高查询的性能。

提示：如果已经意识到调用某一存储过程会发生一种异常，但是还需要更多的信息来确定到底这些事件在什么顺序下会激发这个异常，就可能需要结合之前所述的相同事件对单个查询做性能调校了。将查询事件以完成改到相应的启动类，并添加异常和用户错误信息事件，与调校单个查询的例子类似，这也需要和正在工作的spid上的过滤器一起，直接在SQL Server性能分析器中运行。