SQL 跟踪是一个SQL Server数据库引擎工具，而客户端性能分析器工具只不过是服务器端功能的包装。当执行跟踪时，会监视特定的事件，这些事件是数据库引擎中的各类动作发生时被引发的。例如，一个用户登录或一个查询的执行都会触发事件。每个事件都有一个列的关联集合，这些关联集合是包含事件触发时收集的数据的各类属性。例如，就一个查询而言，可以收集的数据有该查询开始的时间、持续的时间及使用CPU的时间。最后，每个跟踪都可以规定各自的筛选程序，这样就可以根据一组规则来限定返回结果。例如，一个跟踪可以规定只有超过50毫秒的事件才应该被返回。
由于是从大量事件及列中进行选择，因此能够收集到的数据点的数量很大，并不是每一列都适用于每个事件。考虑保留这些数据时的内存使用情况，以及创建这些数据时所需的处理器时间，SQL Server在生成许多信息的同时，还能保证高效运行。除非用户有要求，SQL Server实际上根本不收集任何数据，即这种模式就是选择性地只在需要时进行收集。
注意：
后续版本的 Microsoft SQL Server 将删除该功能。请避免在新的开发工作中使用该功能，并着手修改当前还在使用该功能的应用程序。 请改用扩展事件。
SQL 跟踪（SQL Trace）的优点
Microsoft SQL Server 提供 Transact-SQL 系统存储过程来创建对 SQL Server 数据库引擎实例的跟踪。 可以不使用 SQL Server Profiler，而使用这些系统存储过程从您自己的应用程序中手动创建跟踪。 这样，您就可以针对企业的特定需求编写自定义应用程序。
SQL 跟踪（SQL Trace）体系结构
事件源可以是生成跟踪事件（例如 Transact-SQL 批处理）或 SQL Server 事件（例如死锁）的任何源。有关事件的详细信息，请参阅MSDN中有关 SQL Server 事件类的参考。事件发生后，如果该事件类已经包含在跟踪定义中，则跟踪将收集该事件信息。如果已经在跟踪定义中为该事件类定义筛选器，则将应用这些筛选器并将跟踪事件信息传递到队列。从队列中，跟踪信息或者被写入文件，或者由应用程序（例如 SQL Server Profiler）中的 SMO 使用。
以下关系图显示了在跟踪期间 SQL 跟踪如何收集事件。
下面结合上图，对关键的组件和过程进行描述。
内部跟踪组件
SQL跟踪体系结构中的中心组件是跟踪控制器，这是一种共享资源，用于管理用户创建的所有跟踪。各种事件发生器遍布整个数据库引擎，例如，查询处理器、锁管理器和高速缓存管理器中都存在。这些发生器负责产生与服务器活动的某些目录相关的事件，但是每个发生器都默认设置为不可用，因此就不会产生任何数据。当一个用户要求开始跟踪某个事件时，跟踪控制器中的一个全局位图就被更新，并告知事件发生器至少有一个跟踪在监听，从而使事件开始运行。与该位图一起管理的是一个次级列表，该次级列表记录了哪些跟踪正在监视着哪些事件。
如果一个事件开始运行，它的数据就被发送至一个全局事件接收器，全局事件接收器对各种事件数据进行排队，以分配给每个正在监听的跟踪。这个跟踪控制器根据内部跟踪列表和监控事件列表，将数据传递至每个监听的跟踪。除了跟踪控制器的列表外，每个单独的跟踪都保留监视事件的轨迹，以及正被实际使用的列和适当的过滤程序。跟踪控制器返回至每个跟踪的事件数据都经过过滤，而在数据被发送至一个I/O提供者之前，数据列也会根据需要而被裁剪。
跟踪I/O提供者
跟踪I/O提供者是实际发送数据至其最终目的地的工具。跟踪数据的可用输出格式有两种，一种是数据库服务器（或网络共享）中的一个文件，另一种是客户的一个行集。这两种提供者都是同内部缓冲区来确保当数据不能被尽快消耗时（即写入磁盘或从行集读取时）可以被加入到队列之中。然而，它们在队列增长到超过可控制大小时的处理方法却有很大区别。
文件提供者在设计上的一个重要保证就是不能遗漏任何事件数据。为了使它在发生I/O降速甚至停止工作时既然能运行，内部缓冲区在无法及时写磁盘时就开始逐渐填充数据。一旦缓冲区被填满，传输事件数据至跟踪的线程就开始等待缓冲区被清空。为了避免线程等待跟踪缓冲区，就必须保证有足够快的磁盘系统来完成跟踪。要想监视这些等待，就要了解SQLTRACE_LOCK和IO_COMPLETION等待类型。
另一方面，行集提供者在设计上不能保证不丢失任何数据。如果数据没有被及时消耗并且内部缓冲区已经填满，它就会先等待20秒，然后再抛弃事件以清空缓冲区使事件继续进行。如果事件被丢弃，SQL Server性能分析器客户工具就会发送一个特殊的错误信息，用户也可以通过监视SQL Server的跟踪写等待类型来查看自己是否出现这种情况，当线程等待缓冲区清空时SQL Server的跟踪写等待也会增加。
无论何时，只要服务器上至少有一个跟踪处于活跃状态，后台跟踪管理线程就会运行。除了关闭被视为到期的（如果一个跟踪已经丢失一个事件超过10分钟，这种情况就会发生）基于行集的跟踪之外，这个后台线程还负责刷新文件提供者缓冲区（每4秒钟执行一次）。比起每次收集完一个事件就往磁盘中写数据，SQL Server更倾向于只是偶尔刷新一次文件提供者缓冲区。这样，SQL Server就能利用大块的写操作，极大降低跟踪（求其是特别活跃的服务器上的跟踪）的开销。
SQL Server的新数据库管理员经常会遇到一个问题，为什么没有能直接将跟踪数据写入一个表中的提供者。之所以会有这个局限，是考虑到所需要的开销。由于一个表并不支持大块的写操作，所以SQL Server就不得不一行一行地写入事件数据。事件消费所致的性能下降将引发两种后果：一种是丢弃大量事件；另一种是强制执行无损保证时引发大量的阻塞。由于这两种方案都不合适，所以SQL Server几乎不提供这个功能。无论是在跟踪期间还是在跟踪之后，将数据载入表里都很简单，因此，这也就算不上是一个局限了。
安全和权限
跟踪不仅可以显示大量关于服务器状态的信息，而且还能显示用户发送到数据库引擎及数据库引擎返回的数据信息。监视范围从单独的查询到批处理甚至查询计划级别，这种监视能力很强，但同时一会对存储过程中的输入参数进行曝光，因而会为攻击者提供大量有关数据库中的数据信息。为了保护SQL跟踪不被他人看到，之前版本的SQL Server只允许管理用户（系统管理员确定的服务器负责任的成员）访问来启动跟踪。对许多开发团队来说，这是个限制，因此后来就被放宽了。
修改跟踪（ALTER TRACE）权限
修改跟踪权限，是一个服务器级别的权限（授权给一个登录），除了能够引发用户自定义事件之外，还允许访问来启动、停止或修改一个跟踪。
这个权限是在服务器级别上授权的，它的访问也是服务器级别的；如果一个用户可以启动一个跟踪，那么无论事件在哪个数据库上引发，都能检索事件数据。对于开发者可能在产品系统上运行跟踪以调试应用程序，在SQL Server中加入了该权限，但不能轻易地授予该权限，即使这并不能给他人全部的系统管理员访问权限，但它仍是一个潜在的安全威胁。
要想给一个登录授予修改跟踪的权限，可以使用下面的GRANT语句：
GRANT ALTER TRACE TO JANE;
保护敏感事务数据
除了加锁便于允许某些特定用户使用SQL跟踪之外，跟踪引擎自身还有一对内置的安全特性去避开多余的对私有信息的的监视--包括那些可以通过访问跟踪的多余监视。如果一个事件包含了一个对密码相关的存储过程或语句的调用，SQL跟踪就会自动忽略这些数据。例如，包含WITH PASSWORD选项的CREATE LOGIN的调用会被SQL跟踪取消。
SQL跟踪的另一个安全特性是加密模块的使用。在一个加密的存储过程、用户自定义函数或视图中，SQL跟踪不会返回生成的语句文本或查询计划。再者，也可以有助于保护特别敏感的数据不被那些原本可以查看跟踪的用户看到。
本文转自UltraSQL51CTO博客，原文链接： http://blog.51cto.com/ultrasql/1586032，如需转载请自行联系原作者
