Interpreting execution plans

12
Interpreting Execution Plans 1. 执执执执执执执: 1. SQL 执执执执执执执执执执执执执执执执执执执执执; 2.执执执执执执执执执执执执执执执,执执执执执执 ; 2. 执执执执执执执执: 1. PLAN_TABLE:执执 EXPLAIN PLAN 执执执执 SQL/PLUS 执 autotrace 执执执执执执执,执执执执执执执执执; 2. v$sql_plan:执 Shared Pool 执执 Library Cache 执执执 执执执执执执执执执执; 3. v$sql_plan_monitor:11g 执执执执执执执执; 4. dba_hist_sql_plan:执 AWR 执执执执执执执执执; 5. stats$sql_plan:执执 Statspack 执执执执执执执; 6. SQL Management Base:执执 SQL Plan Management Baselines 执执执执执执执; 7. SQL tuning set; 8. DBMS_MONITOR 执执执 trace 执执:执执执 10046 执执; 9. 执 10053 执执执执执 trace 执执; 10. 10gR2 执执执 dump 执执执执; 3. 执执执执执执执执执: 1. 执执执执执执执执执执,执执执执执执执执执执执执执执执执,执执执执 SQL 执执执执执执 执,执执执执 DBMS_XPLAN 执执执执执执执执执;

description

Interpreting execution plans

Transcript of Interpreting execution plans

Page 1: Interpreting execution plans

Interpreting Execution Plans

1.执行计划的解释:

1.SQL语句的执行计划是由语句中行源的执行计划组成;

2.执行计划是使用父子关系来描述的,像一个树的结构;

2.如何查看执行计划:

1.PLAN_TABLE:是由 EXPLAIN PLAN命令或者 SQL/PLUS

的 autotrace产生的执行计划,是理论上的执行计划;

2.v$sql_plan:在 Shared Pool中的 Library Cache

中保存的实际使用的执行计划;

3.v$sql_plan_monitor:11g中的执行计划监控;

4.dba_hist_sql_plan:由 AWR报告产生的执行计划;

5.stats$sql_plan:是由 Statspack生成的执行计划;

6.SQL Management Base:是由 SQL Plan

Management Baselines产生的执行计划;7.SQL tuning set;

8.DBMS_MONITOR产生的 trace文件:相当于 10046事件;

9.由 10053事件产生的 trace文件;

10. 10gR2之后的 dump跟踪文件;

3.查看执行计划的视图:

1.如果直接查看基表的话,根本无法直接看到执行计划间的

关系,自己编写 SQL语句查看很麻烦,可以使用

DBMS_XPLAN包下面的函数来完成;

Page 2: Interpreting execution plans

2.DBMS_XPLAN.DISPLAY():用来显示 plan_table中的

执行计划;

3.DBMS_XPLAN.DISPLAY_CURSOR():用来显示

v$sql_plan中的执行计划;

4.DBMS_XPLAN.DISPLAY_AWR():用来显示 AWR中的执行

计划;

5.DBMS_XPLAN.DISPLAY_SQLSET():用来显示 SQL

tuning set中的执行计划;

6.DBMS_XPLAN.DISPLAY_SQL_PLAN_BASELINE():用来

显示 SQL Plan Management Baselines中的执行计

划;

4.EXPLAIN TABLE命令:

1.生成一个最优的执行计划,把它存在 PLAN_TABLE中,但

是并不实际执行 SQL语句;

2.语法:EXPLAIN PLAN [SET STATEMENT_ID =

'text'] [INTO plan_table] FOR statement;默

认插入到 PLAN_TABLE表中;3.PLAN_TABLE:

1.当执行 EXPLAN_PLAN命令时自动创建

PLAN_TABLE,它是一个同义词,指向

sys.plan_table$的临时表;SELECT * FROM dba_synonyms WHERE synonym_name = 'PLAN_TABLE';SELECT table_name, TEMPORARY, duration FROM dba_tables

Page 3: Interpreting execution plans

WHERE table_name = 'PLAN_TABLE$';    

 

2.可以根据$ORACLE_HOME/rdbms/admin/

utlxplan.sql脚本创建自己的表,因为默认是临

时表,只能在当前 session查看,导入到自己的表

中就可以永久保存;

3.优点是 SQL语句么有真正执行;缺点是可能不是真

正的执行计划,只有使用绑定变量时执行计划不准,

其它情况都准确;

4.表中的内容是层级结构,可以通过 ID和

PAREANT_ID列来关联;

4.DBMS_XPLAN.DISPLAY函数语

法:DBMS_XPLAN.DISPLAY(table_name, statement_id, format, filter_preds):

1.table_name:默认是 PLAN_TABLE表;

2.statement_id:默认是空,可以根据这个参数获得

指定的语句的执行计划;

Page 4: Interpreting execution plans

3.format:默认是 TYPICAL类型,其他类型查帮助文

档,显示的信息多少;

4.默认只查看上一条语句的执行计划;          

5.查看指定 statement_id的执行计划;        

Page 5: Interpreting execution plans

6.查看更多的执行计划的信息;                

5.AUTOTRACE:

1.AUTOTRACE是 sql*plus的功能,在 oracle7.3版本后

出现,也是把记录存放在 PLAN_TABLE表中;

2.需要 PLUSTRACE角色从 v$视图中检索统计信息,使用

$ORACLE_HOME/sqlplus/admin/plustrce.sql脚

本创建;

3.默认情况下,在执行完查询语句后会生成执行计划和统计

信息;

4.相当于执行了一次 EXPLAIN PLAN命令然后执行了一次

语句,如果使用绑定变量的话可能不是真实的计划;

