在生產環境中，如果系統已經穩定，調優的空間就會越來越小，但是不代表沒有調優的餘地，可能工作的重心就會更加求穩，sql調優就是一項不間斷的工作，很多工作還是需要前瞻的，如果等到問題嚴重的時候再緊急處理，提前的分析這些潛在問題就會讓你不會總是心跳加快，兩手冒汗。 dba_hist_sqlstat是一個寶庫，很多的sql執行統計資訊都會在其中，可以基於這個資料字典分析很多的特性，比如檢視某條sql語句的效能歷史，分析執行計劃是否穩定等等，這些功能在分析sql語句的時候是相當實用的，畢竟一個awr報告中的sql問題可能只是一個表象，如果結合歷史來看就會分析出更多的因素來。 這個指令碼在<<Oracle SQL高階程式設計>>中提到，而且可以通過網站找到相關的指令碼內容，如果明白了思路，大家想自己定製一下也不錯。 大多數的指令碼可以通過連結找到http://kerryosborne.oracle-guy.com/2009/06/oracle-11g-adaptive-cursor-sharing-acs/

分析某一條sql語句的效能歷史指令碼

set lines 155
col execs for 999,999,999
col avg_etime for 999,999.999
col avg_lio for 999,999,999.9
col begin_interval_time for a30
col node for 99999
break on plan_hash_value on startup_time skip 1
select ss.snap_id, ss.instance_number node, begin_interval_time, sql_id, plan_hash_value,
nvl(executions_delta,0) execs,
(elapsed_time_delta/decode(nvl(executions_delta,0),0,1,executions_delta))/1000000 avg_etime,
(buffer_gets_delta/decode(nvl(buffer_gets_delta,0),0,1,executions_delta)) avg_lio
from DBA_HIST_SQLSTAT S, DBA_HIST_SNAPSHOT SS
where sql_id = nvl('&sql_id','4dqs2k5tynk61')
and ss.snap_id = S.snap_id
and ss.instance_number = S.instance_number
and executions_delta > 0
order by 1, 2, 3
/
 

指令碼執行情況如下：

   SNAP_ID   NODE BEGIN_INTERVAL_TIME            SQL_ID        PLAN_HASH_VALUE        EXECS    AVG_ETIME        AVG_LIO
---------- ------ ------------------------------ ------------- --------------- ------------ ------------ --------------
     38878      1 31-MAR-15 05.20.06.216 PM      0xtpfz5pj4prb      1880269335          104        5.702      327,280.7
     38879      1 31-MAR-15 05.30.06.754 PM      0xtpfz5pj4prb                          119        4.926      326,385.0
     38880      1 31-MAR-15 05.40.07.622 PM      0xtpfz5pj4prb                          125        4.713      328,324.9
     38881      1 31-MAR-15 05.50.08.418 PM      0xtpfz5pj4prb                            6        6.461      361,164.7
     38884      1 31-MAR-15 06.20.09.984 PM      0xtpfz5pj4prb                           21        5.324      321,935.6
     38885      1 31-MAR-15 06.30.10.720 PM      0xtpfz5pj4prb                          107        5.539      325,886.4
     38886      1 31-MAR-15 06.40.11.283 PM      0xtpfz5pj4prb                           64        5.432      329,591.9
     38887      1 31-MAR-15 06.50.11.900 PM      0xtpfz5pj4prb                          110        5.397      326,757.1
     38888      1 31-MAR-15 07.00.12.457 PM      0xtpfz5pj4prb                          103        5.792      329,023.0
     38889      1 31-MAR-15 07.10.13.355 PM      0xtpfz5pj4prb                          126        4.682      328,220.6
     38890      1 31-MAR-15 07.20.13.848 PM      0xtpfz5pj4prb                          128        4.601      326,872.7
     38891      1 31-MAR-15 07.30.14.326 PM      0xtpfz5pj4prb      1880269335          131        4.508      328,507.7
     38892      1 31-MAR-15 07.40.14.905 PM      0xtpfz5pj4prb                          129        4.571      326,210.3
     38893      1 31-MAR-15 07.50.15.372 PM      0xtpfz5pj4prb                          132        4.468      327,796.7
     38894      1 31-MAR-15 08.00.15.889 PM      0xtpfz5pj4prb                          113        5.176      328,226.4
     38895      1 31-MAR-15 08.10.16.442 PM      0xtpfz5pj4prb                           63        5.194      332,234.3
     38897      1 31-MAR-15 08.30.17.385 PM      0xtpfz5pj4prb                           37        6.175      326,039.1
     38898      1 31-MAR-15 08.40.17.922 PM      0xtpfz5pj4prb                           76        7.755      327,436.6
     38899      1 31-MAR-15 08.50.18.469 PM      0xtpfz5pj4prb                          113        5.245      327,478.5
     38900      1 31-MAR-15 09.00.18.950 PM      0xtpfz5pj4prb                          127        4.614      326,215.6
     38901      1 31-MAR-15 09.10.19.458 PM      0xtpfz5pj4prb                           74        4.316      332,214.9
 

如果某些指標突然發生了重大的變化，可以通過效能歷史很清晰的看到，對於plan_hash_value做了斷句處理，如果發生了執行計劃的改變，就會很清楚什麼時間點有了變動，哪些方面的變化等等。