1、指標名稱 指標描述 指標范圍 指標單位 1 .關于實例效率(Instance Efficiency Percentages )的性能指標 緩沖區未等待率 (Buffer Nowait %) 指在緩沖區中獲取Buffer的未等該指標的值應接近100%如果該值 % 待比率。 較低，則可能要增大buffer cacheo Redo緩沖區未等待 率 (Redo NoWait %) 指在Redo緩沖區獲取Buffer的未 等待比率。 該指標的值應接近100%如果該值 較低，則有2種可能的情況： 1.online redo log 沒有足夠的空 間； 2.log切換速度較慢。 % 緩沖區命中率 (Buff

2、er Hit %) 指數據塊在數據緩沖區中的命中 率。 該指標的值通常應在 90咐上，否 則，需要調整。如果持續小于90% 可能要加大db_cache_size。但有 時，緩存命中率低并不意味著 cache設置小了，可能是潛在的全 表掃描降低了緩存命中率。 % 內存排序率 (In-memory Sort %) 指排序操作在內存中進行的比率。 當查詢需要排序的時候，數據庫會 話首先選擇在內存中進行排序， 當 內存大小不足的時候，將使用臨時 表空間進行磁盤排序，但磁盤排序 效率和內存排序效率相差好幾個 數量級。 該指標的值應接近100%如果指標 的值較低，則表示出現了大量排序 時的磁盤I/O操作，

3、可考慮加大 sort_area_size 參數的值。 % 共享區命中率 (Library Hit %) 該指標主要代表sql在共享區的 命中率。 該指標的值通常應在 95%上，否 則需要考慮加大共享池(修改 shared_pool_size 參數值)，綁定 變量，修改 cursor_sharing 等參 數。 % 軟解析的百分比 (Soft Parse %) 該指標是指Oracle對sql的解析 過程中，軟解析所占的百分比。 軟 解析(soft parse)是指當 Oracle 接到Client提交的Sql后會首先 在共享池(Shared Pool )里面去 該指標的值通常應在 95咐上，如

4、果低于80%那么就可能sql基本 沒被重用，sql沒有綁定變量，需 要考慮綁定變量。 % 查找是否有之前已經解析好的與 剛接到的這一個Sql完全相同的 Sql。當發現有相同的 Sql就直接 用之前解析好的結果，這就節約了 解析時間以及解析時候消耗的 CPU 資源。 閂命中率 (Latch Hit %) 指獲得Latch的次數與請求Latch 的次數的比率。 該指標的值應接近100%如果低于 99%可以考慮采取一定的方法來降 低對Latch的爭用。 % SQL語句執行與 解析的比率 (Execute to Parse %) 指SQL語句執行與解析的比率。 SQ閔句一次解析后執行的次數越 多，該比

5、率越高，說明SQL語句的 重用性很好。 該指標的值應盡可能到高，如果過 低，可以考慮設置 session_cached_cursors 參數。 % 共享池內存使用率 (Memory Usage %) 該指標是指在采集點時刻，共享池 (share pool )內存被使用的比 例。 這指標的值應保持在 75%90%如 果這個值太低，就浪費內存，如果 太高，會使共享池外部的組件老化， 如果SQL語句被再次執行，則就會 發生硬分析。 % 2 .關于等待事件(Wait events )的性能指標 文件分散讀取 (db file scattered read (cs) 該等待事件通常與全表掃描有關。 因為

6、全表掃描是被放入內存中進 行的進行的，通常情況下它不可能 被放入連續的緩沖區中，所以就散 布在緩沖區的緩存中。 如果這個等待事件比較顯著，可能 說明對于某些全表掃描的表，沒有 創建索引或沒有創建合適的索引。 盡管在特定條件下執行全表掃描可 能比索引掃描更有效，但如果出現 這種等待時，最好檢查一下這些全 表掃描是否必要。 厘秒 文件順序讀取 (db file sequential read (cs) 該等待事件通常與單個數據塊相 關的讀取操作有關。 如果這個等待事件比較顯著，可能 表示在多表連接中，表的連接順序 存在問題，或者可能不合適地使用 了索引。對于大量事務處理、調整 良好的系統，這一數值

7、大多是很正 厘秒 常的，但在某些情況下，它可能暗 示著系統中存在問題。應檢查索引 掃描，以保證每個掃描都是必要的， 并檢查多表連接的連接順序。另外 DB_CACHE_SIZ曲是這些等待出現 頻率的決定因素。 出現這個等待事件的頻度不應大于 1%如果這個等待事件比較顯著， 則需要根據等待事件發生在緩存中 的哪一塊(如字段頭部、回退段頭 部塊、回退段非頭部塊、數據塊、 索引塊等)，采取相應的優化方法。 enqueue是一種保護共享資源的 鎖定機制。該鎖定機制保護共享資 源，如記錄中的數據，以避免兩塵 人在同一時間更新同一數據。 如果enqueue等待事件比較顯著， enqueue包括一個排隊機制，

8、即 則需要根據enqueue等待類型，采 厘秒 FIFO(先進先出)排隊機制。注意： 取相應的優化方法。 Oracle 的 latch 機制不是 FIFO。 Enqueue等待通常指的是 ST enqueue、HWfenqueue、TX4 enqueue 這個等待事件是指當一個會話完 這個等待事件的時間過長，可能是 成一個事務(提交或者回滾數據) 因為commit太頻繁或者lgwr進程緩沖區忙 (buffer busy (cs) 當一個會話想要訪問緩存中的某 個塊，而這個塊正在被其它會話使 用時，將會產生該等待事件。 這時 候，其它會話可能正在從數據文件 向緩存中的這個塊寫入信息， 或正 在對

9、這個塊進行修改。 (enqueue (cs) 閂釋放 (latch free (cs) 日志文件同步 該等待事件意味著進程正在等待 其他進程已持有的latch。 latch是一種低級排隊機制(它們 被準確地稱為相互排斥機制),用 于保護系統全局區域(SGA)中共享 內存結構。latch 就像是一種快速 地被獲取和釋放的內存鎖。latch 用于防止共享內存結構被多個用 戶同時訪問。 對于常見的Latch等待通常的解決 方法： 1) Share pool latch :在 OLTP應 用中應該更多的使用綁定變量以減 少該latch 的等待。 2) Library cache latch :同樣的 需要通過優化sql語句使用綁定變 量減少該latch的等待。 厘秒 和 TM enqueue。 (log file sync 時，必須等待LGWRffi程將會話的 一次寫日志的時間太長(可能是因 (cs) redo信息從日志緩沖區寫到日志 為一