Oracle的SQL语句执行效率问题查找与解决方法
一、识别占用资源较多的语句的方法（4种方法） 1. 测试组和最终用户反馈的与反应缓慢有关的问题。 2. 利用V_$SQLAREA视图提供了执行的细节。（执行、读取磁盘和读取缓冲区的次数）
? 数据列
EXECUTIONS：执行次数 DISK_READS：读盘次数
COMMAND_TYPE：命令类型（3:select,2:insert;6:update;7delete;47:pl/sql程序单元）
OPTIMIZER_MODE：优化方式 SQL_TEXT：Sql语句
SHARABLE_MEM：占用shared pool的内存多少 BUFFER_GETS：读取缓冲区的次数 ? 用途
1、帮忙找出性能较差的SQL语句 2、帮忙找出最高频率的SQL
3、帮忙分析是否需要索引或改善联接
3. 监控当前Oracle的session，如出现时钟的标志，表示此进程中的sql运行时间较长。 4. Trace工具：
a) 查看数据库服务的初始参数：timed_statistics、user_dump_dest和
max_dump_file_size
b) Step 1: alter session set sql_trace=true c) Step 2: run sql；
d) Step 3: alter session set sql_trace=false e) Step 4:使用 “TKPROF”转换跟踪文件
f) Parse，解析数量大通常表明需要增加数据库服务器的共享池大小，
query或current提取数量大表明如果没有索引，语句可能会运行得更有效， disk提取数量表明索引有可能改进性能，
library cache中多于一次的错过表明需要一个更大的共享池大小
二、如何管理语句处理和选项 ? 基于成本（Cost Based） 和基于规则（Rule Based） 两种优化器， 简称为CBO 和RBO ? Optimizer Mode参数值:
Choose：如果存在访问过的任何表的统计数据 ，则使用基于成本的Optimizer,目标是获得最优的通过量。如果一些表没有统计数据，则使用估计值。如果没有可用的统计数据，则将使用基于规则的Optimizer
All_rows：总是使用基于成本的Optimizer，目标是获得最优的通过量 First_rows_n：总是使用基于成本的Optimizer，目标是对返回前N行（“n”可以是1，10，100或者1000）获得最优的响应时间
First_rows：用于向后兼容。使用成本与试探性方法的结合，以便快速传递前几行 RULE：总是使用基于规则的Optimizer
三、使用数据库特性来获得有助于查看性能的处理统计信息（解释计划和AUTOTRACE） No1: Explain Plan
A） 使用Explain工具需要创建Explain_plan表，这必须先进入相关应用表、视图和索引
的所有者的帐户内. (@D:\\oracle\\ora92\\rdbms\\admin\%utlxplan) B） 表结构：
STATEMENT_ID：为一条指定的SQL语句确定特定的执行计划名称。如果在EXPLAN PLAN语句中没有使用SET STATEMENT_ID，那么此值会被设为NULL。
OPERATION：在计划的某一步骤执行的操作名称，例如：Filters，Index，Table，Marge Joins and Table等。
OPTION：对OPERATION操作的补充，例如：对一个表的操作，OPERATION可能是TABLE ACCESS，但OPTION可能为by ROWID或FULL。
Object_Owner：拥有此database Object的Schema名或Oracle帐户名。 Object_name：Database Object名
Object_type：类型，例如：表、视图、索引等等 ID：指明某一步骤在执行计划中的位置。 PARENT_ID：指明从某一操作中取得信息的前一个操作。通过对与ID和PARENT_ID使用Connect By操作，我们可以查询整个执行计划树。 C） EXPLAIN搜索路径解释
? 全表扫描（Full Table Scans）(无可用索引,大量数据,小表 ,全表扫描
hints,HWM(High Water Mark), Rowid扫描) ? 索引扫描
索引唯一扫描（Index Unique Scans） 索引范围扫描（Index Range Scans）
索引降序范围扫描（Index Range Scans Descending） 索引跳跃扫描（Index Skip Scans） 全索引扫描（Full Scans）
快速全索引扫描（Fast Full Index Scans） 索引连接（Index Joins） 位图连接（Bitmap Joins）
? 如何选择访问路径： CBO首先检查WHERE子句中的条件以及FROM子句，确定有哪
些访问路径是可用的。然后CBO使用这个访问路径产生一组可能的执行计划，再通过索引、表的统计信息评估每个计划的成本，最后优化器选择成本最低的一个。 ? 表的连接方式：
Nested Loops会循环外表（驱动表），逐个比对和内表的连接是否符合条件。在驱动表比较小，内表比较大，而且内外表的连接列有索引的时候比较好。当SORT_AREA空间不足的时候，Oracle也会选择使用NL。基于Cost的Oracle优化器(CBO)会自动选择较小的表做外表。（优点：嵌套循环连接比其他连接方法有优势,它可以快速地从结果集中提取第一批记录,而不用等待整个结果集完全确定下来。缺点：如果内部行源表(读取的第二张表（内表）已连接的列上不包含索引,或者索引不是高度可选时, 嵌套循环连接效率是很低的。如果驱动行源表(从驱动表中提取的记录)非常庞大时,其他的连接方法可能更加有效。） SORT-merge JOIN，将两表的连接列各自排序然后合并，只能用于连接列相等的情况，适合两表大小相若的情况（在缺乏数据的选择性或者可用的索引时,或者两个源表都过于庞大(超过记录数的5%)时,排序合并连接将比嵌套循环连更加高效。但是,排列合并连接只能用于等价连接(WHERE D.deptno=E.dejptno,而不是WHERE D.deptno>=E.deptno)。排列合并连接需要临时的内存块,以用于排序(如果
SORT_AREA_SIZE设置得太小的话)。这将导致在临时表空间占用更多的内存和磁盘
I/O。）
HASH JOIN在其中一表的连接列上作散列，因此只有另外一个表做排序合并，理论上比SORT JOIN会快些，需要有足够的内存，而且打开了SORT_JOIN_ENABLE参数。(当缺少有用的索引时，哈希连接比嵌套循环连接更加有效。哈希连接可能比排序合并连接更快，因为在这种情况下只有一张源表需要排序。哈希连接也可能比嵌套循环连接更快，因为处理内存中的哈希表比检索B_树索引更加迅速。和排序合并连接、群集连接一样，哈希连接只能用于等价连接。和排序合并连接一样，哈希连接使用内存资源，并且当用于排序内存不足时，会增加临时表空间的I/O（这将使这种连接方法速度变得极慢）。最后，只有基于代价的优化器才可以使用哈希连接。) 索引连接:
No2: AUTOTRACE
? set autotrace 使用步骤： 1、以system登录
2、创建plustrace角色;
4、如果没有plan_table也要创建:
四、最后，使用计时特性来测量和比较处理时间 Set timing on
V$session_event
应观注一下event这列，这是我们调优的关键一列，下面对常出现的event做以简要的说明： a、buffer busy waits，free buffer waits这两个参数所标识是dbwr是否够用的问题，与IO很大相关的，当v$session_wait中的free buffer wait的条目很小或没有的时侯，说明你的系统的dbwr进程决对够用，不用调整；free buffer wait的条目很多，你的系统感觉起来一定很慢，这时说明你的dbwr已经不够用了，它产生的wio已经成为你的数据库性能的瓶颈，这时的解决办法如下：
a.1增加写进程，同时要调整db_block_lru_latches参数
示例：修改或添加如下两个参数 db_writer_processes=4
db_block_lru_latches=8
a、2开异步IO，IBM这方面简单得多，hp则麻烦一些，可以与Hp工程师联系。
b、db file sequential read，指的是顺序读，即全表扫描，这也是我们应该尽量减少的部分，解决方法就是使用索引、sql调优，同时可以增大db_file_multiblock_read_count这个参数。
c、db file scattered read,这个参数指的是通过索引来读取，同样可以通过增加db_file_multiblock_read_count这个参数来提高性能。
d、latch free,与栓相关的了，需要专门调节。
e、其他参数可以不特别观注。
本文的目的：
1、说一说Oracle的Optimizer及其相关的一些知识。
2、回答一下为什么有时一个表的某个字段明明有索引,当观察一些SQL的执行计划时,发现确不走索引的问题。
3、如果你对 FIRST_ROWS、 ALL_ROWS这两种模式有疑惑时也可以看一下这篇文章。 开始吧:
Oracle在执行一个SQL之前,首先要分析一下语句的执行计划,然后再按执行计划去执行。分析语句的执行计划的工作是由优化器(Optimizer)来完成的。不同的情况,一条SQL可能有多种执行计划,但在某一时点,一定只有一种执行计划是最优的,花费时间是最少的。相信你一定会用Pl/sql Developer、Toad等工具去看一个语句的执行计划,不过你可能对Rule、Choose、First rows、All rows这几项有疑问,因为我当初也是这样的,那时我也疑惑为什么选了以上的不同的项,执行计划就变了?
1、优化器的优化方式
Oracle的优化器共有两种的优化方式,即基于规则的优化方式(Rule-Based Optimization,简称为RBO)和基于代价的优化方式(Cost-Based Optimization,简称为CBO)。
A、RBO方式：优化器在分析SQL语句时,所遵循的是Oracle内部预定的一些规则。比如我们常见的,当一个where子句中的一列有索引时去走索引。
B、CBO方式：依词义可知,它是看语句的代价(Cost)了,这里的代价主要指Cpu和内存。优化器在判断是否用这种方式时,主要参照的是表及索引的统计信息。统计信息给出表的大小、有少行、每行的长度等信息。这些统计信息起初在库内是没有的,是你在做analyze后才出现的,很多的时侯过期统计信息会令优化器做出一个错误的执行计划,因些我们应及时更新这些信息。在Oracle8及以后的版本,Oracle列推荐用CBO的方式。
我们要明了,不一定走索引就是优的 ,比如一个表只有两行数据,一次IO就可以完成全表的检索,而此时走索引时则需要两次IO,这时对这个表做全表扫描(full table scan)是最好的。
2、优化器的优化模式(Optermizer Mode)
优化模式包括Rule,Choose,Firstrows,All rows这四种方式,也就是我们以上所提及的。如下我解释一下：
Rule:不用多说,即走基于规则的方式。
Choolse:这是我们应观注的,默认的情况下Oracle用的便是这种方式。指的是当一个表或或索引有统计信息,则走CBO的方式,如果表或索引没统计信息,表又不是特别的小,而且相应的列有索引时,那么就走索引,走RBO的方式。
First Rows:它与Choose方式是类似的,所不同的是当一个表有统计信息时,它将是以最快的方式返回查询的最先的几行,从总体上减少了响应时间。
All Rows:也就是我们所说的Cost的方式,当一个表有统计信息时,它将以最快的方式返回表的所有的行,从总体上提高查询的吞吐量。没有统计信息则走基于规则的方式。
3、如何设定选用哪种优化模式