Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1957936
  • 博文数量: 498
  • 博客积分: 2078
  • 博客等级: 大尉
  • 技术积分: 1645
  • 用 户 组: 普通用户
  • 注册时间: 2008-11-18 22:43
个人简介

安大

文章分类

全部博文(498)

文章存档

2017年(1)

2016年(2)

2015年(21)

2014年(90)

2013年(101)

2012年(267)

2011年(16)

分类: Oracle

2014-03-25 14:11:00

Oracle诊断或调优经常需要做的就是查看SQL语句的执行计划,很多时候我们需要得到sql语句在不同场景、不同时间段的执行计划。

Oracle10g平台以上获取sql语句的执行计划的方法如下:

1. Explain Plan Command


通过explain plan命令获得sql语句的执行计划。

explain plan的命令格式如下:
sql>Explain plan for sql statement;
注:
蓝色部分可以省略;红色部分为具体sql语句
"set statement_id = ‘text’” ,其中statement_id是plan_table.statement_id,标记该条sql的id信息;
"into your plan table”,默认的plan table是plan_table
运行上述命令生成sql的执行计划,然后可以通过如下2种方式在当前session内获取该sql语句的执行计划:
?运行Explain plan 脚本$ORACLE_HOME/rdbms/admin/utlxpls.sql
    eg: sql>@$ORACLE_HOME/rdbms/admin/utlxpls.sql
?或是直接执行select * from table(dbms_xplan.display());

通过explain plan command获得sql语句的执行计划,最大的优点是不用直接运行sql语句,避免了由于返回结果时间过长过多带来的等待。

2. V$SQL_PLAN

使用dbms_xplan.display_cursor包从v$sql_plan里查看sql语句的执行计划。

sql命令如下:
sql>select plan_table_output from table(dbms_xplan.display_cursor(‘sql_id’));

注意:sql_id可以通过v$sql 视图获得。另外,v$sql_plan_statistics_all记录着sql语句的统计信息,也可以结合该视图查看到历史sql的执行计划。

3. SQL*Plus AUTOTRACE

使用autotrace功能获得sql语句的执行计划。当然这需要建立autotrace相关的plan_table、synonym等。

建立autotrace方法如下:

1、cd @oracle_homerdbms/rdbms/admin
2、#sqlplus as system
3、sql>@utlxplan
4、sql>create public synonym plan_table for plan_table
5、sql>Grant all on plan_table to public;

autotrace命令格式:
SQL>SET AUTOTRACE OFF/ON/TRACEONLY {EXPLAIN/STATISTICS}

注意:红色部分是可选项。执行”set autotrace option”后,运行的sql在返回结果结束后根据参数设置显示该条sql的执行计划或统计信息。

不同选项说明如下:


SET AUTOTRACE ON 执行sql语句返回结果,且自动显示执行计划和统计信息
SET AUTOTRACE ON Explain 打开autotrace;仅显示执行计划,不显示统计信息
SET AUTOTRACE ON Statistics 打开autotrace;仅显示统计信息,不显示执行计划
SET AUTOTRACE Traceonly sql语句仅返回结果,且自动显示explain和statistics
SET AUTOTRACE OFF 当前session关闭autotrace

 
  

4. AWRRPT

通过AWRRPT查看sql语句的执行计划。
同其他方式一样,要想获得sql语句的执行计划,必须获得该sql的sql_id。有了sql_id,并且确认该sql已经被记录在dba_hist_sqltext里,你就可以使用oracle10g提供的dbms_xplan.display_awr包显示指定sql_id的执行计划。

比如,执行一条sql,通过awrrpt获取其执行计划的步骤如下:

1)执行sql语句

sql>select /*awrshow*/ id from test order by id;

2)确认sql语句的sql_id

sql>select sql_id,sql_text from v$sql where sql_text like '%awrshow%';

3)确认该sql是否被记录在dba_hist_sqltext里

sql>select sql_id,sql_text from dba_hist_sqltext where sql_id = '****';

注意:如果没有该sql的信息,则手工设置AWR的snapshot,将sql信息记录在dba_hist_sqltext里。执行如下sql命令:
sql>exec dbms_workload_repository.create_snapshot();

4)使用dbms_xplan.display_awr的包显示指定sql_id的执行计划

sql>select plan_table_output from table(dbms_xplan.display_awr('sql_id'));

结合AWRRPT功能查看sql语句的执行计划最大的用处就是,当业务出现瓶颈或是峰值时,你可以获得异常时间段内问题sql语句的执行计划与正常表现时的进行对比。当然前提是,数据库是Oracle10g及以上版本,并使用了AWRRPT功能。

怎样看懂Oracle的执行计划
一、什么是执行计划


An explain plan is a representation of the access path that is taken when a query is executed within Oracle.


二、如何访问数据

