SQL执行计划改变导致数据库慢

      昨天晚班到今天凌晨4:30,应用作过修改后,进行测试,发现系统极慢,发现对数据库在一张156G的表从v$session_longops可以看出来在做全表扫描,把语句找出来,查看执行计划后,发现执行计划中大表是走的unique index代入值后,手工执代入值后行很快能完成.  接着查看这个语句的历史执行计划,发现发生了改变. 通过对这个语句的表grant 授权操作之后,应用测试这个功能的部分可以成功,但ATM部分还是出不来. 只有将部发表的将上次分析的统计信息导回来,导回来后,应用测试成功.问题解决.

回头想了一下:当时语句抓出来之后，代入值发现执行正常（其实是这条ＳＱＬ已经重新bind_peeking和parse了），想可能执行计划没有变在查看这条ＳＱＬ的计划变化历史没注意到已经发生改变，之后转了一圈之后，再仔细看了一下，发现确实改变了，看数据要仔细，优其在人疲劳的时候，否则将浪费宝贵的时间.

--查看执行计划变化历史:
SELECT snap_time,a.* FROM perfstat.stats$sql_plan_usage a, perfstat.stats$snapshot b WHERE a.snap_id=b.snap_id
AND a.hash_value=:hash_value ORDER BY snap_time DESC

--   根据异常的SQL的hash_value:原来表分析的统计信息导回数据库select 'EXEC DBMS_STATS.IMPORT_TABLE_STATS(OWNNAME=>'||''''||object_owner||''''||','||'TABNAME=>'||''''||object_name||''''||','||'STATOWN=>'||''''||'PERFSTAT'||''''||','||'STATTAB=>'||''''||'NAME_STAT'||''''||','||'CASCADE=>TRUE'||','||'STATID=>1'||','||'no_invalidate=>true'||')'||';' from (select distinct object_name,object_owner from v$sql_plan where operation='TABLE ACCESS' and object_owner='OWNER' and optimizer='ANALYZED' and hash_value='hash_value');

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10834762/viewspace-469847/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/10834762/viewspace-469847/