SQL Server Profiler 是一个功能丰富的界面，用于创建和管理跟踪，并分析和重播跟踪结果。对 SQL Server Profiler 的使用取决于您出于何种目的监视 SQL Server 数据库引擎 实例。例如，如果您正处于生产周期的开发阶段，则您会更关心如何尽可能地获取所有的性能详细信息，而不会过于关心跟踪多个事件会造成多大的开销。相反，如果您正在监视生产服务器，则会希望跟踪更加集中，并尽可能占用较少的时间，以便尽可能地减轻服务器的跟踪负载。
使用 SQL Server Profiler 可以：
- 监视 SQL Server 数据库引擎、分析服务器或 Integration Services 的实例（在它们发生后）的性能。
- 调试 Transact-SQL 语句和存储过程。
- 通过标识低速执行的查询来分析性能。
- 通过重播跟踪来执行负载测试和质量保证。
- 重播一个或多个用户的跟踪。
- 通过保存显示计划的结果来执行查询分析。
- 在项目开发阶段，通过单步执行语句来测试 Transact-SQL 语句和存储过程，以确保代码按预期方式运行。
- 通过捕获生产系统中的事件并在测试系统中重播这些事件来解决 SQL Server 中的问题。这对测试和调试很有用，并使得用户可以不受干扰地继续使用生产系统。
- 审核和检查在 SQL Server 实例中发生的活动。这使得安全管理员可以检查任何审核事件，包括登录尝试的成功与失败，以及访问语句和对象的权限的成功与失败。
- 将跟踪结果保存在 XML 中，以提供一个标准化的层次结构来跟踪结果。这样，您可以修改现有跟踪或手动创建跟踪，然后对其进行重播。
- 聚合跟踪结果以允许对相似事件类进行分组和分析。这些结果基于单个列分组提供计数。
- 允许非管理员用户创建跟踪。
- 将性能计数器与跟踪关联以诊断性能问题。
- 配置可用于以后跟踪的跟踪模板。
SQL Server 为我们两者提供跟踪的方式：一种是一个物理文件(可保存在本机或者UNC网络路径)，一种是行集。对于后者大家应该比较熟悉
这个工具在 SSMS 的 工具 –> SQL Profile
详细的我暂时不介绍，先说说两者的区别和类同点 DIFFAndSame(行集,文件提供者)。
两者都是用类似Buffer来保存当前的事件数据，很明显是为了减少IO的压力，这样可以不阻塞和尽量不遗漏 事件数据，当Buffer 到达一定量时候可能才会Flush到磁盘或者发送到网络的终端(客户端)显示监控行集。
物理文件保存监控结果的方式的重要保证是不能遗漏任何事件，一旦IO降速的时候，可能会影响到整个T-SQL的执行情况。
SELECT * FROM sys.dm_os_wait_stats WHERE wait_type IN ('SQLTRACE_LOCK','IO_COMPLETION');
我使用这个语句来监控TRACE 和IO 完成对我当前机器的影响，我的某个客户的IO情况：
wait_type waiting_tasks_count wait_time_msmax_wait_time_ms signal_wait_time_ms
IO_COMPLETION66030898243774993634 418960
SQLTRACE_LOCK12007 1759431001 1281
因为我进行了大量的过滤，因此这个值还是能够接受的，影响不是特别大。
行结果集的方式，其实也是我们最熟悉的，就是使用SQL Server Profile监控GUI 直接展现给我们看到的。但是，我是非常不建议使用的，首先如果Buffer满了，它有一定的延迟，可能会抛弃事件已清空缓存区继续接受事件，而事件没有发送到Client，也没有写到物理文件，自然就丢失了。比如，SQL Server Profile 在DB服务器进行监控，因为高负载的机器再用来展示，很有可能就会丢失事件，另外物理文件方式，其实是接受一个足够大的Buffer，进行的大块写操作，性能是优于行集的。
保密性原则
SQL Server的安全特性会自动过滤 包含隐私的数据，比如密码。我在我的SSMS中执行了如下的语句：
EXEC sp_password 'pp','pp1','sa';
这是修改sa帐号密码的系统sp，我打开了SQL Server Profile –> 选择了T-SQL 监控模版
然后执行上面的存储过程，监控结果：
监控结果：--*sp_password----------------------------
SQL Server Profile
使用SQL Server Profile GUI工具还是很多优势，首先是减少了我们监控的复杂性，可以快速的建立监控，在跟踪属性中，可以可以选择MSSQL为我们提供的模版，包括常用的T-SQL、T-SQL Duration、T-SQL Locks模版分别监控当前DB运行的所有查询，所有查询的耗时、所有的锁定状态。
在跟踪属性 –> 选择事件选择 我们可以选择自己需要的事件，所有的事件在MSDN 都有定义->单击列筛选器 可以自定义过滤，排序噪点干扰因素
其他的模版大家可以自己看看MSDN 手册，自己尝试一下：SQL Server 2008 R2 本机 MSDN
服务器端跟踪和物理方式收集
SQL Server Profile 只是对一些存储过程的封装，我更倾向于，自己定义常用的脚本，将监控结果保存在本机，用来大量的分析和存档。
当然涉及4个存储过程，虽然设置过滤的脚本非常麻烦，但是SQL Server Profile 可以利用 文件->导出 可以导出监控脚本意味着，我们不需要编写复杂的T-SQL 脚本，不过还是建议大家熟悉这几个存储过程：
sp_trace_create 定义跟踪 ，创建的跟踪会在sys.traces查询的到。
s_trace_setevent 设置监控事件
sp_trace_setfilter 设置过滤
sp_trace_setstatus 设置跟踪的状态 常用的是 sp_trace_setstatus @traceid,0 停止功能 、sp_trace_setstatus @traceid,2 移除跟踪，这将导致sys.traces最终查询不到该跟踪
其实整个跟踪还是比较简单的。我这里有一个常用的脚本：
用来 监控超过指定秒数 和 数据库 的 批处理和存储过程 语句(超过5MB的文件，会执行ROLLOVER，根据文件名在后面添加类似_1,_2.trc的跟踪结果)：
CREATE PROC [dbo].[sp_trace_sql_durtion]
@DatabaseName nvarchar(128),
@Seconds bigint,
@FilePath nvarchar(260)
AS
BEGIN
DECLARE @rc int,@TraceID int,@MaxFileSize bigint;
SET @MaxFileSize = 5;
EXEC sp_trace_create @TraceID OUTPUT,2,@FilePath,@MaxFileSize,NULL;
IF @rc != 0
RETURN;
DECLARE @On bit;
SET @On = 1;
EXEC sp_trace_setevent @TraceID,10,35,@On;
EXEC sp_trace_setevent @TraceID,10,1,@On;
EXEC sp_trace_setevent @TraceID,10,13,@On;
EXEC sp_trace_setevent @TraceID,41,35,@On;
EXEC sp_trace_setevent @TraceID,41,1,@On;
EXEC sp_trace_setevent @TraceID,41,13,@On;
SET @Seconds = @Seconds * 1000000;
EXEC sp_trace_setfilter @TraceID,13,0,4,@Seconds;
IF @DatabaseName IS NOT NULL
EXEC sp_trace_setfilter @TraceID,35,0,0,@DatabaseName
EXEC sp_trace_setstatus @TraceID,1
SELECT TraceID = @TraceID;
END
参数非常的明了，数据库名称、执行事件超过多少秒、保存的路径。
当我们运行这个脚本一段事件以后，可以快速的发现大量耗时的T-SQL，我们可以通过
SELECT * FROM fn_trace_gettable(N'监控文件路径',1);
来查看行方式的结果。
同样的富有创造力的读者可以自己创建监控锁定，监控死锁等方式保存文件，但是我的建议是尽可能的减少噪音，也就是说我们要达到什么目地就
建立什么功能，这样才能将大问题细化解决。
在《Microsfot SQL Server 2005 技术内幕： T-SQL 程序设计》 中有一个正则，用来将类似的语句全部组合成，只有参数形式替换具体值
的SQL CLR，但是我认为那个正则还有bug，等我空了给大家写一个，自己也能使用的更完善。
监控异常
在上个系列中，讲述了具体的SQL Event抓去的异常，可以及时通知，但是具体的异常信息，并不是特别详细。因此我们可以选择事件中的
Error来添加有关T-SQL批处理和SP的所有异常，用于分析，这个跟踪非常有利于我们监控一些异常情况!!!
我创建了一个跟踪的脚本，和上面的跟踪事件的脚本一样，超过5MB RollOver。
我们要定期的执行这个跟踪，虽然不建议长期开启，但是定期监控处理异常是有利我们系统更加长时间运作的。
CREATE PROC [dbo].[sp_trace_sql_exception]
@FilePath nvarchar(260)
AS
DECLARE @rc int,@TraceID int,@Maxfilesize bigint
SET @maxfilesize = 5
EXEC @rc = sp_trace_create @TraceID output, 2, @FilePath, @Maxfilesize, NULL
IF (@rc != 0)
RETURN;
DECLARE @on bit
SET @on = 1
EXEC sp_trace_setevent @TraceID, 33, 1, @on
EXEC sp_trace_setevent @TraceID, 33, 14, @on
EXEC sp_trace_setevent @TraceID, 33, 51, @on
EXEC sp_trace_setevent @TraceID, 33, 12, @on
EXEC sp_trace_setevent @TraceID, 11, 2, @on
EXEC sp_trace_setevent @TraceID, 11, 14, @on
EXEC sp_trace_setevent @TraceID, 11, 51, @on
EXEC sp_trace_setevent @TraceID, 11, 12, @on
EXEC sp_trace_setevent @TraceID, 13, 1, @on
EXEC sp_trace_setevent @TraceID, 13, 14, @on
EXEC sp_trace_setevent @TraceID, 13, 51, @on
EXEC sp_trace_setevent @TraceID, 13, 12, @on
DECLARE @intfilter int,@bigintfilter bigint;
EXEC sp_trace_setstatus @TraceID, 1
SELECT TraceID=@TraceID
GOTO finish
ERROR:
SELECT ErrorCode=@rc
FINISH:
定期执行吧，同志们，找异常。。。
默认跟踪和黑盒跟踪
在sys.traces中的TraceID = 1的跟踪是SQL Server 默认跟踪，这个跟踪比较轻量级，一般监控服务器的启用停止，对象的创建和删除，日志和数据文件自动增长以及其他数据库的变化。(监控那些没事删错了表的人，是最好的，当然前提不要都使用一个帐号!)
可以通过
EXEC sp_configure 'default trace enabled',0;
RECONFIGURE WITH OVERRIDE;
来关闭默认跟踪。
黑盒跟踪，就是可以帮助我们诊断数据库没事自个奔了的异常，在MSDN 搜索sp_create_trace的时候应该也发现了
的选项，那么我们也能创建一个类似的存储过程来快速的创建黑盒跟踪，帮助我们诊断一些异常!
CREATE PROCEDURE sp_trace_blackbox
@FilePath nvarchar(260)
AS
BEGIN
DECLARE @TraceID int,@MaxFileSize bigint
SET @MaxFileSize = 25;
EXEC sp_trace_create @TraceID OUTPUT,8,@FilePath,@MaxFileSize
EXEC sp_trace_setstatus @TraceID,1;
END
我这里提供@FilePath = NULL参数，这个默认就保存在SQL Server的数据文件夹中。
TechTarget中国原创内容，原文链接：http://www.searchdatabase.com.cn/showcontent_45099.htm