oracle exist 10053,Oracle 10053 事件

Oracle 10053 事件

一. 10053事件

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

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

Oracle 跟踪事件 set event

现在来看一下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是如何工作的，根据什么依据得出最终的执行计划。