10046的使用和看法

10046的定义

sql_trace/10046事件是oracle提供的用于进行sql跟踪的手段，其内容包括sql的解析过程、sql的执行计划、绑定变量的使用、会话发生的等待事件。

10046生成语句方法：

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

现在随便查询一个什么，如：

select * from dba_users where rownum<20

查看trace文件

SQL> select * from v$diag_info;

里面有个Default Trace File

1 Default Trace File

/u01/app/oracle/diag/rdbms/prod1/PROD1/trace/PROD1_ora_28613.trc

10g的话，show parameter dump;找udump

10046级别

目的：获取sql、pl_sql等相关语句的执行情况解析

10046级别：共4个级别分别为0、1、4、8、12

10046事件是SQL_TRACE的扩展，被戏称为"吃了兴奋剂的SQL_TRACE"

有效的追踪级别：

① 0级：SQL_TRACE=FASLE

② 1级：SQL_TRACE=TRUE，这是缺省级别

③ 4级：1级+绑定变量

④ 8级：4级+等待事件

⑤ 12级：4级+8级

tkprof:oracle内置的针对跟踪文件格式化的一种工具

alter session set events '10046 trace name context forever, level 12'; --当前会话启用跟踪

alter session set events '10046 trace name context off'; --关闭当前会话跟踪

select sid,serial#,username from v$session where username is not null; --查询sid和serial

execute dbms_system.set_ev(sid,serial#,10046,12,''); --在当前会话对其它会话进行跟踪

execute dbms_system.set_ev(sid,serial#,10046,0,''); --在当前会话关闭其它会话跟踪

tkprof常用参数

tkprof 回车查看一下帮助就知道怎么用了 tkprof 解析源追踪文件解析完成的文件

filename 由SQL trace产生的输入跟踪文件

explain SQL语句的explain plain

recoed 创建非递归SQL语句的SQL脚本

waits 记录等待事件的汇总

SORT 根据一个或多个项目提供分类数据，如PRSCPU（CPU时间分析）、PRSELA（已用时间分析）等

table 定义表的名称，TKPROF实用程序暂时将执行计划放入该表中

sys 启用或禁用由sys给出的一组SQL语句

PRINT 仅列出指定数量的SQL语句，而不是所有的SQL语句

insert 创建存储跟踪数据库信息的脚本

与10046相关的两个参数：

show parameter max_dump_file_size;

对trace文件的大小限制

show parameter timed_statistics;

对重要信息的收集是否开启

10046怎么看？

tkprof文件都包含以下内容：

sql语句
分析执行获取调用的次数
被处理的行数
所使用CPU的秒数
所使用的IO
库高速缓存未命中
可选的执行计划
行源操作列表
一个报告，总结分析了在跟踪文件中有多少相似和完全不同的语句，如果同样的语句，parse列总是一个大值，说明没有用上绑定变量

count = number of times OCI procedure was executed。OCI为oracle的调用接口，提供了一组可对ORACLE数据库进行存取的接口子例程（函数），通过在第三代程序设计语言（如C语言）中进行调用可达到存取ORACLE数据库的目的。

cpu = cpu time in seconds executing 以秒为单位的

elapsed = elapsed time in seconds executing 以秒为单位的消耗时间

disk = number of physical reads of buffers from disk 物理读

query = number of buffers gotten for consistent read 为了一致性读获得的空间。

在一致性读模式下，所有parse、execute、fetch所获得的buffer的数量。一致性模式的buffer是用于给一个长时间运行的事务提供一个一致性读的快照，缓存实际上在头部存储了状态。

current = number of buffers gotten in current mode (usually for update) 数据库块命中的次数，通常是为了update

在current模式下所获得的buffer的数量。一般在current模式下执行insert、update、delete操作都会获取buffer。

rows = number of rows processed by the fetch or execute call 每一种调用类型所处理的行的总数

还有这些：

Misses in library cache during parse：发生在解析的硬解析数量，如果是软解析则Misses in library cache during parse将为0

Misses in library cache during execute：发生在执行调用阶段的硬解析数量。如果在执行调用时没有硬解析发生，Misses in library cache during execute这一行将不存在。

重点参考：http://czmmiao.iteye.com/blog/1493765

分析下面一段代码：

SQL ID: 00fqk94bdzqnj Plan Hash: 644658511

select sid,serial#,username

from

v$session where username is not null

call count① cpu elapsed disk query current rows

------- ------ -------- ---------- ---------- ---------- ---------- ----------

Parse 1 0.01 0.01 0 0 0 0

Execute 1 0.00 0.00 0 0 0 0

Fetch 2 0.00 0.00 0 0 0 2

------- ------ -------- ---------- ---------- ---------- ---------- ----------

total 4 0.01 0.01 0② 0 0 2

Misses in library cache during parse: 1

Optimizer mode: ALL_ROWS

Parsing user id: SYS

Number of plan statistics captured: 1

①假设count这列，fetch部分执行了17324次，获得的rows行数是259806，两者相除，就可以得出一次获取，能够获取多少行记录，一次获得15行数据，怀疑是用了数组取操作。

②理论上，elapsed time=CPU time+disk time，即如果elapsed time为1.85，CPU为1.82，那么disk可能就是3。但是也可能是有等待事件，把大量时间花在了等待事件上。

③可以通过磁盘IO所占逻辑IO的比例，disk/query+current来判断磁盘IO的情况，太大的话有可能是db_buffer_size过小，当然这也跟SQL的具体特性有关

④query+current/rows 平均每行所需的block数，太大的话（超过20）SQL语句效率太低，数据过于分散，可以考虑重组对象

⑤通过SQL ID: 06nvwn223659v Plan Hash: 0 标识出一个新的SQL分析，会发现很多是系统自己的SQL，直接不用看

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

转载于:http://blog.itpub.net/28853590/viewspace-2151123/