【技术】执行计划 --- 几种方式

看Oracle的执行计划：

 

1. 使用SQL_TRACE （set autotrace trace[only]）

2. V$sql_plan

3. EXPLAIN PLAN

4. 10046 event

5. set autotrace ....

 

 

 

1. 使用SQL_TRACE

   a). 全局的：  在参数文件(pfile/spfile)中指定:   sql_trace =true

 

   b).自己的：

       alter session set sql_trace=true;  

        alter session set sql_trace=false;

 

   c). 别的session

       通过Oracle提供的系统包DBMS_SYSTEM. SET_SQL_TRACE_IN_SESSION来完成    

 

 

   通过这种方法，可以得到执行路径

 

2. 直接查V$SQL_PLAN

    视图V$SQL_PLAN提供了一种方式检查那些执行过的并且仍在缓存中的cursor的执行计划。

 　通常，本视图提供的信息与打印出的EXPLAIN PLAN非常相似，不过，EXPLAIN PLAN显示的是理论上的计划，并不一定在执行的时候就会被使用，但V$SQL_PLAN中包括的是实际被使用的计划。获自EXPLAIN PLAN语句的执行计划跟具体执行的计划可以不同，因为cursor可能被不同的session参数值编译(如，HASH_AREA_SIZE)。视图提供了一种方式检查那些执行过的并且仍在缓存中的cursor的执行计划。

  动态性能表V$SQL_PLAN

 

本视图提供了一种方式检查那些执行过的并且仍在缓存中的cursor的执行计划。
 

　　通常，本视图提供的信息与打印出的EXPLAIN PLAN非常相似，不过，EXPLAIN PLAN显示的是理论上的计划，并不一定在执行的时候就会被使用，但V$SQL_PLAN中包括的是实际被使用的计划。获自EXPLAIN PLAN语句的执行计划跟具体执行的计划可以不同，因为cursor可能被不同的session参数值编译(如，HASH_AREA_SIZE)。

V$SQL_PLAN中数据可以：　　确认当前的执行计划
　　鉴别创建表索引效果
　　寻找cursor包括的存取路径(例如，全表查询或范围索引查询)
　　鉴别索引的选择是否最优
　　决定是否最优化选择的详细执行计划(如，nested loops join)如开发者所愿。

　　本视图同时也可被用于当成一种关键机制在计划对比中。计划对比通常用于下列各项发生改变时：

　　删除和新建索引
　　在数据库对象上执行分析语句
　　修改初始参数值
　　从rule-based切换至cost-based优化方式
　　升级应用程序或数据库到新版本之后

　　如果之前的计划仍然在(例如，从V$SQL_PLAN选择出记录并保存到oracle表中供参考)，那么就有可能去鉴别一条SQL语句在执行计划改变后性能方面有什么变化。

注意：
Oracle公司强烈推荐你使用DBMS_STATS包而非ANALYZE收集优化统计。该包可以让你平行地搜集统计项，收集分区对象(partitioned objects)的全集统计，并且通过其它方式更好的调整你的统计收集方式。此处，cost-based优化器将最终使用被DBMS_STATS收集的统计项。浏览Oracle9i Supplied PL/SQL包和类型参考以获得关于此包的更多信息。

不过，你必须使用ANALYZE语句而非DBMS_STATS进行统计收集，不涉及cost-based优化器，就像：
·使用VALIDATE或LIST CHAINED ROWS子句
·在freelist blocks上收集信息。

V$SQL_PLAN中的常用列：

