关于sql plan的三个视图
db服务器突然变慢，是不是执行计划出现的跳变导致sql性能下降呢.....
oracle的执行计划经常会遭遇绑定变量窥视问题，导致执行计划变更，引起 数据库负载飙升，带来性能问题。
今天通过awr发现，等待事件第一位的是read by other session；SQL Statistics 中几乎都是同一条sql排在第一：56s18gn1k19yp 该sql一个小时内执行了3700多次。
从这种迹象来看，应该是执行计划发生了变更。 www.2cto.com
oracle 10G中可以通过下面的三个视图查询到语句的历史执行信息：
DBA_HIST_SQL_PLAN
DBA_HIST_SQLSTAT
DBA_HIST_SNAPSHOT
查看语句的历史执行信息，是否发生变化，何时发生了变化。如果发生了变化,找出以前的执行计划,与当前的执行计划进行对比,有什么不同。
通过下面的sql查询执行计划是否发生变化：
select a.INSTANCE_NUMBER,a.snap_id,a.sql_id,a.plan_hash_value,b.begin_interval_time
from dba_hist_sqlstat a, dba_hist_snapshot b
where sql_id ='56s18gn1k19yp'
and a.snap_id = b.snap_id
order by instance_number, snap_id;
SQL> select a.snap_id, a.sql_id, a.plan_hash_value,to_char(b.begin_interval_time,'yyyy-mm-dd hh24:mi:ss')
2 from dba_hist_sqlstat a, dba_hist_snapshot b
3 where sql_id ='56s18gn1k19yp'
4 and a.snap_id = b.snap_id
5 order by snap_id desc; www.2cto.com
SNAP_ID SQL_ID PLAN_HASH_VALUE TO_CHAR(B.BEGIN_INT
---------- ------------- --------------- -------------------
30569 56s18gn1k19yp 947531627 2012-03-02 14:00:30
30558 56s18gn1k19yp 947531627 2012-03-02 03:00:12
30552 56s18gn1k19yp 947531627 2012-03-01 21:00:36
30551 56s18gn1k19yp 2658265176 2012-03-01 20:00:27
30550 56s18gn1k19yp 947531627 2012-03-01 19:00:21
30535 56s18gn1k19yp 947531627 2012-03-01 04:00:31
30527 56s18gn1k19yp 947531627 2012-02-29 20:00:37
30524 56s18gn1k19yp 947531627 2012-02-29 17:00:24
30521 56s18gn1k19yp 947531627 2012-02-29 14:00:11
30519 56s18gn1k19yp 947531627 2012-02-29 12:00:04
30518 56s18gn1k19yp 947531627 2012-02-29 11:00:59
30511 56s18gn1k19yp 947531627 2012-02-29 04:00:11
30510 56s18gn1k19yp 947531627 2012-02-29 03:00:04
30502 56s18gn1k19yp 947531627 2012-02-28 19:00:27
30501 56s18gn1k19yp 947531627 2012-02-28 18:00:22
30500 56s18gn1k19yp 947531627 2012-02-28 17:00:18
30498 56s18gn1k19yp 947531627 2012-02-28 15:00:11
30497 56s18gn1k19yp 947531627 2012-02-28 14:00:07
30491 56s18gn1k19yp 947531627 2012-02-28 08:00:25
30475 56s18gn1k19yp 947531627 2012-02-27 16:00:03
30464 56s18gn1k19yp 947531627 2012-02-27 05:00:06
30463 56s18gn1k19yp 947531627 2012-02-27 04:00:00
30461 56s18gn1k19yp 947531627 2012-02-27 02:00:51
30456 56s18gn1k19yp 947531627 2012-02-26 21:00:31
30448 56s18gn1k19yp 2658265176 2012-02-26 13:00:55
30440 56s18gn1k19yp 947531627 2012-02-26 05:00:33
30439 56s18gn1k19yp 947531627 2012-02-26 04:00:25
30438 56s18gn1k19yp 947531627 2012-02-26 03:00:17
30437 56s18gn1k19yp 947531627 2012-02-26 02:00:09
30428 56s18gn1k19yp 947531627 2012-02-25 17:00:16
30423 56s18gn1k19yp 947531627 2012-02-25 12:00:51
30418 56s18gn1k19yp 947531627 2012-02-25 07:00:05
30416 56s18gn1k19yp 947531627 2012-02-25 05:00:55
30415 56s18gn1k19yp 947531627 2012-02-25 04:00:50
30406 56s18gn1k19yp 947531627 2012-02-24 19:00:52
30398 56s18gn1k19yp 947531627 2012-02-24 11:00:12
30396 56s18gn1k19yp 947531627 2012-02-24 09:00:56
30392 56s18gn1k19yp 947531627 2012-02-24 05:00:23
30391 56s18gn1k19yp 947531627 2012-02-24 04:00:11
30388 56s18gn1k19yp 947531627 2012-02-24 01:00:46
30383 56s18gn1k19yp 947531627 2012-02-23 20:00:15
30380 56s18gn1k19yp 947531627 2012-02-23 17:00:56
30377 56s18gn1k19yp 947531627 2012-02-23 14:00:37
30377 56s18gn1k19yp 2658265176 2012-02-23 14:00:37
我们注意到最近一次3月1号20点左右，执行计划发生了变化。
具体查看这两种执行计划有什么区别：
select sql_id,plan_hash_value,id,operation,options,object_owner,object_name,depth,cost,timestamp
from DBA_HIST_SQL_PLAN
where sql_id ='56s18gn1k19yp'
and plan_hash_value in (947531627,2658265176);
SQL> select plan_hash_value,id,operation,options,object_name,depth,cost,timestamp
2 from DBA_HIST_SQL_PLAN www.2cto.com
3 where sql_id ='56s18gn1k19yp'
4 and plan_hash_value in (947531627,2658265176);
PLAN_HASH_VALUE ID OPERATION OPTIONS OBJECT_NAME DEPTH COST TIMESTAMP
--------------- --- -------------------- -------------------- ------------------------------- ----- ---------- -------------------
947531627 0 SELECT STATEMENT 0 84 2011-09-27 04:33:34
947531627 1 COUNT STOPKEY 1 2011-09-27 04:33:34
947531627 2 VIEW 2 84 2011-09-27 04:33:34
947531627 3 SORT ORDER BY STOPKEY 3 84 2011-09-27 04:33:34
947531627 4 TABLE ACCESS BY INDEX ROWID BLOG_USER 4 3 2011-09-27 04:33:34
947531627 5 NESTED LOOPS 5 83 2011-09-27 04:33:34
947531627 6 HASH JOIN OUTER 6 17 2011-09-27 04:33:34
947531627 7 TABLE ACCESS BY INDEX ROWID CIRCLE_PAPER_MAIN 7 13 2011-09-27 04:33:34
947531627 8 INDEX RANGE SCAN IDX_CIRCLE_PAPER_MAIN_CID 8 3 2011-09-27 04:33:34
947531627 9 TABLE ACCESS BY INDEX ROWID CIRCLE_DISCUSS_CLASS 7 3 2011-09-27 04:33:34 www.2cto.com
947531627 10 INDEX RANGE SCAN IDX_CIRCLE_DISCUSS_CLASS_CID 8 1 2011-09-27 04:33:34
947531627 11 INDEX RANGE SCAN IDX_BLOG_USER_BLOGID 6 2 2011-09-27 04:33:34
2658265176 0 SELECT STATEMENT 0 9516 2012-02-22 15:54:33
2658265176 1 COUNT STOPKEY 1 2012-02-22 15:54:33
2658265176 2 VIEW 2 9516 2012-02-22 15:54:33
2658265176 3 SORT ORDER BY STOPKEY 3 9516 2012-02-22 15:54:33
2658265176 4 HASH JOIN RIGHT OUTER 4 8181 2012-02-22 15:54:33
2658265176 5 TABLE ACCESS BY INDEX ROWID CIRCLE_DISCUSS_CLASS 5 3 2012-02-22 15:54:33
2658265176 6 INDEX RANGE SCAN IDX_CIRCLE_DISCUSS_CLASS_CID 6 1 2012-02-22 15:54:33
2658265176 7 HASH JOIN 5 8177 2012-02-22 15:54:33
2658265176 8 TABLE ACCESS FULL CIRCLE_PAPER_MAIN 6 953 2012-02-22 15:54:33
2658265176 9 TABLE ACCESS FULL BLOG_USER 6 4954 2012-02-22 15:54:33
我们从查询结果中可以看到不同：
plan_hash_value = 947531627 --执行计划走索引
plan_hash_value = 2658265176 --执行计划走全表扫描
使用coe_xfr_sql_profile.sql可以发现两种执行计划的效率(AVG_ET_SECS)：
SQL> @coe_xfr_sql_profile.sql
Parameter 1: www.2cto.com
SQL_ID (required)
Enter value for 1: 56s18gn1k19yp
PLAN_HASH_VALUE AVG_ET_SECS
--------------- -----------
947531627 .037
2658265176 24.646
Parameter 2:
PLAN_HASH_VALUE (required)
Enter value for 2: 947531627
如何固定执行计划：
10g推荐使用sql profile来固定执行计划，coe_xfr_sql_profile.sql的本质也是调用sql profile来固定执行计划的。