原文链接：http://www.cnblogs.com/caishuhua226/p/3838060.html http://www.cnblogs.com/lyhabc/articles/2946938.html
http://www.cnblogs.com/lipeng0824/p/4417581.html（还需要学习）
1）菜单路径：开始--程序--Microsoft SQL Server 2008--性能工具--SQL Server Profiler
或者在SSMS里打开，工具--SQL Server Profiler
2）窗口左边的“常规”选项卡是一个基本设置，一般默认的就OK了。右边的“事件选择”选项卡，用来设置要跟踪的事件有哪些，列表的事件可以一一选择，基本上Sql上有的事件都有，包括你用SQL Server Management Studio操作数据库的过程都可以跟踪的到，只要单击显示所有事件就可以进行全部事件的选择了。
3）在“事件选择”选项卡中可以对统计的字段进行筛选，单击任意一个列标题可以查看列的说明
4）SQL Trace文件的收集方法
首先，SQL Trace里有哪些事件呢？在Profiler里新建一个Trace，在事件选择里选择“显示所有事件”，就能看到一个清单。里面的事件分类，在SQL2005这个版本已有21个之多，而每个分类下又有不同数目的事件。可以说，DBA想要看到的事件，基本上都能覆盖。可是事件太多，如果所有的事件都收集，产生的SQL Trace会非常庞大，SQLSERVER就受不了。
这里总结一下，在做不同的问题分析时，经常要用到的事件
Database事件组
当DBA要监视数据文件和日志文件的自动增长与自动收缩的时候，可以选择收集Database事件组下面的这些事件，不过如果只是关心文件大小是什么时候变化的，可以定期运行TSQL脚本，或者使用性能监视器。如果要分析是什么操作触发了文件大小变化，可以使用SQL Trace。
Errors and Warnings事件组
这些事件会搜集SQL里发生的所有错误和警告信息。如果SQL运行不正常，很可能这些事件会有反映。所以建议每次收集时，都把这个事件组的事件全都选上这个事件组也能从一个角度反映性能问题。例如，attention事件记录了每一个客户端取消的请求。运行超时command timeout就是其中一个类型。如果你发现一个语句运行了15秒或30秒，然后紧跟着一个attention事件，就说明这里发生了一个客户端的command timeout。而hash warning，missing column statistics，missing join predicate，sort warning很可能伴随着一个运行速度不理想的语句
Locks事件组
dead lock graph，lock：deadlock，lock：deadlock chain这三个事件是跟踪死锁的。因为死锁在SQL里发生的频率不会太高，所以在做死锁问题的时候，可以把他们三个都选上。但是要注意，要先选上“显示所有列”，再选事件，因为有些重要的字段默认的模板里没有选上。
Lock:Timeout和Lock：Timeout（timeout>0）在发生阻塞的时候，会有Lock Timeout事件发生。可是，阻塞是SQL里为了实现事务隔离所需发生的事件，所以阻塞在SQL里发生得非常普遍。收集这两个事件对问题分析的帮助不会太大。还不如用性能监视器里SQLSERVER：Locks-Lock Timeouts/sec在生产环境上，要尽可能避免使用他们
“Performance”事件组
所以如果要收集执行计划，结果日志肯定会很大。所以一定要在必要的时候，才加入执行计划事件
“Security Audit”事件组
看到拒绝的时间和理由。
“Server”事件组
日志里也会有包含。
“Sessions”事件组
的连接。这个事件总是要被选上的。
“Stored Procedures”事件组
这是一个很重要的事件组，事件的选择也很有讲究。常用的事件分成两类：
和编译、重编译有关的：
SP:CacheHit
SP:CacheInsert
SP:CacheMiss
SP:CacheRemove
SP:Recompile
、重编译相关的时候，才需要选择。其他问题不要选择收集这些事件。
关于存储过程运行的：
是比较小的。
RPC一样，SP:Completed事件也能包含SP:Starting的绝大部分信息。
都不会有SP:StmtCompleted,SP:StmtStarting事件。所以通过
更多的事件，有目的地收集和分析。
“TSQL”事件组
这个事件组也很重要。他的事件也分两类：
和编译、重编译相关的：
Exec PreparedSQL
Prepare SQL
SQL:StmtRecompile
Unprepare SQL
其中，SQL:StmtRecompile比较常用
关于批处理执行的：
SQL:BatchCompleted SQL:BatchStarting RPC:Completed
RPC:Starting类似
SQL:StmtCompleted SQL:StmtStarting
SP:StmtCompleted SP:StmtStarting类似
。当问题有了方向之后，再加入更多的事件，有目的地收集和分析
“Transactions”事件组
常用的事件有：
DTCTransaction：分布式事务的生命周期。正常来讲MSDTC事务在SQL里比较少，而且
容易出问题。所以可以默认就收集他。
，会产生大量记录。所以只会在遇到阻塞和死锁问题，又搞不清楚这个事务
怎麽被打开时，才会借助这个事务分析问题
TransactionLog：记录SQL向事务日志文件里写入日志的动作。这个动作在SQL里非常普遍，建议不要收集
－－－－－－总结
来总结一下，对于一般性问题，作者建议收集的事件有哪些
1、一个普通的Trace
Database：Data File Auto Grow、Data File Auto Shrink、Log File Auto Grow、Log File Auto Shrink
Errors and Warnings：除了Errorlog以外的所有事件
Locks：Deadlock Graph、Lock：Escalation（在论坛里见过）
1 ALTER TABLE dbo.Tmp_testComputeColumn SET (LOCK_ESCALATION = TABLE) 2 GO
Performance：Auto Stats
Progress Report：Online Index Operation
Security Audit：、Audit Logi、Audit Login Failed、Audit Logout、Audit Server Starts and Stops、Audit Backup/Restore Event、Audit DBCC Event
Server：所有事件
Sessions：ExistingConnection
Stored Procedures：RPC:Completed, RPC:Starting
TSQL：SQL:BatchCompleted、SQL:BatchStarting、PrepareSQL、UnprepareSQL、SQL:StmtRecompile
Transactions：DTCTransaction
如果还要缩小日志生成量，可以去掉RPC:Starting和 SQL:BatchStarting
2、一个很详细的关于性能问题的Trace
Performance：Showplan Statistics Profile
、SP:Completed、SP:Starting、SP:StmtCompleted、SP:StmtStarting
TSQL：SQL:StmtStarting、SQL:StmtCompleted
Transactions：SQLTransaction
如果要缩小日志生成量，可以去掉SP:Starting 、SP:StmtStarting、 SQL:StmtStarting。当然，每个人分析问题的方法都可能不一样，对这些事件的喜好也不一样。
上面只是两种建议的组合。在使用时可以根据实际问题作调整。另外，按照默认的模板，有些事件比较重要的数据字段可能没有被包含。
例如Performance下的“Showplan Statistics Profile”事件，如果不选Binary字段，可能整个执行计划就看不到了，Trace就白收了。所以如果要收Trace，建议把所有字段都选上