注：以下指標取自Oracle的性能分析工具Statspack所提供的性能分析指標。
1．關於實例效率（Instance Efficiency Percentages）的性能指標
@緩衝區未等待率(Buffer Nowait %)
指在緩衝區中獲取Buffer的未等待比率。
該指標的值應接近100%，如果該值較低，則可能要增大buffer cache。
@Redo緩衝區未等待率(Redo NoWait %)
指在Redo緩衝區獲取Buffer的未等待比率。
該指標的值應接近100%，如果該值較低，則有2種可能的情況：
1）online redo log沒有足夠的空間；
2）log切換速度較慢。
*適當增大redo log文件大小
@緩衝區命中率(Buffer Hit %)
指數據塊在數據緩衝區中的命中率。
該指標的值通常應在90%以上，否則，需要調整。如果持續小於90%，可能要加大db_cache_size。但有時，緩存命中率低並不意味着cache設置小了，可能是潛在的全表掃描降低了緩存命中率。
*關注sql top5
@內存排序率(In-memory Sort %)
指排序操作在內存中進行的比率。當查詢需要排序的時候，數據庫會話首先選擇在內存中進行排序，當內存大小不足的時候，將使用臨時表空間進行磁盤排序，但磁盤排序效率和內存排序效率相差好幾個數量級。
該指標的值應接近100%，如果指標的值較低，則表示出現了大量排序時的磁盤I/O操作，可考慮加大sort_area_size參數的值。
@共享區命中率(Library Hit %)
該指標主要代表sql在共享區的命中率。
該指標的值通常應在95%以上，否則需要考慮加大共享池（修改shared_pool_size參數值），綁定變量，修改cursor_sharing等參數。
@軟解析的百分比(Soft Parse %)
該指標是指Oracle對sql的解析過程中，軟解析所佔的百分比。軟解析（soft parse）是指當Oracle接到Client提交的Sql後會首先在共享池（Shared Pool）裏面去查找是否有之前已經解析好的與剛接到的這一個Sql完全相同的Sql。當發現有相同的Sql就直接用之前解析好的結果，這就節約瞭解析時間以及解析時候消耗的CPU資源。
該指標的值通常應在95%以上，如果低於80%，那麼就可能sql基本沒被重用，sql沒有綁定變量，需要考慮綁定變量。
@閂命中率(Latch Hit %)
指獲得Latch的次數與請求Latch的次數的比率。
該指標的值應接近100%，如果低於99%，可以考慮採取一定的方法來降低對Latch的爭用。
@SQL語句執行與解析的比率(Execute to Parse %)
指SQL語句執行與解析的比率。SQL語句一次解析後執行的次數越多，該比率越高，說明SQL語句的重用性很好。
該指標的值應儘可能到高，如果過低，可以考慮設置session_cached_cursors參數。
@共享池內存使用率(Memory Usage %)
該指標是指在採集點時刻，共享池（share pool）內存被使用的比例。
這指標的值應保持在75%~90%,如果這個值太低，就浪費內存，如果太高，會使共享池外部的組件老化，如果SQL語句被再次執行，則就會發生硬分析。
2．關於等待事件（Wait events）的性能指標
@文件分散讀取(db file scattered read (cs))
該等待事件通常與全表掃描有關。因爲全表掃描是被放入內存中進行的進行的，通常情況下它不可能被放入連續的緩衝區中，所以就散佈在緩衝區的緩存中。
如果這個等待事件比較顯著，可能說明對於某些全表掃描的表，沒有創建索引或沒有創建合適的索引。儘管在特定條件下執行全表掃描可能比索引掃描更有效，但如果出現這種等待時，最好檢查一下這些全表掃描是否必要。
*查找sql top5
@文件順序讀取(db file sequential read (cs))
該等待事件通常與單個數據塊相關的讀取操作有關。
如果這個等待事件比較顯著，可能表示在多表連接中，表的連接順序存在問題，或者可能不合適地使用了索引。對於大量事務處理、調整良好的系統，這一數值大多是很正常的，但在某些情況下，它可能暗示着系統中存在問題。應檢查索引掃描，以保證每個掃描都是必要的，並檢查多表連接的連接順序。另外DB_CACHE_SIZE 也是這些等待出現頻率的決定因素。
*定時蒐集索引碎片
@緩衝區忙(buffer busy (cs))
當一個會話想要訪問緩存中的某個塊，而這個塊正在被其它會話使用時，將會產生該等待事件。這時候，其它會話可能正在從數據文件向緩存中的這個塊寫入信息，或正在對這個塊進行修改。
出現這個等待事件的頻度不應大於1%。如果這個等待事件比較顯著，則需要根據等待事件發生在緩存中的哪一塊（如字段頭部、回退段頭部塊、回退段非頭部塊、數據塊、索引塊等），採取相應的優化方法。
@(enqueue (cs))
enqueue 是一種保護共享資源的鎖定機制。該鎖定機制保護共享資源，如記錄中的數據，以避免兩個人在同一時間更新同一數據。enqueue 包括一個排隊機制，即FIFO(先進先出)排隊機制。注意：Oracle 的latch 機制不是FIFO。Enqueue 等待通常指的是ST enqueue、HW enqueue、TX4 enqueue 和TM enqueue。
如果enqueue等待事件比較顯著，則需要根據enqueue等待類型，採取相應的優化方法。
@閂釋放(latch free (cs))
該等待事件意味着進程正在等待其他進程已持有的latch。
latch是一種低級排隊機制(它們被準確地稱爲相互排斥機制),用於保護系統全局區域(SGA)中共享內存結構。latch 就像是一種快速地被獲取和釋放的內存鎖。latch 用於防止共享內存結構被多個用戶同時訪問。
對於常見的Latch等待通常的解決方法：
1）Share pool latch：在OLTP應用中應該更多的使用綁定變量以減少該latch的等待。
2）Library cache latch：同樣的需要通過優化sql語句使用綁定變量減少該latch的等待。
*可能與業務層實現有關
@日誌文件同步(log file sync (cs))
這個等待事件是指當一個會話完成一個事務（提交或者回滾數據）時，必須等待LGWR進程將會話的redo信息從日誌緩衝區寫到日誌文件後，才能繼續執行下去。
這個等待事件的時間過長，可能是因爲commit太頻繁或者lgwr進程一次寫日誌的時間太長（可能是因爲一次log io size太大），可調整 _log_io_size，結合log_buffer,使得 (_log_io_size*db_block_size)*n = log_buffer，這樣可避免和增大log_buffer引起衝突，或者可以將日誌文件存放在高速磁盤上。
*也有可能是redo log太小，頻繁日誌切換導致重做日誌輸出受阻。