除了一些新加列，本视图几乎包括所有的PLAN_TABLE列，那些同样存在于PLAN_TABLE中的列拥有相同的值：
ADDRESS：当前cursor父句柄位置
HASH_VALUE：在library cache中父语句的HASH值。
ADDRESS和HASH_VALUE这两列可以被用于连接v$sqlarea查询 cursor-specific 信息。
CHILD_NUMBER：使用这个执行计划的子cursor数
列ADDRESS,HASH_VALUE以及CHILD_NUMBER可被用于连接v$sql查询子cursor信息。
OPERATION: 在各步骤执行内部操作的名称，例如：TABLE ACCESS
OPTIONS: 描述列OPERATION在操作上的变种，例如：FULL
OBJECT_NODE: 用于访问对象的数据库链接database link 的名称对于使用并行执行的本地查询该列能够描述操作中输出的次序。
OBJECT#: 表或索引对象数量
OBJECT_OWNER: 对于包含有表或索引的架构schema 给出其所有者的名称
OBJECT_NAME: 表或索引名
OPTIMIZER: 执行计划中首列的默认优化模式；例如，CHOOSE。比如业务是个存储数据库，它将告知是否对象是最优化的。
ID: 在执行计划中分派到每一步的序号。
PARENT_ID: 对ID 步骤的输出进行操作的下一个执行步骤的ID。
DEPTH: 业务树深度(或级)。
POSITION: 对于具有相同PARENT_ID 的操作其相应的处理次序。
COST: cost-based方式优化的操作开销的评估，如果语句使用rule-based方式，本列将为空。
CARDINALITY: 根据cost-based方式操作所访问的行数的评估。
BYTES: 根据cost-based方式操作产生的字节的评估，。
OTHER_TAG: 其它列的内容说明。
PARTITION_START: 范围存取分区中的开始分区。
PARTITION_STOP: 范围存取分区中的停止分区。
PARTITION_ID: 计算PARTITION_START和PARTITION_STOP这对列值的步数
OTHER: 其它信息即执行步骤细节，供用户参考。
DISTRIBUTION: 为了并行查询，存储用于从生产服务器到消费服务器分配列的方法
CPU_COST: 根据cost-based方式CPU操作开销的评估。如果语句使用rule-based方式，本列为空。
IO_COST: 根据cost-based方式I/O操作开销的评估。如果语句使用rule-based方式，本列为空。
TEMP_SPACE: cost-based方式操作(sort or hash-join)的临时空间占用评估。如果语句使用rule-based方式，本列为空。
ACCESS_divDICATES: 指明以便在存取结构中定位列，例如，在范围索引查询中的开始或者结束位置。
FILTER_divDICATES: 在生成数据之前即指明过滤列。

CONNECT BY操作产生DEPTH列替换LEVEL伪列，有时被用于在SQL脚本中帮助indent PLAN_TABLE数据

V$SQL_PLAN中的连接列
　　列ADDRESS,HASH_VALUE和CHILD_NUMBER被用于连接V$SQL或V$SQLAREA来获取cursor-specific信息，例如，BUFFER_GET,或连接V$SQLTEXT获取完整的SQL语句。
Column View Joined Column(s)
ADDRESS, HASH_VALUE V$SQLAREA ADDRESS, HASH_VALUE
ADDRESS,HASH_VALUE,CHILD_NUMBER V$SQL ADDRESS,HASH_VALUE,CHILD_NUMBER
ADDRESS, HASH_VALUE V$SQLTEXT ADDRESS, HASH_VALUE


确认SQL语句的优化计划
　　下列语句显示一条指定SQL语句的执行计划。查看一条SQL语句的执行计划是调整优化SQL语句的第一步。这条被查询到执行计划的SQL语句是通过语句的HASH_VALUE和ADDRESS列识别。分两步执行：

1.SELECT sql_text, address, hash_value FROM v$sql
WHERE sql_text like '%TAG%';

SQL_TEXT ADDRESS HASH_VALUE
-------- -------- ----------
82157784 1224822469


2.SELECT operation, options, object_name, cost FROM v$sql_plan
WHERE address = '82157784' AND hash_value = 1224822469;

OPERATION OPTIONS OBJECT_NAME COST
-------------------- ------------- ------------------ ----
SELECT STATEMENT 5
SORT
AGGREGATE
HASH JOIN 5
TABLE ACCESS FULL DEPARTMENTS 2
TABLE ACCESS FULL EMPLOYEES 2
 

 

3. EXPLAIN PLAN

    见“ORACLE EXPLAIN PLAN的总结”

 

 

    explain plan set statement_id='名字' for SQL语句

    SELECT A.OPERATION,OPTIONS,OBJECT_NAME,OBJECT_TYPE,ID,PARENT_ID
       FROM PLAN_TABLE  a
       WHERE STATEMENT_ID='名字'
       ORDER BY Id;

 

4. 用10046event 进行trace，分析trace文件；

  a) 自己session，可用 alter session set events ('10046 trace name context forever, level 12 );

                               alter session set events ('10046 trace name context off' );

  b) 别人的，用dbms_system.set_ev( sid, serial#, 10046, 12, 'context' );

                    dbms_system.set_ev( sid, serial#, 10046, 0, 'context' );

 

 

5. set autotrace:

   Elapsed: 00:00:01.59

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=120 Card=28724 Bytes
          =344688)

   1    0   TABLE ACCESS (FULL) OF 'TT2' (Cost=120 Card=28724 Bytes=34
          4688)





Statistics
----------------------------------------------------------
        307  recursive calls
          0  db block gets
       1247  consistent gets
       1199  physical reads
          0  redo size
        306  bytes sent via SQL*Net to client
        373  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          7  sorts (memory)
          0  sorts (disk)
          0  rows processed

 

资料：

使用SQL_TRACE进行数据库诊断