At the physical level Oracle reads blocks of data. The smallest amount of data read is a single Oracle block, the largest is constrained by operating system limits (and multiblock i/o). Logically Oracle finds the data to read by using the following methods:
Full Table Scan (FTS)    --全表扫描
Index Lookup (unique & non-unique)    --索引扫描(唯一和非唯一)
Rowid    --物理行id


三、执行计划层次关系

When looking at a plan, the rightmost (ie most inndented) uppermost operation is the first thing that is executed. --采用最右最上最先执行的原则看层次关系,在同一级如果某个动作没有子ID就最先执行


1.看一个简单的例子:

Query Plan
-----------------------------------------
SELECT STATEMENT [CHOOSE] Cost=1234
**TABLE ACCESS FULL LARGE [:Q65001] [ANALYZED] --[:Q65001]表示是并行方式,[ANALYZED]表示该对象已经分析过了

优化模式是CHOOSE的情况下,看Cost参数是否有值来决定采用CBO还是RBO:
SELECT STATEMENT [CHOOSE] Cost=1234 --Cost有值,采用CBO
SELECT STATEMENT [CHOOSE] Cost= --Cost为空,采用RBO

2.层次的父子关系,看比较复杂的例子:

PARENT1
**FIRST CHILD
****FIRST GRANDCHILD
**SECOND CHILD

Here the same principles apply, the FIRST GRANDCHILD is the initial operation then the FIRST CHILD followed by the SECOND CHILD and finally the PARENT collates the output.


四、例子解说

Execution Plan
----------------------------------------------------------
0 **SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=8 Bytes=248)
1 0 **HASH JOIN (Cost=3 Card=8 Bytes=248)
2 1 ****TABLE ACCESS (FULL) OF 'DEPT' (Cost=1 Card=3 Bytes=36)
3 1 ****TABLE ACCESS (FULL) OF 'EMP' (Cost=1 Card=16 Bytes=304)


左侧的两排数据,前面的是序列号ID,后面的是对应的PID(父ID)。


A shortened summary of this is:
Execution starts with ID=0: SELECT STATEMENT but this is dependand on it's child objects
So it executes its first child step: ID=1 PID=0 HASH JOIN but this is dependand on it's child objects
So it executes its first child step: ID=2 PID=1 TABLE ACCESS (FULL) OF 'DEPT'
Then the second child step: ID=3 PID=2 TABLE ACCESS (FULL) OF 'EMP'
Rows are returned to the parent step(s) until finished


五、表访问方式

1.Full Table Scan (FTS) 全表扫描

In a FTS operation, the whole table is read up to the high water mark (HWM). The HWM marks the last block in the table that has ever had data written to it. If you have deleted all the rows then you will still read up to the HWM. Truncate resets the HWM back to the start of the table. FTS uses multiblock i/o to read the blocks from disk.   --全表扫描模式下会读数据到表的高水位线(HWM即表示表曾经扩展的最后一个数据块),读取速度依赖于Oracle初始化参数db_block_multiblock_read_count


Query Plan
------------------------------------
SELECT STATEMENT [CHOOSE] Cost=1
**INDEX UNIQUE SCAN EMP_I1   --如果索引里就找到了所要的数据,就不会再去访问表了


2.Index Lookup 索引扫描

There are 5 methods of index lookup:

index unique scan   --索引唯一扫描
Method for looking up a single key value via a unique index. always returns a single value, You must supply AT LEAST the leading column of the index to access data via the index.
eg:
SQL> explain plan for select empno,ename from emp where empno=10;

index range scan   --索引局部扫描
Index range scan is a method for accessing a range values of a particular column. AT LEAST the leading column of the index must be supplied to access data via the index. Can be used for range operations (e.g. > < <> >= <= between) .
eg:
SQL> explain plan for select mgr from emp where mgr = 5;

index full scan   --索引全局扫描
Full index scans are only available in the CBO as otherwise we are unable to determine whether a full scan would be a good idea or not. We choose an index Full Scan when we have statistics that indicate that it is going to be more efficient than a Full table scan and a sort. For example we may do a Full index scan when we do an unbounded scan of an index and want the data to be ordered in the index order.
eg:
SQL> explain plan for select empno,ename from big_emp order by empno,ename;

index fast full scan   --索引快速全局扫描,不带order by情况下常发生
Scans all the block in the index, Rows are not returned in sorted order, Introduced in 7.3 and requires V733_PLANS_ENABLED=TRUE and CBO, may be hinted using INDEX_FFS hint, uses multiblock i/o, can be executed in parallel, can be used to access second column of concatenated indexes. This is because we are selecting all of the index.
eg:
SQL> explain plan for select empno,ename from big_emp;

index skip scan   --索引跳跃扫描,where条件列是非索引的前导列情况下常发生
Index skip scan finds rows even if the column is not the leading column of a concatenated index. It skips the first column(s) during the search.
eg:
SQL> create index i_emp on emp(empno, ename);
SQL> select /*+ index_ss(emp i_emp)*/ job from emp where ename='SMITH';

