oracle查看执行最慢与查询次数最多的sql语句及其执行速度很慢的问题分析
oracle查看执行最慢与查询次数最多的sql语句
注:本文来源 于《oracle查看执行最慢与查询次数最多的sql语句》
前言
在ORACLE数据库应用调优中,一个SQL的执行次数/频率也是常常需要关注的,因为某个SQL执行太频繁,要么是由于应用设计有缺陷,需要在业务逻辑上做出优化处理,要么是业务特殊性所导致。如果执行频繁的SQL,往往容易遭遇一些并发性的问题。 那么如何查看ORACLE数据库某个SQL的执行频率/次数呢? 下面来看看完整的示例代码。
一、查询执行最慢的sql
select * from (select sa.SQL_TEXT, sa.SQL_FULLTEXT, sa.EXECUTIONS "执行次数", round(sa.ELAPSED_TIME / 1000000, 2) "总执行时间", round(sa.ELAPSED_TIME / 1000000 / sa.EXECUTIONS, 2) "平均执行时间", sa.COMMAND_TYPE, sa.PARSING_USER_ID "用户ID", u.username "用户名", sa.HASH_VALUE from v$sqlarea sa left join all_users u on sa.PARSING_USER_ID = u.user_id where sa.EXECUTIONS > 0 order by (sa.ELAPSED_TIME / sa.EXECUTIONS) desc) where rownum <= 50;
二、查询次数最多的 sql
select * from (select s.SQL_TEXT, s.EXECUTIONS "执行次数", s.PARSING_USER_ID "用户名", rank() over(order by EXECUTIONS desc) EXEC_RANK from v$sql s left join all_users u on u.USER_ID = s.PARSING_USER_ID) t where exec_rank <= 100;
三、Oracle查询SQL语句执行的耗时
select a.sql_text SQL语句, b.etime 执行耗时, c.user_id 用户ID, c.SAMPLE_TIME 执行时间, c.INSTANCE_NUMBER 实例数, u.username 用户名, a.sql_id SQL编号 from dba_hist_sqltext a, (select sql_id, ELAPSED_TIME_DELTA / 1000000 as etime from dba_hist_sqlstat where ELAPSED_TIME_DELTA / 1000000 >= 1) b, dba_hist_active_sess_history c, dba_users u where a.sql_id = b.sql_id and u.username = 'SYNC_PLUS_1_20190109' and c.user_id = u.user_id and b.sql_id = c.sql_id -- and a.sql_text like '%insert into GK_ZWVCH_HSC_NEW select %' order by SAMPLE_TIME desc, b.etime desc;
四:定位系统里面哪些SQL脚本存在TABLE ACCESS FULL行为
select * from v$sql_plan v where v.operation = 'TABLE ACCESS' and v.OPTIONS = 'FULL' and v.OBJECT_OWNER='SYNC_PLUS_1_20190109';
select s.SQL_TEXT from v$sqlarea s where s.SQL_ID = '4dpd97jh2gzsd' and s.HASH_VALUE = '1613233933' and s.PLAN_HASH_VALUE = '3592287464';
或者
select s.SQL_TEXT from v$sqlarea s where s.ADDRESS = '00000000A65D2318';
Oracle SQL执行缓慢的原因以及解决方案
对Oracle SQL执行缓慢的原因的分析,如果Oracle数据库中的某张表的相关数据已是2亿多时,同时此表也创建了相关的4个独立的相关索引。由于业务方面的需要,每天需分两次向此表中插入300万条记录。
由于数据量大,每次插入耗时3个小时以上,严重影响效率。
因此,修改了系统的算法,将此表中只存储当天新增记录。将此表truncate后,第二天执行对此表的update操作时,非常耗时。表中有2亿多条数据的时候,此Oracle sql语句耗时59秒;表中有300万条数据的时候,此Oracle sql语句耗时几个小时。
咨询DBA后,得出结论,需重建索引。重建后,6秒完成此操作。但第三天问题依然出现。DBA正在查找原因。难道每次truncate表,都需要重建索引?
对于这个问题,DBA也没有给出合理的解释,推测主要原因是Oracle复杂的查询优化算法。
最终,DBA给出的解决方案:
truncate table ....
drop index.....
insert data .....
create index ...
analyze table table_name compute statistics;
重新生成统计数据
调整后,整个操作耗时非常少。
以上的相关内容就是对Oracle SQL执行缓慢的分析的介绍,望你能有所收获。
学问:纸上得来终觉浅,绝知此事要躬行
为事:工欲善其事,必先利其器。
态度:道阻且长,行则将至;行而不辍,未来可期
.....................................................................
------- 桃之夭夭,灼灼其华。之子于归,宜其室家。 ---------------
------- 桃之夭夭,有蕡其实。之子于归,宜其家室。 ---------------
------- 桃之夭夭,其叶蓁蓁。之子于归,宜其家人。 ---------------
=====================================================================
* 博客文章部分截图及内容来自于学习的书本及相应培训课程以及网络其他博客,仅做学习讨论之用,不做商业用途。
* 如有侵权,马上联系我,我立马删除对应链接。 * @author Alan -liu * @Email no008@foxmail.com
转载请标注出处! ✧*꧁一品堂.技术学习笔记꧂*✧. ---> https://www.cnblogs.com/ios9/