使用TKPROF查看跟踪文件

tkprof是安装数据自带的查看跟踪文件的命令工具，其将跟踪文件xx.trc转化为易于阅读的xx.prf文件，其在创建跟踪文件的同时也可以运行tkprof程序。

TKPROF语法格式：
    tkprof tracefile outputfile [explain= ] [table= ] [print= ] [insert= ] [sys= ] [sort= ] [waits=] [aggregate = ] [record=]

TKPROF选项：

参数值	定义
tracefile	SQL Trace的跟踪文件名称，例如sid_ora_pid.trc
output_file	TKPROF写入的跟踪文件转换格式后的名字，例如sid_ora_pid.prf
print=number	包含在输出结果中的语句数目，如果没有这个参数，TKPROF将输出列中的所有的语句，输出跟踪文件中几条解析的SQL数目，如果设置为5，则只能在prf文件中看到5条SQL
Explain =username/password	在跟踪文件里对用户的SQL进行explain plan,这个用户创建自己的paln_table,因此用户需要创建表和创建表空间的权限。在TKPROF运行结束会删除这个表。确保使用的解析游标（运行查询）的用户的用户密码是正确，从而确保是该用户的explain table
insert=filename	生成创建表的脚本，并为跟踪的每条SQL语句存储跟踪文件统计
record=filename	生成一个保存用户所有SQL语句的文件
sys=yes|no	这个选项可以再输出结果里不显示请求递归SQL语句的用户（由sys执行）。默认是YES，递归的SQL通常包括内部调用和表的维护，比如在插入操作时将区extent添加到表中。设置为NO不显示除了sys用户调用以外的SQL
sort=parameters	排序选项 prscnt  number of times parse was called 解析阶段消耗的时间 prscpu  cpu time parsing 解析阶段消耗的CPU时间 prsela  elapsed time parsing prsdsk  number of disk reads during parse prsqry  number of buffers for consistent read during parse prscu   number of buffers for current read during parse prsmis  number of misses in library cache during parse execnt  number of execute was called execpu  cpu time spent executing执行的CPU时间 exeela  elapsed time executing exedsk  number of disk reads during execute 指定阶段的磁盘度 exeqry  number of buffers for consistent read during execute execu   number of buffers for current read during execute 指定阶段的内存读 exerow  number of rows processed during execute执行阶段处理的行数 exemis  number of library cache misses during execute fchcnt  number of times fetch was called fchcpu  cpu time spent fetching 数据提取阶段的CPU时间 fchela  elapsed time fetching fchdsk  number of disk reads during fetch 数据提取阶段的硬盘读 fchqry  number of buffers for consistent read during fetch fchcu   number of buffers for current read during fetch 数据读取阶段的内存读 fchrow  number of rows fetched 取出的行数 userid  userid of user that parsed the cursor 多个排序操作可以使用,sort = para1 sort=para2
waits=yes|no	任何等待事件的记录概要
aggregate=yes|no	如果值为NO，TKPROF不会组合相同的SQL文本为多个用户
table=schema.table	TKPROF在将执行计划写入输出文件之前临时放置他们的表

     































































TKPROF举例：

         例1 列出5个打头的CPU的时间（数据提取+执行+解析）的结果

         tkprof testdb_ora_29541_MYSQLTRACE.trc 29541.prf explain=system/oracle sort=fchcpu,execpu,prscpu print=5

         例2 忽略掉所有递归语句

         tkprof testdb_ora_6214.trc testdb_ora_6214_02.prf explain=system/oracle sys=no

         例3 创建一个文件，文件内容是建立一个表，并向其中插入通过跟踪得到的记录

         tkprof testdb_ora_6214.trc testdb_ora_6214_05.prf explain=scott/tiger  insert=insert_name

         例4 创建显示跟踪会话的文件

         tkprof testdb_ora_6214.trc testdb_ora_6214_06.prf explain=system/oracle  record=record_name

         TKPROF输出文件内容：

         其输出内容主要包括SQL语句、统计、信息和Explan Plan等。

        

         ①SQL语句

         TKPROF输出文件第一部分就是SQL语句，和所执行的SQL完全一样，包括SQL语句里的任何提示和注释，输出也会保留这些内容，where语句中的谓词如果有绑定变量：1会显示绑定变量：1而不是实际的文本内容。

 

         ②统计部分

         包含这条SQL语句以及为了满足该语句而生成的所有的递归SQL语句统计。该信息有8部分组成，第一列是对数据库的调用类型（分析parse，执行execute，数据提取fetch），每种调用类型生成单独的一行统计。其中parse是SQL语句被放入内存（shared pool里的 lib cache）中的方式，execute是实际执行的语句，而fetch是从结果中获取数据。每种类型的统计描述如下：

列	定义
call	SQL统计 调用类型，parse execute fetch
count	这种类型的调用次数
cpu	这个语句中所有这种类型的调用总CPU时间，如果没有设置参数timed_statistics为true,这个统计值和elapsed统计值会是0.
elapsed	这次调用的总消耗时间
disk	为了满足这次调用，从磁盘检索的数据块数目，就是物理读取数
query	进行这次调用从内存检索的数据缓冲区数目。其中select语句通常在这种模式下检索缓冲区，也就是一致性读的数量
current	进行这种类型的调用从内存检索的数据缓冲区数目。这种模式下，insert,update,delete,尽管select 也会使用少量缓冲区，也就是数据库读的数量
rows	这条语句处理的总行数。Select语句所有处理的行数将出现在fetch统计行中，insert、update、delete都出现在execute中。

 

         ③信息部分

         信息部分包含了分析和执行调用中丢失的库缓存的数量信息。如果丢失率很高，则说明共享池大小出问题，硬蛋对库缓存的命中率和重载率进行检查。另外这部分信息还包括最近分析这条语句的用户名和当前优化器模式设置信息。

        

 

         ④行源操作部分

         行源操作部分列出了交叉引用行操作中涉及的行的数目。其可以用来查看是否有数据库对象在执行跟踪后发生了变化。

        

         ⑤执行计划explain paln

         EKPROF输出文件里最重要的信息部分，这部分第一列就是执行计划中每一行语句所处理的行数。与explian plan中每行语句处理的行数相比，如果fetch的行数较低，就需要特别注意这条语句了，这个计划会在EKPROF使用explian option选项时生成，如果想要查看SQL最初运行时生成的计划，可以用row source operation plan命令。

TKPROF输出信息问题追踪：

 

问题	解决方案
解析阶段的值太高	可能需要增大shared_pool_size
磁盘读取量太高	没有使用索引或者根本没有索引
Query和current值太高	索引的选择性不好，删除、限制索引。使用直方图或位图索引或许可以提高性能。表连接顺序或者索引连接顺序不好也有可能导致此种情况。
解析时间太长	可能打开游标数量有问题
Explain里每一行处理的行数相对于其他语句而言太多	可能表示有索引对唯一键（列上的唯一值）进行了较差分布。还可能是语句写的较差。
解析期间库缓存丢失率大于1	表明需要重载这条语句，可以增大init.ora文件中的shared_pool_size,或者执行一次较好的共享SQL任务。

 

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/27067062/viewspace-2127398/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/27067062/viewspace-2127398/