如何解读执行计划(中)

回述过去一段时间内sql语句执行计划（10.2提供）：

Viewing Execution Plans Using DBMS_XPLAN.DISPLAY_AWR()

Source: AWR, use DISPLAY_AWR()

Statement’s plan must have been captured by AWR

Query DBA_HIST_SQL_PLAN for available statements

dbms_xplan.display_awr (sql_id varchar2,

plan_hash_value integer default null,

db_id integer default null,

format varchar2 default ‘TYPICAL’)

If PLAN_HASH_VALUE is ommited, all children of SQL_ID displayed

SQL_IDs must be in AWR; will not display if SQL_ID is only in VACTIVESESSIONHISTORY…LookinVSQL_PLAN to verify

执行计划：id越大越先执行，通常0是表明sql语句开始，不做实际的操作。Operation指做了什么操作，种类非常多。Name代表这步操作对象名，rows这一步操作大概返回多少条记录（根据统计信息估算出来的）。02：30：00解读执行计划。离散数学对理解索引有帮助。

FTS：

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 multi-block i/o).

Logically Oracle finds the data to read by using the following methods:

Full Table Scan (FTS)

Index Look-up (unique & non-unique)

Rowid

FTS它会读自高水位以下的块，不管块里面有多少条数据。FTS使用多块I/O，数据文件离散读等待事件会发生。多块读，读多少个块由参数文件里面参数设置。这个参数并不是绝对值，它是期望值，db_file_multiblock_read_count建议我们在发生多块读的时候一次读操作读多少个块。db_file_multiblock_read_count对索引不起作用，因为索引尽可能单块读。db_file_multiblock_read_count修改成最大是多大由os决定。db_file_multiblock_read_count默认值=db_block_buffers / ( (PROCESSES+3) / 4 )，FTS扫描块也会被buffer最近最少使用淘汰出去，FTS不建议对大表使用。

默认情况执行FTS

1. 没有很好where条件。

2. where条件没有可用索引。

索引：

首先通过key定位索引结点，key值是where里面用到有索引的列，并不等同于一个列出现在where条件里面就会用这个列索引访问数据。

一个索引要被使用至少满足以下条件：

1. 作为主驱动：在索引key上面它要有谓词，也就是说索引列等于某个具体值或者用范围对个列进行比较运算。

2. 作为被动表：被动表索引列要参与连接。

3. 如果索引由多个列创建，索引第一列必须出现比较表达式里面（索引列值要与比较值类型匹配）。

如果索引key也是唯一并且做等值比较的话，那么这个唯一索引访问效率是最高的，因为只要通过key就可以找到rowid。非唯一索我引可能找的数据会很多，这就需要看索引区分度。

以下索引扫描方式：

Index unique scan

Index range scan

Index Full Scan

Index Fast Full Scan

Index skip scan

我们再看看AWR：

在两个awr报告之间实例是不能重启的，默认awr是一小时生成一次，10g以后引入新特性。

awr只能追溯某个时段数据库问题，但是对于sql还没有执行就造成数据库慢（例如：进程排队，虽然sql没有产生开销，但是在等待，也是占用系统响应时间），awr是捕获不到的。

有些等待事件是不能出现在top 5 timed events 里面的，包括：latch有关的，buffer有关的，liberary latch有关的。如果出现在top 5 timed events 里面，系统可能遇到性能问题。对于等待事件，总等待时间长，平均等待时间长，并且数据库繁忙，说明数据库遇到了性能问题。

数据文件读方式等待与索引和表有没有关系，没关系。数据文件读方式，怎么读这个块，它仅仅根怎么读这个块有关系，是读索引和还是读表跟这个等待（db file scattered read）没关系。1小时3600秒，而在top 5 timed events显示 db file scattered read等待时间81,327秒，相当于8万多秒，这是所有进程等待时间总和。