【转载】SQL Server Profiler工具
SQL Profiler是一个图形界面和一组系统存储过程，其作用如下：
- 图形化监视SQL Server查询；
- 在后台收集查询信息；
- 分析性能；
- 诊断像死锁之类的问题；
- 调试T-SQL语句；
- 模拟重放SQL Server活动；
也可以使用SQL Profiler捕捉在SQL Server实例上执行的活动。这样的活动被称为Profiler跟踪。
1、Profiler跟踪
从开始=》所有程序=》Microsoft SQL Server 2008=》性能工具打开Profiler工具，也可以打开SQL Server Management Studio=》工具=》SQL Server Profiler。
然后选择文件=》新建=》跟踪打开一个连接窗口，选择将要跟踪的服务器实例然后连接。打开如下“跟踪属性”对话框。
如果有许多跟踪，可以提供一个跟踪名称来帮助在以后进行分类。不同的跟踪模板可帮助建立用于不同目的的跟踪。
打开跟踪属性窗口后，单击“事件选择”选项卡，为跟踪提供更详细的定义。
2、事件
一个事件表现SQL Server中执行的各种活动。这些活动可以简单地分类为事件类，游标事件，锁事件，存储过程事件和T-SQL事件是常见的事件类。
对于性能分析，主要对SQL Server上执行的各种活动的资源压力水平的事件感兴趣。资源压力主要包含如下内容：
- SQL活动涉及哪一类的CPU使用？
- 使用了多少内存？
- 涉及多少I/0操作?
- SQL活动执行了多长时间？
- 特定的查询执行的频率有多高？
- 查询面对哪类错误和警告？
下面给出跟踪查询结束的事件：
| 事件类 | 事件 | 说明 |
| Stored Procedures | RPC:Completed | RPC完成事件 |
| SP:Completed | 存储过程完成事件 | |
| SP:StmtCompleted | 在存储过程中一条SQL语句完成事件 | |
| T-SQL | SQL:BatchCompleted | T-SQL批完成事件 |
| SQL:StmtCompleted | 一条T-SQL语句完成事件 |
RPC事件表示存储过程使用远程过程调用(RPC)机制通过OLEDB命令执行。如果一个数据库应用程序使用T-SQL EXECUTE语句执行一个存储过程，那么存储过程将被转化为一个SQL批而不是一个RPC。RPC请求通常比EXECUTE请求快，因为它绕过了SQL Server中的许多语句解析和参数处理。
T-SQL由一条或多条T-SQL语句组成。语句或T-SQL语句在存储过程中也是单独和离散的。用SP:StmtCompleted或SQL:StmtCompleted事件捕捉单独的语句可能是代价很高的操作，这取决于单独语句的数量。假设系统中的每个存储过程包含且只有一条T-SQL语句。在这种情况下，完成的语句集合相当小。现在假定过程中有多条语句，而且这些过程中有些使用其他语句调用其他过程。收集所有这些额外的数据现在变成系统上非常厉害的负载。在生产机上一定要慎用。
现在回到那个事件选择面板，只有已经被选择的事件才会被显示。如果想显示所有可供选择的事件，则只需选中“显示所有事件”单选框，要添加一个跟踪事件，在Event列中查找一个事件类下的事件，并单击其左边的检查框；要删除不需要的事件，取消选中的事件选择框。
光分类就有好多的说：
下面给出其他一些与性能诊断有关的事件:
| 事件类 | 事件 | 说明 |
| Security Audit(安全审计) | Audit Login(登录审计) | 记录用户连接到SQL Server或断开连接时数据库的连接 |
| Audit Logout(注销审计) | ||
| Sessions(会话) | ExistingConnection(现有连接) | 表示所有在跟踪开始之间连接到SQL Server的用户 |
| Cursors(游标) | CursorImplicitConversion(游标隐含转换) | 表明创建的游标类型与所请求的类型个不同 |
| Errors and Warnings(错误和警告) | Attention(注意) | 表示由于客户端撤销查询或者数据库连接破坏引起请求中断 |
| Exception(异常) | 表明SQL Server发生了异常 | |
| Execution Warning(执行警告) | 表明在查询或存储过程执行期间出现了警告 | |
| Hash Warning(哈希警告) | 表明hash操作发生了错误 | |
| Missing Column Statistics(列统计丢失) | 表明优化器要求的确定处理策略用的类统计丢失 | |
| Missing Join Predicate(连接断言丢失) | 表明查询在两个表没有连接断言情况下执行 | |
| Sort Warning(排序警告) | 表明像SELECT这样的查询中执行排序操作没有合适的内存 | |
| Locks(锁) | Lock:Deadlock(死锁) | 标志着死锁的出现 |
| Lock:Deadlock Chain(死锁链) | 显示产生死锁的查询链条 | |
| lock:Timeout(锁超时) | 表示锁已经超过其超时参数，该参数由SETLOCK_TIMEOUT timeout_perious(ms)命令设置 | |
| Stored Procedures(存储过程) | SP:Recompile(重编译) | 表明用于一个存储过程的执行计划必须重编译，原因是执行计划不存在，强制的重编译，或者现有的执行计划不能重用 |
|
SP:Starting(开始) SP:StmtStarting(语句开始) |
分别表示一个SP:StmtStarting存储过程和存储过程中的一条SQL语句的开始。他们对于识别开始单因为一个操作导致Attention事件未能结束的查询很有用 | |
| Transactions(事物) | SQLTransaction(SQL事务) | 提供数据库事务的信息，包括事务开始/结束的时间、事务持续事件等信息 |
3、事件列
事件以不同的特性(被称为数据列)来表现。数据列表现一个事件的不通特性，如事件的类、用于该事件的SQL语句、事件的资源开销以及事件来源。
| 数据列 | 说明 |
| EventClass(事件类) | 事件类型，如SQL:StatementCompleted |
| TextData | 事件所用的SQL语句，如SELECT * FROM Person |
| CPU | 事件的CPU开销（以ms表示），如对一个SELECT语句，CPU=100表示该语句执行100ms |
| Reads | 为一个事件所执行的逻辑读操作数量。例如对一个SELECT语句，Reads=800表示该语句需要800次逻辑读操作 |
| Writes | 为一个事件所执行的逻辑写操作数量 |
| Duration | 事件的执行时间(ms) |
| SPID | 用于该事件的SQL Server进程标识符 |
| StartTime | 事件开始的时间 |
以上是常用的数据列，另外还有一些不太常用的数据列：
- BinaryData(二进制数据)
- IntegerData(整数数据)
- EventSubClass(事件子类)
- DatabaseID(数据库标识符)
- ObjectID(对象标识符)
- IndexID(索引标识符)
- TransactionID(事务标识符)
- Error(错误)
- EndTime(结束时间)
列数据可以重新安排以符合你自己所喜欢的风格，要控制列数据的安放，单击组织列按钮，将打开如下对话框。可以单击Up和Down按钮修改列的位置，将列移入Groups意味着它将成为一个合计列。
4、列筛选器
除了为一个Profiler跟踪定义事件和数据列之外，还可以定义各种过滤条件。这些条件帮助缩小跟踪的输出，这往往是一个好主意。下面给出常用过滤条件列表。
| 事件 | 过滤条件实例 | 用处 |
| ApplicationName(应用程序名称) | Not like:SQL Profiler | 过滤Profiler生成的事件。这是默认的行为 |
| DatabaseID(数据库标识符) | Equals: |
过滤特定数据库生成的事件。数据库ID:SELECT DB_IC('Northwind') |
| Duration(持续时间) | Greater than or equal:2 | 对于性能分析，经常会为一个大的工作负载捕捉跟踪，在大的跟踪中，许多事件日志具有比所感兴趣更小的持续周期(Duration)。过滤这个事件日志，因为几乎没有可用于优化这些SQL活动的余地 |
| Reads(读操作数) | Greater than or equal"2 | 过滤读操作较小的事件 |
| SPID |
Equals: |
定位由特定的数据库用户发送的查询 |
下面给出设置过滤列的方式：
5、跟踪模板
SQL Server Profiler可以用自定义事件、数据列和过滤器创建一个跟踪模板，然后定义一个新的跟踪，然后重用跟踪个模板来捕捉一个跟踪。定义新跟踪模板的过程类似于定义新跟踪，步骤如下：
- 创建一个新的跟踪。
- 和前面一样定义事件，数据列和过滤器。
- 从文件=》另存为菜单将跟踪定义保存为跟踪模板。
SQL Server Profiler将自动将新的模板加入到其模板列表中。
新建模板：
保存模板:
查看：
6、跟踪数据
定义了跟踪以后，单击运行按钮将开始捕捉事件并将其显示在屏幕上，可以看到一系列滚动事件，可以在我们称之为SQL TV的屏幕上看到系统的运行，可以像DVD播放机一样或多或少地控制跟踪，可以使用工具栏上的按钮暂停、开始和停止跟踪，甚至可以在工作室暂停跟踪并修改它。
一旦完成了SQL Server活动的捕捉，就可以将跟踪输出保存为一个跟踪文件或一个跟踪表。保存到跟踪文件的跟踪输出是一个原生的格式，可以由Profiler打开以分析SQL查询。将跟踪的输出保存为一个表，也可以使Profiler在跟踪表上用SELECT语句来分析其中的SQL查询。
具体的操作为 文件 =》 另存为 =》 跟踪表。选择你希望存入的的数据库和表，然后你就可以像普通表一样执行各种SQL查询。
二、跟踪的自动化
如果自动化了性能监视器捕捉到文件，又自动化了Profiler数据捕捉到一个文件。它们覆盖相同的时间段，那么就可以在SQL Profiler GUI中一起使用它们。确定跟踪有StartTime和EndTime数据字段，按照以下步骤进行：
- 打开跟踪文件(当然前提是你曾经 另存为=》跟踪文件)；
- 单击 文件=》 导入性能数据；
- 选择导入的性能监视器文件；
执行上面的操作将打开如下所示对话框，这里允许选择包含性能监视器计数器。
选择了想要包含的计数器之后，单击OK按钮将一起打开Profiler和性能监视器数据。现在，可以开始一起使用跟踪数据和性能监视器数据。如果在顶部窗口选择一个时间，它将在性能 监视器中放置一条红线，显示数据中事件发生的时间。相反，可以单击性能监视器数据，表示那段 时间的事件将被选中。这些性能工作得很好，将可以在调整过程中定时使用它们以确认瓶颈和压力 点，并确定导致这些压力的特定查询。
四、SQL Profiler使用要点
建立一个跟踪能收集许多数据供以后使用，但是这种收集可能代价很大，必须等待结果。
如果要立即捕捉系统的性能度量，特别是关于查询性能的度量，那么动态管理视图sys.dm_exec_query_stats正式所需要的。如果还需要查询运行及其单独开销的历史记录，那么跟踪仍然是更好的工具。但是，如果只需要知道这时候运行时间最长的查询或者最多的物理读操作，则可以从sys.dm_exec_query_stats得到这些信息。
因为sys.dm_exec_query_stats只是一个视图，可以简单地对其进行查询并获得服务器上查询计划统计的信息。
| 列 | 描述 |
| Plan_handle | 引用执行计划的指针 |
| Creation_time | 计划创建的时间 |
| Last_execution time | 查询最后一次使用的计划时间 |
| Execution_count | 计划已经使用的次数 |
| Total_worker_time | 从创建起计划使用的CPU时间 |
| Total_logical_reads | 从创建器计划使用的读操作数量 |
| Total_logical_writes | 从创建器计划使用的写操作数量 |
| Query_hash | 可用于识别有相似逻辑的查询的一个二进制hash |
| Query_plan_hash | 可用于识别有相似逻辑的计划的一个二jinzhihash |
为了过滤从sys.dm_exec_query_stats返回的信息，需要将其连接到其他动态管理函数上，如sys.dm_exec_sql_text可以显示与计划相关的查询文本，sys.dm_query_plan显示用于查询的执行计划。一旦连接到其他DMF，可以限制希望过滤得数据库或过程。
分类: