Oracle AWR性能優化一例

有一個批處理程序運行超過24小時仍然不能完成，采集了程序運行期間的AWR報告如下。

由上可以看到，該系統為AIX的單實例數據庫，采樣時長1319.96 分鐘，DB time 1532.15分鐘。

看一下TOP等待事件:

可以看到有非常高的DB file scattered read等待事件，該等待事件表示將大量的數據塊讀入到不連續的內存區域，往往預示著大的全表掃描。
在程序運行期間，查看ASH動態視圖v$active_session_history，同樣可以發現發生著大量的DB file scattered read 等待事件，從該視圖的執行計劃列可以看到正在發生著 Table Full Scan.

接著我們看TOP SQL部分:

我們看到 SQL ID 為2yhcj6jcbtvac的SQL語句消耗大量的資源， 該SQL語句如下:
SELECT MATCH_CLIENT_ID , MATCH_CLIENT_ROLE , DECODE(MATCH_SYS_CODE, 'HKP', 1, 'UVP', 2, 'CAS', 3, 'NB', 4, 'GP', 5, 'GLH', 6, 'GI', 7, 'MFD', 8, 'CRC', 9, 10) AS MATCH_POL_ORDER , MATCH_SYS_CODE , MATCH_LOB , MATCH_CONTRACT_NO , MATCH_CERTIFICATE_NO FROM POSSIBLE_CUST_REPORT_SCB WHERE BATCH_DATE = :B3 AND CLIENT_ID = :B2 AND MATCH_CLIENT_ID = :B1

可以看到該語句為一個單表查詢，從v$active_session_history也可以看到就是該語句發生著大量的DB file scattered read, 查看該表的定義，沒有索引，所以初次可以判定，以上的SQL語句被多次執行，并且因為沒有索引所以在產生全表掃描。

查看AWR的segment部分，更確認了這一點:

該表段上產生最大的邏輯讀、物理讀和非優化的讀取。

所以， 現在完全可以確定，該表上大量的全表掃描是最主要的性能問題，所以需要在該表上添加索引。

在該表上創建索引:
CREATE INDEX idx1_POSSIBLE_CUST_REPORT_SCB ON POSSIBLE_CUST_REPORT_SCB(BATCH_DATE,CLIENT_ID,MATCH_CLIENT_ID);

所以創建完成后，立刻再次查看v$active_session_history，可以看到執行路勁改走索引。
最終結果確認，該批處理程序性能提升3倍以上。