ITPub博客

首页 > Linux操作系统 > Linux操作系统 > tkprof和sql trace

tkprof和sql trace

原创 Linux操作系统 作者:hjgo5 时间:2019-04-23 19:03:05 0 删除 编辑

1.准备使用SQL TRACE

1) Init.ORA参数

timed_statistics设置为true(也可以在session上设置),否则不会有CPU时间信息
user_dump_dest指定trace文件生成的目录
max_dump_file_sizetrace文件的最大尺寸(单位为操作系统块),UMLIMITED表示没有限制
Oracle8以后可以在后面加上 K M 来表示文件大小
optimizer_mode定义缺省的查询优化器。虽然可以用alter session来设置,但在格式化trace文件里optimizer_mode会回复到原来的设置(一个新的session来分析SQL的执行计划),这样会产生不准确的执行计划,所以建议不要通过session来修改这个参数

注:在运行tkprof时不要加explain参数,就不存在这个问题,执行计划是Oracle在运行时所用的计划

2) 确定是以"dedicated"方式连接到数据库

 

2. 在系统中打开SQL_TRACE

Init.ORA中加入

SQL_TRACE = TRUE

这样会对系统性能造成明显的影响,建议不要使用。

 

3.session中打开SQL_TRACE

1) SQLPLUS

alter session set sql_trace=true

2) PL/SQL,由于不能执行alter session,可以使用

dbms_session.set_sql_trace(TRUE);

必须安装DBMS_SESSION包,并"直接"赋给用户alter session的权限。

3) 打开其它sessionSQL_TRACE

dbms_system.set_sql_trace_in_session(sid,serial#,TRUE)

4) event来打开

alter session set events '10046 trace name context forever,level ';

alter session set events '10046 trace name context off';

N为以下值之一:

N=1alter session set sql_trace = true
N=4可以捕获绑定变量
N=8可以捕获查询时的等待事件
N=12可以捕获绑定变量与等待事件

4.找到trace文件

trace文件名是ora_xxxx_SID.trc,其中xxxx是与Oracle连接的shadow进程的PIDSIDOracle实例的SID。文件生成在Init.ORA参数user_dump_dest指定的目录下。

 

5.tkprof格式化trace文件

 tkprof是用来解释trace文件内容,把原始的trace文件转化为容易理解的文件。使用方法为

tkprof trace文件名 报告文件名 [sort=option]

:

tkprof ora_12345_test.trc report.txt

sort参数是用来指定输出的SQL是按什么数据来排序(cpu时间或elapsed时间,详见tkprof的使用参数说明)

report.txt中有关于每个SQLparse/execute/fetch/disk read/buffer get/cpu time/执行计划(包括每一步运行时的行数),样例如下:

select *
from
 reverse_test where id=23456


call     count       cpu      elapsed       disk      query    current        rows
-------   ------      --------    ----------    ----------   ---------- ----------     ----------
Parse         1         0.01        0.00              0            0             0              0
Execute      1        0.00        0.00              0            0             0              0
Fetch          2        0.01        0.06              2            4             0               1
-------   ------      --------    ----------    ----------   ---------- ----------     ----------
   total        4        0.02         0.06              2            4             0               1

Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 27

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  TABLE ACCESS BY INDEX ROWID REVERSE_TEST
      2   INDEX RANGE SCAN (object id 5833)

report.txt文件头有各个数据的解释,根据以下一些指标可以分析一下SQL的执行性能:

query+current/rows平均每行所需的block数,太大的话(超过20SQL语句效率太低
Parse count/Execute countparse count应尽量接近1,如果太高的话,SQL会进行不必要的reparse。要检查Pro*C程序的MAXOPENCURSORS是不是太低了,或不适当的使用的RELEASE_CURSOR选项
rows Fetch/FetchFetch Array的大小,太小的话就没有充分利用批量Fetch的功能,增加了数据在客户端和服务器之间的往返次数。在Pro*C中可以用prefetch=NN,Java/JDBC中可调用SETROWPREFETCH,PL/SQL中可以用BULK COLLECT,SQLPLUS中的arraysize(缺省是15)
disk/query+current磁盘IO所占逻辑IO的比例,太大的话有可能是db_buffer_size过小(也跟SQL的具体特性有关)
elapsed/cpu太大表示执行过程中花费了大量的时间等待某种资源
cpu OR elapsed太大表示执行时间过长,或消耗了大量的CPU时间,应该考虑优化
执行计划中的Rows表示在该处理阶段所访问的行数,要尽量减少

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

上一篇: Explain的使用
下一篇: autotrace的使用
请登录后发表评论 登录
全部评论

注册时间:2005-03-03

  • 博文量
    58
  • 访问量
    43459