5.语法:SET AUTOT[RACE] {OFF | ON | TRACE[ONLY]} [EXP[LAIN]] [STAT[ISTICS]];

1.ON:要显示结果和 trace信息;

Page 6: Interpreting execution plans

2.TRACEONLY:不显示结果;

6.查看当前的设置:show autotrace;

6.阅读统计信息:

1.recursive calls:递归的调用,读取数据字典,权限,列

的信息.第一次执行会很大,以后执行会变小;如果使用存

储过的话,这个值一般会很大,属于正常;可以通过清除

shared_pool测试:alter system flush shared_pool;

2.db block gets:修改当前状态的数据块的 block的块

数.只有当 DML语句会引起 db block gets增加,因为

当前块会被更新,SELECT语句的话不会增加,因为可以读

取 REDO或者构造的 CR块;

3.consistent gets:逻辑读的数量(不是 BLOCK),表示

返回记录的批次数,跟当前的 arraysize有关;

1.arraysize:表示一次返回的记录数,通过 show

arraysize命令查看;

2.粗略是算法是:consistent gets=rows

processed/arraysize,记录越多越接近;

3.优化时应该关心在相同的 arraysize下减小此值,

即减小逻辑读;

4.physical reads:物理读,即从硬盘读取的 BLOCK的数

量,BUFFER CACHE越大这个值越小,可以通过清除

Page 7: Interpreting execution plans

BUFFER CACHE测试:alter system flush buffer_cache;

5.redo size:产生的日志的数量,一般 DML语句才会产生;

6.bytes sent via SQL*Net to client:服务器发送

到客户端的字节数;

7.bytes received via SQL*Net from client:服务

器接收到客户端的字节数;

8.SQL*Net roundtrips to/from client:SQL的网络

流量的次数,也跟 arraysize参数有关;

9.sorts (memory):内存中的排序数量,主要是 PGA;

10. sorts (disk):在硬盘的排序,应该避免这个值;

11. rows processed:处理的记录数;7.v$sql_plan:

1.v$sql_plan:查看 library cahce中真正使用的执行

计划;PLAN_TABLE只是理论上的执行计划;

2.可以通过 sql_id列与 v$sql表关联,也可以使用

address和 hash_value的值;

3.主要的列:

1.HASH_VALUE:父语句在 library cache中的哈

希值;

2.ADDRESS:访问 SQL语句的句柄,即内存地址;

3.CHILD_NUMBER:使用此执行计划的子 CURSOR数

量;

Page 8: Interpreting execution plans

4.POSITION:具有相同 PARENT_ID的操作的执行顺

序;

5.PARENT_ID:跳出过程的下一个执行的过程 ID,这

个很抽象,看到执行计划,很容易理解这一点;

6.ID:每一个步骤的编号;

7.PLAN_HASH_VALUE:执行计划的哈希值;

4.查看实际的执行计划:SELECT * FROM table(DBMS_XPLAN.DISPLAY_CURSOR('sql_id'));

5.v$sql_plan_statistics:提供实际执行时的统计信息

1.当 STATISTICS_LEVEL设置为 ALL时才会收集;

2.或者语句中指定了 GATHER_PLAN_STATISTICS的hint;

3.v$sql_plan_statistics_all:获得所有的实际

执行的统计信息;

Page 9: Interpreting execution plans

6.v$sql_workarea:提供了 SQL CURSOR使用的工作区的

信息;                                      

8.AWR:

1.AWR是为了检测和自调整为目的的收集,处理,维护性能统

计信息;

2.统计信息包括:

1.对象统计信息;

2.时间模型统计信息;

3.一些系统和 session的统计信息;

4.ASH(Active Session History)统计信息;

3.自动生成性能数据的快照;

4.重要的 AWR视图: 1.V$ACTIVE_SESSION_HISTORY;2.V$metric views;3.DBA_HIST views:

1.DBA_HIST_ACTIVE_SESS_HISTORY;

Page 10: Interpreting execution plans

2.DBA_HIST_BASELINE;3.DBA_HIST_DATABASE_INSTANCE;4.DBA_HIST_SNAPSHOT;5.DBA_HIST_SQL_PLAN;6.DBA_HIST_WR_CONTROL;

5.指定 sql_id查看 AWR中的 sql的执行计划: SELECT plan_table_output FROM TABLE(DBMS_XPLAN.DISPLAY_AWR('g22czkqq3pxmb'));

6.从 AWR数据生成一个 SQL报告:@$ORACLE_HOME/rdbms/admin/awrsqrpt;

9.SQL Monitoring:11g;

10. 阅读执行计划:

1.读执行计划的顺序:

1.从上往下看,第一个没有儿子节点的节点最先执行;

2.执行执行其兄弟节点;

3.最后执行父节点;

2.就是二叉树中的后序遍历的方式:

1.前序遍历:对任一子树,先访问根,然后遍历其左子

树,最后遍历其右子树;

2.中序遍历:对任一子树,先遍历其左子树,然后访问

根,最后遍历其右子树;

3.后序遍历:对任一子树,先遍历其左子树,然后遍历

其右子树,最后访问根;

3.例子:

Page 11: Interpreting execution plans

1.执行的顺序为:356421;                  

2.执行的顺序为:43652871;                

Page 12: Interpreting execution plans

3.执行顺序为:325410;                    

4.查看执行计划的建议:

1.要使驱动表保持最好的过滤条件,即驱动表有最小的

记录;

2.每一步返回的数据尽量最小;

3.正确使用视图,只是用一层,尽量不要嵌套;

4.避免使用笛卡尔积;

11. 仅仅靠一个执行计划不能说明它是否是最好的,可以借助

SQL Tuning Advisor工具;