3.Rowid 物理ID扫描

This is the quickest access method available.Oracle retrieves the specified block and extracts the rows it is interested in. --Rowid扫描是最快的访问数据方式


六、表连接方式

有三种连接方式:

1.Sort Merge Join (SMJ)    --由于sort是非常耗资源的,所以这种连接方式要避免

Rows are produced by Row Source 1 and are then sorted Rows from Row Source 2 are then produced and sorted by the same sort key as Row Source 1. Row Source 1 and 2 are NOT accessed concurrently.


SQL> explain plan for
select /*+ ordered */ e.deptno,d.deptno
from emp e,dept d
where e.deptno = d.deptno
order by e.deptno,d.deptno;

Query Plan
-------------------------------------
SELECT STATEMENT [CHOOSE] Cost=17
**MERGE JOIN
****SORT JOIN
******TABLE ACCESS FULL EMP [ANALYZED]
****SORT JOIN
******TABLE ACCESS FULL DEPT [ANALYZED]

 

Sorting is an expensive operation, especially with large tables. Because of this, SMJ is often not a particularly efficient join method.

2.Nested Loops (NL)    --比较高效的一种连接方式

Fetches the first batch of rows from row source 1, Then we probe row source 2 once for each row returned from row source 1.
For nested loops to be efficient it is important that the first row source returns as few rows as possible as this directly controls the number of probes of the second row source. Also it helps if the access method for row source 2 is efficient as this operation is being repeated once for every row returned by row source 1.

SQL> explain plan for
select a.dname,b.sql
from dept a,emp b
where a.deptno = b.deptno;

 

Query Plan
-------------------------
SELECT STATEMENT [CHOOSE] Cost=5
**NESTED LOOPS
****TABLE ACCESS FULL DEPT [ANALYZED]
****TABLE ACCESS FULL EMP [ANALYZED]

3.Hash Join    --最为高效的一种连接方式

New join type introduced in 7.3, More efficient in theory than NL & SMJ, Only accessible via the CBO. Smallest row source is chosen and used to build a hash table and a bitmap The second row source is hashed and checked against the hash table looking for joins. The bitmap is used as a quick lookup to check if rows are in the hash table and are especially useful when the hash table is too large to fit in memory.

 

SQL> explain plan for
select /*+ use_hash(emp) */ empno
from emp,dept
where emp.deptno = dept.deptno;

 

Query Plan
----------------------------
SELECT STATEMENT [CHOOSE] Cost=3
**HASH JOIN
****TABLE ACCESS FULL DEPT
****TABLE ACCESS FULL EMP

 

Hash joins are enabled by the parameter HASH_JOIN_ENABLED=TRUE in the init.ora or session. TRUE is the default in 7.3.

3.Cartesian Product    --卡迪尔积,不算真正的连接方式,sql肯定写的有问题

A Cartesian Product is done where they are no join conditions between 2 row sources and there is no alternative method of accessing the data. Not really a join as such as there is no join! Typically this is caused by a coding mistake where a join has been left out.
It can be useful in some circumstances - Star joins uses cartesian products.Notice that there is no join between the 2 tables:

 

SQL> explain plan for
select emp.deptno,dept,deptno
from emp,dept

 

Query Plan
------------------------------
SLECT STATEMENT [CHOOSE] Cost=5
**MERGE JOIN CARTESIAN
****TABLE ACCESS FULL DEPT
****SORT JOIN
******TABLE ACCESS FULL EMP

 

The CARTESIAN keyword indicate that we are doing a cartesian product.


七、运算符

1.sort    --排序,很消耗资源

There are a number of different operations that promote sorts:
order by clauses
group by
sort merge join

2.filter    --过滤,如not in、min函数等容易产生


Has a number of different meanings, used to indicate partition elimination, may also indicate an actual filter step where one row source is filtering, another, functions such as min may introduce filter steps into query plans.

3.view    --视图,大都由内联视图产生

When a view cannot be merged into the main query you will often see a projection view operation. This indicates that the 'view' will be selected from directly as opposed to being broken down into joins on the base tables. A number of constructs make a view non mergeable. Inline views are also non mergeable.
eg:
SQL> explain plan for
select ename,tot
from emp,(select empno,sum(empno) tot from big_emp group by empno) tmp
where emp.empno = tmp.empno;

 

Query Plan
------------------------
SELECT STATEMENT [CHOOSE]
**HASH JOIN
**TABLE ACCESS FULL EMP [ANALYZED]
**VIEW
****SORT GROUP BY
******INDEX FULL SCAN BE_IX


4.partition view     --分区视图

 

Partition views are a legacy technology that were superceded by the partitioning option. This section of the article is provided as reference for such legacy systems.


阅读(7652) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~