主要从SQL执行信息(v$sql,gv$sql...)和SQL执行计划(v$sql_plan,gv$sql_plan,v$sql_plan_statistics_all...)的特点上来讨论,比如:
1.OLTP环境下,v$sql上executions>1000的,单次elapsed_time>3s,就认为可能SQL属于高耗SQL,需要关注。。。
2.执行计划有笛卡尔积运算的,需要关注。。。
3.OLTP环境下,SORT MERGE JOIN的需要关注。。。
4.谓词出现显示函数运算或自动函数索引或数学运算,运算在索引列上的需要关注。。。
5.执行计划有FILTER多子操作,且父操作card估算超过1000的。。。需要关注



1. 索引建立的不合理。
2.N久没有收集统计信息。
3.一个表的名字出现多次,造成对表的多次 scan 。

btree index 出现bitmap conversion

1. SQL文本比较长,一眼看上去比较复杂
2. 没有恰当地使用INDEX
3. (老版中)统计信息收集不及时,与实际差异较大
4. 涉及的表没有进行有效的段空间维护,使得数据实际小,而高水位很高
5. 对其调整是要用到执行计划
6. 复杂的SQL,DBA会做等价改写

1.SQL里面嵌入自定义函数反复执行。
2.动态SQL使用硬解析,没有使用绑定变量。

1:同一个表关联了多次,看看是否可能消除不必要的连接。有的时候是因为使用了视图所导致的,这点我一般会看一下。
2:过多层的NL。要看看数据返回量与优化器的评估量之间的差别。

1、统计信息没问题时,且cost >100,0000,可能业务逻辑有问题, 需要重视;
2、cost < 1000 且 executions > 60s 的, 可能执行计划有问题, 需要重视;
3、SQL 执行计划包括 ‘PARTITION RANGE ALL’  没加分区条件的, 需要重视;【博客:http://blog.itpub.net/28602568/viewspace-1250423/】
4、一个SQL的执行计划出现了5次全扫,可能遗漏可能加的索引条件,需要重视;
5、执行计划出现('MERGE JOIN CARTESIAN','FILTER'),可能情况(统计信息问题、少关联条件