Oracle事件之10053 跟踪的trace文件相关解释
一. 10053事件
当一个SQL出现性能问题的时候，可以使用SQL_TRACE 或者 10046事件来跟踪SQL. 通过生成的trace来了解SQL的执行过程。 我们在查看一条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
1.1启用10053事件：
ALTER SESSION SET EVENTS='10053 trace name context forever, level 1'; ALTER SESSION SET EVENTS='10053 trace name context forever, level 2';
1.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信息。
二． 实验10053事件：
1.设定当前的trace 文件
1.1 设定trace 文件名称
SQL> alter session set tracefile_identifier='10053事件'; 会话已更改。
设置标识的目的就是方便我们查找生成的trace文件。我们只需要在trace目录查找文件名里带有标识的文件即可。
1.2直接用如下SQL直接查出，当前的trace文件名。
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 pub_user u, pub_department dept where u.department_id = dept.department_id; SQL>Explain plan for select * from pub_user u, pub_department dept where u.department_id = dept.department_id;
4.关闭10053事件
SQL> ALTER SESSION SET EVENTS '10053 trace name context off';
三． 查看生成的trace文件
在此之前设置了标识，所以直接进入trace目录，找到含有 ‘10053事件’标识的trace 文件。
Trace file D:\oracle\product\10.2.0\admin\dw\udump/10053事件.trc
四、10053事件内容解析
1. Predicate Move-Around (PM)(对SQL语句的谓词进行分析、重写，把它改为最符合逻辑的SQL语句)
2. 解释trace文件用到的一些缩写的指标定义
3. Peeked values of the binds in SQL statement(绑定变量的描述)
4. Bug Fix Control Environment(一些修复的bug信息)
5. PARAMETERS WITH DEFAULT VALUES(性能相关的初始化参数)
6. BASE STATISTICAL INFORMATION(SQL引用对象的基本信息)
7. CBO计算每个对象单独访问的代价
8. CBO计算列出两个表关联方式，并计算出每一种关联方式的代价，最终选择最小的cost
五、实验：10053事件的妙用
在我们写sql时，一条明显可以查询出来数据的语句，为什么我们写完之后却不返回数据？这时，10053可以解答我们的疑问。
见如下order by 查不出数据实验：
---10.2.0.1版本加了order by查不出数据实验 Drop table test1 purge; Drop table test2 purge; create table test1 (id number(20),name varchar2(20)); insert into test1 values (1,'A'); insert into test1 values (2,'A'); insert into test1 values (3,'A'); insert into test1 values (4,'A'); insert into test1 values (5,'B'); insert into test1 values (6,'B'); insert into test1 values (7,'C'); insert into test1 values (8,'C'); insert into test1 values (9,'C'); insert into test1 values (10,'C'); create table test2 (id number(20),name varchar2(20)); insert into test2 values (1,'A'); insert into test2 values (2,'A'); insert into test2 values (3,'A'); insert into test2 values (4,'A'); insert into test2 values (5,'A'); insert into test2 values (6,'A'); insert into test2 values (7,'A'); insert into test2 values (8,'B'); insert into test2 values (9,'C'); insert into test2 values (10,'C');
SELECT * FROM (SELECT * FROM (SELECT INNER_TABLE.*, ROWNUM OUTER_TABLE_ROWNUM FROM (select test2.* from test2, (SELECT t.id, t.name FROM test1 T WHERE T.id = (SELECT MAX(T1.id) FROM test1 T1 WHERE T.name = T1.name)) test1 where test2.name = test1.name order by test2.name ---加上order by就没有数据 ) INNER_TABLE) WHERE OUTER_TABLE_ROWNUM <= 18) OUTER_TABLE WHERE OUTER_TABLE_ROWNUM > 0;
SELECT * FROM (SELECT * FROM (SELECT INNER_TABLE.*, ROWNUM OUTER_TABLE_ROWNUM FROM (select test2.* from test2, (SELECT t.id, t.name FROM test T WHERE T.id in (SELECT MAX(T1.id) FROM test T1 group by name)) test1 where test2.name = test1.name order by test2.name) INNER_TABLE) WHERE OUTER_TABLE_ROWNUM <= 18) OUTER_TABLE WHERE OUTER_TABLE_ROWNUM > 0;
<
<<
<<
<<
<
<
<
<
<<
<
>
<<
<
<
<
>
>
<
<
>><<
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
><
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
><
>
>>
>
>
>
>
>
>
>
>
>
>
><
>
>
>
>
>
>
>
>
>
>
>
>
>
>
-
-
-
-
-
-
-
- > >
-
- >
-
- > >
-
- >
-
- >
-
- >
-
- >
-
-
-
-
-
-
-
-
-
-
- >
- >
-
- > >
-
- >
-
- >
-
- >
- >
-
- >
- > >
-
-
-
-
-
-
-
-
-
-
- >
-
-
-
-
-
-
-
-
-
-
-
-
- >
- > >
- >
- >
- >
- >
- >
-
-
-
-
-
-
-
-
-
-
- >
- >
-
- > >
-
-
- >
-
- >
-
- >
- >
