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