SQLSERVER Profiler进行性能调优时经常用到的事件
SQLSERVER Profiler进行性能调优时经常用到的事件
SQLSERVER的一大优点，是能够把SQL里发生的很多事件记录下来，而记录下的日志通常被称为SQL Trace文件。
在SQL安装的管理工具里，有一个叫SQLSERVER Profiler的工具，可以用他来搜集和分析SQL Trace文件。
这个工具比较直观很多时候都要靠这个工具发挥他的威力呢o(∩_∩)o
开始介绍
开始介绍SQL Trace 开始菜单-》性能工具-》数据库引擎优化顾问的下面
或者在SSMS里打开
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
这个计数器看一个总的趋势。所以在实际使用中，很少选他们
Lock：Acquired 、Lock:Cancel、Lock:Escalation、Lock:Released:
这些事件能够跟踪一句语句在运行过程中对锁资源的申请和释放过程。
但是在繁忙的生产环境里，SQL会申请大量的锁资源。所以这些事件会产生大量
记录。通常情况下，只会在测试环境里，测试单条语句时，才敢把他们加上。
在生产环境上，要尽可能避免使用他们
“Performance”事件组
“Performance”事件组里的事件主要分两类：Auto Stats能够记录SQL里发生的自动
创建或更新统计信息的事件。其他有showplan字样的，是关于各种形式的执行计划
以及运行信息。他们的相同点和不同点要有目的地选择，不要重复收集
需要注意的是，执行计划一般都比较大，而每一条语句执行，都会有他的执行计划
所以如果要收集执行计划，结果日志肯定会很大。所以一定要在必要的时候，才加入执行计划事件
“Security Audit”事件组
这一组事件的目的，是监视SQL里各项和安全有关的事件，例如有人加入了一个
DB User、一个Login，有人做了数据库备份、DBCC动作，有人修改了用户密码等
如果要对SQL做安全监控，这些事件都是要考虑的
如果是要一般地监视运行，可能要选择的只有Audit Login和Audit logout
通过这两个事件，我们能够看到一个连接的生命周期。如果有用户抱怨连接
失败，也可以跟踪Audit Login Failed。如果连接请求是被SQL拒绝的，可以
看到拒绝的时间和理由
“Server”事件组
他的下面只有三个事件，Mount Tape、 Server Memory Change 、Trace File Close
这三个事件在SQL里发生的频率都不会很高，所以加进来也不会有很大影响
尤其是Server Memory Change，如果发生，对SQL性能的影响不会很大。所以
这个事件是可以经常收集的。当然，如果你同时收集了性能监视器日志，那个
日志里也会有包含
“Sessions”事件组
他只有一个事件：ExistingConnection，反映在日志开始收集的时候，SQL里已经有
的连接。这个事件总是要被选上的
“Stored Procedures”事件组
这是一个很重要的事件组，事件的选择也很有讲究。常用的事件分成两类：
和编译、重编译有关的：
SP:CacheHit
SP:CacheInsert
SP:CacheMiss
SP:CacheRemove
SP:Recompile
这些事件的量也会很大。所以只有当怀疑问题和执行计划重用、或者编译
、重编译相关的时候，才需要选择。其他问题不要选择收集这些事件
关于存储过程运行的：
RPC:Completed,RPC:Starting:应用程序调用了一个存储过程。这两个事件记录了存储过程
的开始和结束。一般的SQL应用程序，例如，使用ADO连接运行一个存储过程，在SQL
里看到的都是RPC事件
在RPC:Completed事件里，不但有结束时间，也包含开始时间。所以如果连接正常
一个RPC:Completed事件就应该包含RPC:Starting里的信息。理论上讲，只收
RPC:Completed就可以了。但是如果连接非正常地退出，或者遇到了SQL异常，
可能存储过程的运行只能看到RPC:Starting事件，看不到RPC:Completed事件，但是这种几率
是比较小的
SP:Completed,SP:Starting:如果连接是以SQL Batch的方式调用存储过程，例如
在SSMS里运行sp_who，看到的会是一组SP:Completed,SP:Starting事件。像
RPC一样，SP:Completed事件也能包含SP:Starting的绝大部分信息
SP:StmtCompleted,SP:StmtStarting:前两组事件都是以整个存储过程为单位的
一个复杂的存储过程，可能最后执行的指令数会达到几千行，甚至几万行，十几万行
（如果里面有循环逻辑）。当知道了一个存储过程慢，就要知道是哪一部分，或者
是哪一句话最慢。这时候就需要SP:StmtCompleted,SP:StmtStarting事件来帮忙
和SP:Completed、RPC:Completed不同的是，如果一个存储过程在运行过程中
被cancel了（例如，遇到了运行超时），SP:Completed、RPC:Completed都能
被抓到，但是正在运行的语句不会有SP:StmtCompleted，后面没有运行的语句
都不会有SP:StmtCompleted,SP:StmtStarting事件。所以通过
SP:StmtCompleted,SP:StmtStarting事件可以很好地看出存储过程在被终止时执行到了哪一步
但是SP:StmtCompleted,SP:StmtStarting事件会产生大量的日志记录，所以在
问题定位阶段，一般不大会加入他们。而且，为了减少事件的数目，常常
只收Completed事件，不收Starting事件。当问题有了方向之后，再加入
更多的事件，有目的地收集和分析
“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类似
相似地，在问题定位阶段，一般不会加入SQL:StmtCompleted SQL:StmtStarting
而且，为了减少事件的数目，常常只收Completed事件，不收Starting事件
当问题有了方向之后，再加入更多的事件，有目的地收集和分析
“Transactions”事件组
常用的事件有：
DTCTransaction：分布式事务的生命周期。正常来讲MSDTC事务在SQL里比较少，而且
容易出问题。所以可以默认就收集他
SQLTransaction：SQL事务的生命周期。SQL事务是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
Stored Procedures：RPC:Output Parameter、SP:CacheMiss、SP:CacheRemove、SP:Recompile、
、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，建议把所有字段都选上
