注:本文來源 於《oracle查看執行最慢與查詢次數最多的sql語句》html
在ORACLE數據庫應用調優中,一個SQL的執行次數/頻率也是經常須要關注的,由於某個SQL執行太頻繁,要麼是因爲應用設計有缺陷,須要在業務邏輯上作出優化處理,要麼是業務特殊性所致使。若是執行頻繁的SQL,每每容易遭遇一些併發性的問題。 那麼如何查看ORACLE數據庫某個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;
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;
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;
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';
或者sql
select s.SQL_TEXT from v$sqlarea s where s.ADDRESS = '00000000A65D2318';數據庫
對Oracle SQL執行緩慢的緣由的分析,若是Oracle數據庫中的某張表的相關數據已經是2億多時,同時此表也建立了相關的4個獨立的相關索引。因爲業務方面的須要,天天需分兩次向此表中插入300萬條記錄。併發
因爲數據量大,每次插入耗時3個小時以上,嚴重影響效率。oracle
所以,修改了系統的算法,將此表中只存儲當天新增記錄。將此表truncate後,次日執行對此表的update操做時,很是耗時。表中有2億多條數據的時候,此Oracle sql語句耗時59秒;表中有300萬條數據的時候,此Oracle sql語句耗時幾個小時。優化
諮詢DBA後,得出結論,需重建索引。重建後,6秒完成此操做。但第三天問題依然出現。DBA正在查找緣由。難道每次truncate表,都須要重建索引?spa
對於這個問題,DBA也沒有給出合理的解釋,推測主要緣由是Oracle複雜的查詢優化算法。設計
最終,DBA給出的解決方案:code
truncate table ....
drop index.....
insert data .....
create index ...
analyze table table_name compute statistics;
從新生成統計數據
調整後,整個操做耗時很是少。
以上的相關內容就是對Oracle SQL執行緩慢的分析的介紹,望你能有所收穫。