10.12.07
又一次郁闷的SQL问题
昨天晚上,应用上线,23点开始干活,前期都十分正常,大概在凌晨3点左右,应用有故障过来.一个sql从应用中执行,运行很慢很慢.
检查那个sql,其实是很简单的一个sql,就是在一个表中(约4kw记录),根据where后的三个条件作一个查询,没有表关联.
在plsql中查看该sql的执行计划,在plsql中,该sql的执行计划正常,cost为6,走的是正确的索引.
检查索引的状况,没有任何不对的地方,而且在10号表以及索引都被分析过.并且该表数据不会出现任何异动,也就是说,数据量没有大的增,删,改.
在sqlplus中explain该sql的执行计划,也正常.
让应用发起该应用,在后台捕获该sql的hash_value,然后根据hash_value到v$sql_plan中去查询sql的真实执行计划.还是正常,因为该执行计划非常之简单,就是走了个索引,cost为6.
如果将该sql中的绑定变量直接写上常量,在plsql或者sqlplus中执行,速度非常好,但是在应用上,就是很慢,应用的后台log看,就是慢在这个select上.
那么,实在没有办法,用dbms_system.set_sql_trace_in_session跟踪该sql到底在作什么,奇怪的问题,就出现了,只要我打开trace,sql执行就很快,trace文件中,没有什么异常,只要我关闭trace,sql立刻执行缓慢.
并且,我有两个一模一样的环境,一个在aix 5.3上,一个在hpux11.11上.两个机器上的表现完全相同.
实在没有办法了,将表重新分析一次,取样5%.aix上的正常了,hp上的不正常,还是慢,并且在等待全表扫描和读取临时表空间.在分析一次hp上的该表.系统正常.
实在想不明白为什么会这样,没道理的事情呀.
谁见过这种情况,还是我被oracle忽悠了下.
wangyihbu said,
October 12, 2007 at 5:28 pm
是不是应用系统的问题?
我遇到过一次一个简单的查询很慢,而且cpu负荷很高,看sql的执行计划都正常,
后来发现是应用系统的一个配置文件有问题.
d.c.b.a said,
October 12, 2007 at 8:21 pm
cost只是一个假的值,
你要看真正的执行代价, consistent gets是多少?
Thomas Zhang said,
October 12, 2007 at 9:34 pm
4千Ｗ的表，如果索引的选择性很低的话，性能差了是可想知的了．另外看看你分析的比例太小了，执行计划变化也是很有可能的．
是否采用了bind var（peeking也会导致问题,所以我这里干脆关闭了）
另外clustering_factor因子很重要，索引和表中记录的顺序一致对性能有很大提高（你可以找时候做个sort)
victor666666 said,
October 19, 2007 at 8:32 am
这个sql语句cost应该是真值。
是
victor666666 said,
October 19, 2007 at 8:33 am
是