sql_trace的学习记录和实验

1、设置初始参数

参数:

timed_statistics=true 允许sql trace 和其他的一些动态性能视图收集与时间有关的参数、

max_dump_file_size=500 指定跟踪文件的大小

user_dump_dest 指定跟踪文件的路径

2、对所在用户的session启动sql_trace

(1)alter session set sql_trace=true

停止:alter session set sql_trace=false

(2)通过存储过程启动sql_trace

在sys用户下查看dbms_system的set_sql_trace_in_session

可以看到使用的情况

SQL>select sid,serial#,username from v$session;


 

SQL>exec dbms_system.set_sql_trace_in_session('142','127','true')

SQL>exec dbms_system.set_sql_trace_in_session(‘142’’127’’fasle’)

Sql_trace的文件内容包括

1.    解析、执行、返回数据的次数
2.cpu和执行命令的时间
3.物理读和逻辑读的次数
4.系统处理的记录数
5.库缓冲区错误

对10046事件说明
10046事件是Oracle提供的内部事件,是对SQL_TRACE的增强.
10046事件可以设置以下四个级别:
1 - 启用标准的SQL_TRACE功能,等价于sql_trace
4 - Level 1 加上绑定值(bind values)
8 - Level 1 + 等待事件跟踪
12 - Level 1 + Level 4 + Level 8
类似sql_trace,10046事件可以在全局设置,也可以在session级设置。

1. 在全局设置
在参数文件中增加:

event="10046 trace name context forever,level 12"

 

此设置对所有用户的所有进程生效、包括后台进程.

2. 对当前session设置
通过alter session的方式修改,需要alter session的系统权限:

SQL> alter session set events '10046 trace name context forever';

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

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

3. 对其他用户session设置
通过DBMS_SYSTEM.SET_EV系统包来实现:

但此时的可读性不强需要进行转化

此时就要使用TKPROF

tkprof 的目的是将sql trace 生成的跟踪文件转换成用户可以理解的格式
tkprof tracefile outputfile [explain= ] [table= ] [print= ] [insert= ] [sys= ] [sort= ] ...

tracefile:你要分析的trace文件

outputfile:格式化后的文件

explain=user/password@connectstring

table=schema.tablename

    注1:这两个参数是一起使用的,通过连接数据库对在trace文件中出现的每条sql语句查看执行计划,并将之输出到outputfile中

     注2:该table必须是数据库中不存在的,如果存在会报错

print=n:只列出最初N个sql执行语句

insert=filename:会产生一个sql文件,运行此文件可将收集到的数据insert到数据库表中

sys=no:过滤掉由sys执行的语句

record=filename:可将非嵌套执行的sql语句过滤到指定的文件中去

waits=yes|no:是否统计任何等待事件

aggregate=yes|no:是否将相同sql语句的执行信息合计起来,默认为yes

sort= option:设置排序选项,选项如下:

    prscnt:number of times parse was called
    prscpu:cpu time parsing
    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
    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
    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选项可同时用多个,做法是用括号括起来,中间用逗号分割:

 

C:\>tkprof c:\oc_ora_2892.trc c:\cc.txt sort=(prsela, exeela, fchela)
注意:最后排序是按照各个选项的数字之和进行排序,类似于order by (sort1+sort2+sort3),而不是order by sort1,sort2,sort3

Trace文件解释

CALL :每次SQL语句的处理都分成以下三个部分
  Parse:这步将SQL语句转换成执行计划,包括检查是否有正确的授权和所需要用到的表、列以及其他引用到的对象是否存在。
  Execute:这步是真正的由Oracle来执行语句。对于insert、update、delete操作,这步会修改数据,对于select操作,这步就只是确定选择的记录。
  Fetch:返回查询语句中所获得的记录,这步只有select语句会被执行。
COUNT:这个语句被parse、execute、fetch的次数。
CPU:这个语句对于所有的parse、execute、fetch所消耗的cpu的时间,以秒为单位。
ELAPSED:这个语句所有消耗在parse、execute、fetch的总的时间。
DISK:从磁盘上的数据文件中物理读取的块的数量。一般来说更想知道的是正在从缓存中读取的数据而不是从磁盘上读取的数据。
QUERY:在一致性读模式下,所有parse、execute、fetch所获得的buffer的数量。一致性模式的buffer是用于给一个长时间运行的事务提供一个一致性读的快照,缓存实际上在头部存储了状态。
CURRENT:在current模式下所获得的buffer的数量。一般在current模式下执行insert、update、delete操作都会获取buffer。在current模式下如果在高速缓存区发现有新的缓存足够给当前的事务使用,则这些buffer都会被读入了缓存区中。
ROWS: 所有SQL语句返回的记录数目,但是不包括子查询中返回的记录数目。对于select语句,返回记录是在fetch这步,对于insert、update、delete操作,返回记录则是在execute这步。

A、query+current/rows 平均每行所需的block数,太大的话(超过20)SQL语句效率太低
B、Parse count/Execute count parse count应尽量接近1,如果太高的话,SQL会进行不必要的reparse
C、rows Fetch/Fetch Fetch Array的大小,太小的话就没有充分利用批量Fetch的功能,增加了数据在客户端和服务器之间的往返次数。
D、disk/query+current 磁盘IO所占逻辑IO的比例,太大的话有可能是db_buffer_size过小(也跟SQL的具体特性有关)
E、elapsed/cpu 太大表示执行过程中花费了大量的时间等待某种资源
F、cpu Or elapsed 太大表示执行时间过长,或消耗了了大量的CPU时间,应该考虑优化
G、执行计划中的Rows 表示在该处理阶段所访问的行数,要尽量减少

请使用浏览器的分享功能分享到微信等