Oracle 10053 事件

 Oracle 10053 事件  

一. 10053事件
当一个SQL出现性能问题的时候，可以使用SQL_TRACE 或者 10046事件来跟踪SQL. 通过生成的trace来了解SQL的执行过程。
 

Oracle SQL Trace 和 10046 事件
http://blog.csdn.net/tianlesoftware/archive/2010/09/02/5857023.aspx

 

Event 10053 执行计划 绑定变量 Bind peeking

http://blog.csdn.net/tianlesoftware/archive/2010/04/30/5544307.aspx

 

Oracle 跟踪事件 set event

http://blog.csdn.net/tianlesoftware/archive/2009/12/13/4977827.aspx

 

 

现在来看一下10053事件。10053事件也是非公开的，在官网上也找不到相关信息。  我们在查看一条SQL的执行计划的时候，只能看到CBO 最终告诉我们的执行计划结果，但是不知道CBO 是根据什么来做的。 如果遇到了执行计划失真，如：一个SQL语句，很明显oracle应该使用索引，但是执行计划却没有使用索引。无法进行分析判断。
而10053事件就提供了这样的功能。它产生的trace文件提供了Oracle如何选择执行计划，为什么会得到这样的执行计划信息。
 

10053事件生成trace文件目录和SQL_TRACE一样。

在Oracle 10g中，SQL_TRACE生成的trace文件默认路劲是$ORACLE_BASE/admin/SID/udump.       

在Oracle 11g，trace 默认路径在：$ORACLE_BASE\diag\rdbms\orcl\orcl\trace目录下
 

对于10053事件的trace文件，我们只能直接阅读原始的trace文件，不能使用tkprof工具来处理，tkprof工具只能用来处理sql_trace 和 10046事件产生的trace文件。
 

10053事件有两个级别：
         Level 2：2级是1级的一个子集，它包含以下内容：
                            Column statistics

Single Access Paths

Join Costs

Table Joins Considered

Join Methods Considered (NL/MS/HA)

         Level 1： 1级比2级更详细，它包含2级的所有内容，在加如下内容：
                            Parameters used by the optimizer

Index statistics

 

启用10053事件：
         ALTER SESSION SET EVENTS='10053 trace name context forever, level 1';

ALTER SESSION SET EVENTS='10053 trace name context forever, level 2';

 

关闭10053事件：
ALTER SESSION SET EVENTS '10053 trace name context off';

 

 

说明：
（1）sqlplus中打开autotrace看到的执行计划实际上是用explain plan 命令得到的，explain plan 命令不会进行bind peeking。应该通过v$sql_plan查看SQL的真实的执行计划。
（2）10053只对CBO有效，而且如果一个sql语句已经解析过，就不会产生新的trace信息。
 

 

二． 示例：
1.       确定当前的trace 文件
 

1.1 设定trace 文件标识
SQL> alter session set tracefile_identifier='怀宁';

会话已更改。
 

设置标识的目的就是方便我们查找生成的trace文件。我们只需要在trace目录查找文件名里带有标识的文件即可。
 

1.2直接用如下SQL直接查出，当前的trace文件名。
 

/* Formatted on 2010/9/1 23:56:24 (QP5 v5.115.810.9015) */

SELECT      d.VALUE

         || '/'

         || LOWER (RTRIM (i.INSTANCE, CHR (0)))

         || '_ora_'

         || p.spid

         || '.trc'

            AS "trace_file_name"

  FROM   (SELECT   p.spid

            FROM   v$mystat m, v$session s, v$process p

           WHERE   m.statistic# = 1 AND s.SID = m.SID AND p.addr = s.paddr) p,

         (SELECT   t.INSTANCE

            FROM   v$thread t, v$parameter v

           WHERE   v.NAME = 'thread'

                   AND (v.VALUE = 0 OR t.thread# = TO_NUMBER (v.VALUE))) i,

         (SELECT   VALUE

            FROM   v$parameter

           WHERE   NAME = 'user_dump_dest') d;

 

2.       启动10053事件
SQL> ALTER SESSION SET EVENTS='10053 trace name context forever, level 1';

 

3.       执行事务
SQL> select * from all_tables where table_name='T';

 

4.       关闭10053事件
SQL> ALTER SESSION SET EVENTS '10053 trace name context off';

小结：
         CBO 一定是选择代价最低的数据访问路径作为SQL 的执行计划。 如果觉得CBO做出的执行计划不是最优的，就应该去分析。 这时就用到了10053事件。 我们需要关注CBO选择的每一个代价最低的数据访问方式，以及提供给CBO的分析信息是否真实。

        

CBO 只是一个数学模型，它只是机械地将收集到的各种信息通过固定的方式进行计算，如果我们提供给CBO的信息是准确的，那么CBO 就能计算出最优的执行计划（排除bug）。
        

         10053事件没有10046事件用的多，比如我们分析SQL，主要还是看SQL的执行计划和SQL_TRACE信息。 但是如果想了解CBO的内部，还得通过10053事件，从10053事件的trace文件中，我们可以深入的了解CBO的内部，了解CBO是如何工作的，根据什么依据得出最终的执行计划。

 

本文来自CSDN博客，转载请标明出处： http://blog.csdn.net/tianlesoftware/archive/2010/09/02/5859027.aspx

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

转载于:http://blog.itpub.net/611609/viewspace-683744/