statspack report分析(二)

Parse CPU to Parse Elapsd %:解析實際運作事件/(解析實際運作時間+解析中等待資源時間)

越高越好

% Non-Parse CPU:查詢實際運作時間/(查詢實際運作時間+sql解析時間)，太低表示解析消耗時間過多。100*（parse time cpu / parse time elapsed）= Parse CPU to Parse Elapsd %

如果一個經常通路的列上的索引被删除，可能會造成buffer hit 顯著的下降

如果增加了索引，但是他影響了ORACLE正确的選擇表連接配接時的驅動順序，那麼可能會導緻buffer hit 顯 著增高

如果你的命中率變化幅度很大，說明你要改變SQL模式

  Quote:

Shared Pool Statistics        Begin   End

                               ------  ------

             Memory Usage %:   33.79   57.02

    % SQL with executions>1:   62.62   73.24

  % Memory for SQL w/exec>1:   64.55   78.72

Shared Pool相關統計資料

Memory Usage %:共享池記憶體使用率，應該穩定在70%-90%間，太小浪費記憶體，太大則記憶體不足。

% SQL with executions>1:執行次數大于1的sql比率，若太小可能是沒有使用bind variables。

% Memory for SQL w/exec>1:也即是memory for sql with execution > 1:執行次數大于1的sql

消耗記憶體/所有sql消耗的記憶體

4、首要等待事件

常見等待事件說明:

oracle等待事件是衡量oracle運作狀況的重要依據及訓示，主要有空閑等待事件和非空閑等待事件,  TIMED_STATISTICS = TRUE 那麼等待事件按等待的時間排序= FALSE那麼事件按等待的數量排序.運作statspack期間必須session上設定TIMED_STATISTICS = TRUE.

空閑等待事件是oracle正等待某種工作，在診斷和優化資料庫時候，不用過多注意這部分事件，

非空閑等待事件專門針對oracle的活動，指資料庫任務或應用程式運作過程中發生的等待，這些等待事件是我們在調整資料庫應該關注的。

比較影響性能常見等待事件

db file scattered read

    該事件通常與全表掃描有關。因為全表掃描是被放入記憶體中進行的進行的，

通常情況下它不可能被放入連續的緩沖區中，是以就散布在緩沖區的緩存中。該指數的數量過大說明缺少索引或者限制了索引的使用(也可以調整optimizer_index_cost_adj) 。這種情況也可能是正常的，因為執行全表掃描可能比索引掃描效率更高。當系統存在這些等待時，需要通過檢查來确定全表掃描是否必需的來調整。如果經常必須進行全表掃描,而且表比較小, 把該表存人keep池.如果是大表經常進行全表掃描,那麼應該是olap系統,而不是oltp的.

db file sequential read

   該事件說明在單個資料塊上大量等待，該值過高通常是由于表間連接配接順序很糟糕，或者使用了非選擇性索引。通過将這種等待與statspack報表中已知其它問題聯系起來(如效率不高的sql),通過檢查確定索引掃描是必須的，并確定多表連接配接的連接配接順序來調整, DB_CACHE_SIZE可以決定該事件出現的頻率

buffer busy wait

    當緩沖區以一種非共享方式或者如正在被讀入到緩沖時,就會出現該等待.該值不應該大于1%,确認是不是由于熱點塊造成(如果是可以用反轉索引,或者用更小塊大小)

latch free

   常跟應用沒有很好的應用綁定有關. 闩鎖是底層的隊列機制(更加準确的名稱應該是互斥機制)，用于保護系統全局區(SGA)共享記憶體結構闩鎖用于防止對記憶體結構的并行通路。如果闩鎖不可用，就會記錄一次闩鎖丢失。絕大多數得闩鎖問題都與使用綁定變量失敗(庫緩存闩鎖)、生成重作問題(重執行配置設定闩鎖)、緩存的争用問題(緩存LRU鍊) 以及緩存的熱資料寬塊(緩存鍊)有關。當闩鎖丢失率高于0.5%時，需要調整這個問題。

log buffer space

    日志緩沖區寫的速度快于LGWR寫REDOFILE的速度,可以增大日志檔案大小，增加日志緩沖區的大小，或者使用更快的磁盤來寫資料。

logfile switch

    通常是因為歸檔速度不夠快,需要增大重做日志

log file sync

    當一個使用者送出或復原資料時，LGWR将會話得重做操作從日志緩沖區填充到日志檔案中，使用者的程序必須等待這個填充工作完成。在每次送出時都出現，如果這個等待事件影響到資料庫性能，那麼就需要修改應用程式的送出頻率, 為減少這個等待事件，須一次送出更多記錄，或者将重做日志REDO LOG 檔案訪在不同的實體磁盤上。

Enqueue   最有可能是多個使用者同時修改同一個塊,如果沒有空閑的ITL空間,就會出現資料庫塊級鎖.

TOP SQL

調整首要的25個緩沖區讀操作和首要的25個磁盤讀操作做的查詢,将可對系統性能産生5%到5000%的增益.  

Instance Activity Stats for DB: CRMTEMP  Instance: crmtemp  Snaps: 3 -11           

Statistic                      Total     per Second    per Trans                         

--------------------------------- ------------------ -------------- ------------    

CPU used by this session  291,318           98.1         13.0    

CPU used when call started  291,318       98.1         13.0    

CR blocks created              1,784            0.6           0.1    

Cached Commit SCN referenced 0            0.0           0.0    

Commit SCN cached                 0            0.0           0.0    

DBWR buffers scanned     985,112          331.6   44.0                                                 

DBWR checkpoint buffers written    948  0.3          0.0                                                    

DBWR checkpoints                  0            0.0          0.0                                                    

dirty buffers inspected             483        0.2            0.0    --髒緩沖的個數

free buffer inspected            8,154        2.7            0.4    --如果數量很大,說明緩沖區過小

sorts (disk)                            0            0.0            0.0    --不應當大于1-5%

sorts (memory)                  15,365       5.2          0.7                               

sorts (rows)                  1,445,018      823.0        109.2                              

summed dirty queue length  24,667     8.3          1.1