名稱

注釋

CPU used by this session

統計CALL發起開始到結束的CPU時間片的數量，每個計數代表一個CPU周期，也就是10毫秒。不過如果有一個CALL不足一個CPU周期就執行完了，那么統計值的時候START TIME和END TIME是相同的，這樣會計算為0.這個計數基本上可以代表了ORACLE數據庫消耗的CPU資源，不過計算的時候要注意單位是厘秒(cs)，乘以10可以換算成毫秒。比如平均每秒這個指標值是782.1，表示ORACLE消耗了7821毫秒CPU時間，如果這個系統是一個16個CPU的系統，那么這個指標可以說明ORACLE消耗了超過50%的CPU資源。不過由于部分小的CALL可能由于消耗的時間小于10毫秒而沒有計算進去，實際的使用率可能略高于通過這個值計算出來的。一般來說大多數CALL消耗的CPU都會大于10毫秒，所以這個值還是能夠基本反映出ORACLE對CPU資源的開銷

CR blocks created   

CURRENT塊被克隆后用于創建CR（consistent read）塊。被克隆的主要原因是BUFFER被非兼容的模式占用,如果單位時間內CR BLOCKS CREATED值比較高，說明數據庫中對某些數據塊的修改和訪問比較頻繁。如果這些訪問集中在某些熱塊上，那么可能會形成較為嚴重的BUFFER BUSY  WAITS，在RAC環境中，可能還會導致全局熱塊沖突，如果這個指標比較高，那么應該關注BUFFER BUSY  WAITS以及CACHE BUFFER CHAINS閂鎖等

current blocks converted for CR

一個CURRENT的BUFFER在被使用前生成了CR

DBWR buffers scanned

當某些觸發條件發生時，DBWR會在LRU鏈的冷端開始掃描臟塊，組成DBWR BATCH，這個指標統計的是DBWR在LRU上掃描的BUFFER的總數，包含臟塊和干凈的塊，這個指標除以DBWR LRU SCANS這個指標就是每次掃描查找的數據塊的數量。

DBWR checkpoint buffers written

CHECKPOINTS時dbwr寫入的的臟塊數量，如果在單位時間里這個指標比較高，說明系統中數據塊的變更較為頻繁

DBWR free buffers found

DBWR從LRU鏈中掃描BUFFER的時候發現的FREE的BUFFER的數量，除以DBWR  MAKE  FREE REQUESTS就是平均每次DBWR在收到DBWR MAKE FREE消息的時候掃描LRU鏈找到的FREE BUFFER的平均數，這個平均數一般會比較少

DBWR make free requests

DBWR收到的MAKE FREE 消息的數量，如果某個前臺進程在查找一個空閑的BUFFER的時候無法找到的時候或者其他一些觸發條件，會向DBWR發出MAKE FREE消息。如果在單位時間內這個值較高，說明DB CACHE可能存在不足的現象

DBWR summed scan depth

DBWR掃描LRU鏈查找臟塊的時候，查找的BUFFER的數量，這個數越大說明LRU鏈尾部的贓塊數量越少。從Oracle 8i開始，由于LRU鏈的算法發生了變化，因此如果LRU鏈尾部的熱塊比較多，也可能造成這個指標較大

DBWR timeout

DBWR IDLE超過一個特定值，該指標就會加1。如果該值較高，說明BUFFER CACHE中的數據變化較小，需要寫入磁盤的臟塊數量極少

DBWR transaction table writes

DBWR寫入的回滾段頭的數量，這個指標比較高說明有較多熱塊正在被寫入，而大量用戶進程在等待這些塊寫入完成

DBWR undo block writes

DBWR寫入回滾段的數據塊數量

DDL statements parallelized

DDL操作并發執行的計數

DML statements parallelized

DML操作并發執行的計數

background checkpoints completed

后臺進程完成的CHECKPOINTS的數量。

background checkpoints started

后臺進程啟動的CHECKPOINTS數量，可能比上一個狀態的值大一些。如果一個新的CHECKPOINT覆蓋了一個未完成的CHECKPOINT或者CHECKPOINT還正在執行。這個狀態只包含REDO的CHECKPOINT，不包括其他類型的CHECKPOINT，比如OFFLINE文件或者BEGIN BACKUP或者ALTER SYSTEM CHECKPOINT LOCAL命令等

branch node splits

由于插入數據導致的索引枝節點分裂的數量，這個指標較高說明目前存在索引產生了較多的枝節點分裂，可能某張表上的某個索引字段變化十分頻繁，這種頻繁的變化可能對某個應用的性能有較大的影響

BUFFER DEADLOCK

DB CACHE死鎖的數量計數，如果單位時間內該指標較高，可能DB CACHE存在性能問題，或者存在某些BUG

buffer is not pinned count

當訪問一個BUFFER的時候，這個BUFFER已經釋放的數量，只用于Oracle內部調試，并不說明性能問題

buffer is pinned count

當訪問一個BUFFER的時候，該BUFFER已經被PIN住了，如果單位時間內這個指標比較高，說明可能存在熱塊

change write time

當前塊的變化被寫入REDO的時間，單位厘秒（cs,10毫秒），該指標一般不會太大，如果太大需要分析

commit cleanout failures: block lost

在commit的時候準備做塊清理操作的時候，發現不能找到正確的塊的次數計數。

commit cleanout failures: buffer being written

Oracle在COMMIT的時候，去清除BUFFER的時候，發現這個BUFFER 正在被其他會話寫入的計數，如果改指標比較高，可能說明存在熱塊  

commit cleanout failures: callback failure

Oracle在COMMIT的時候，做清除操作時調用CALLBACK函數返回FALSE的計數

commit cleanout failures: cannot pin

Oracle在COMMIT的時候，做清除操作時無法PIN到這個BUFFER的計數,有可能在準備清理的時候該BUFFER又被其他會話PIN住了，如果該指標較高，可以查看DB CACHE相關的情況，包括DB CACHE的大小，命中率，相關閂鎖的命中率，以及熱塊爭用的情況

commit cleanout failures: hot backup in progress       

Oracle在COMMIT的時候，做清除操作時發現正在做熱備份的技術。此時在修改這個BUFFER前，這個BUFFER在被修改前，必須先被寫入LOG BUFFER，以確保數據庫恢復的時候不會產生塊斷裂

commit cleanout failures: write disabled

Oracle在COMMIT的時候，做清除操作時發現數據庫的寫操作暫時被關閉了。這種情況出現的很少

commit cleanouts

在做COMMIT的時候做塊清除工作的計數，無論成功與否計數器都會加1

commit cleanouts successfully completed

COMMIT時成功完成CLEANOUTS的計數。這個指標和上一個指標參考來看，兩個指標應該較為接近（這個指標略低一些），如果這兩個指標相差太大，需要分析DB CACHE是否存在過小的問題，或者應用中是否經常對大表進行大數據量的修改操作

consistent changes

數據塊提交了UNDO信息成為CR塊的計數，這個指標說明了系統中CR塊產生的數量，這個指標越大，越要注意CACHE BUFFER  CHAINS等閂鎖的情況，以及熱塊對系統性能的影響

consistent gets

一致性讀的計數，會話發出的對某個數據塊進行一致性讀的請求。這個指標不能和consistent  changes混淆，一個CR塊產生后，可能被多次consistent gets使用，因此這個指標要比前一個指標大的多。

data blocks consistent reads - undo records applied

從UNDO中讀取數據，形成CR READ。本計數器是記錄從UNDO中獲取UNDO記錄的計數，如果這個指標的值較大，說明對于某些修改較為頻繁的表的查詢和其他操作也很頻繁，有可能存在熱點表和索引

deferred (CURRENT) block cleanout applications

做延遲塊清除操作的計數。在提交的時候該數據塊由于某些原因，某些數據塊無法馬上做塊清除工作，這種情況下，這個數據塊就會做延遲塊清除，延遲塊清除操作可能在下次該數據塊被查詢的時候進行，這種情況也導致了有時候我們會看到我們做SELECT操作的時候也會產生大量的REDO

dirty buffers inspected

當某個會話在LRU鏈的冷端開始查找空閑的數據塊，查到一個臟塊，這個指標就會被增加，如果在單位時間內該指標較大，說明LRU鏈的冷端存在較多的臟塊。這種情況的出現有幾種可能：

l          系統中的贓塊數量十分巨大，而且DBWR的寫入速度不足，從而導致DBWR無法盡快將這些臟塊寫入硬盤

l          部分BUFFER 特別熱，并且被更改的頻率特別高，從而造成LRU鏈的尾端存在大量這樣的塊

l          本系統是一個以DML為主的系統，數據塊的變更十分頻繁

碰到這種情況，可以關注一下dbwr的性能，并且關注一下DB  CACHE的命中率及cache buffer chains等閂鎖的情況

enqueue waits

等待各種鎖的計數

exchange deadlocks

當進行兩個BUFFER交換的時候，發生內部死鎖的計數。索引掃描是導致這種交換的唯一因素，如果改指標較高，可以檢查是否存在十分熱的索引（可以通過BUFFER BUSY  WAITS分析來定位）

free buffer inspected

從LRU隊列的尾部掃描可重用的BUFFER的時候跳過的BUFFER的數量。

global cache freelist waits

當ping一個buffer的時候由于所有的lock element都被使用而引起的等待。

global lock convert time

同步全局鎖的轉換時間（單位是10ms），這個指標較高說明全局鎖沖突較為嚴重，需要檢查cluster  interconnect的性能

hot buffers moved to head of LRU

當一個熱塊到達LRU隊列的尾部的時候，ORACLE自動會把這個塊移動到LRU隊列的頭上，以便于使之能夠繼續被使用。每發生一次這樣的操作，這個計數就加一，值得注意的是，從8i開始，LRU的算法發生了變化，通過引入TCH計數來確定熱塊，而不是通過將熱塊在LRU鏈上移動來保證熱塊不被過早的換出。如果熱塊存在于LRU鏈的尾部，掃描的時候發現了熱塊，會主動跳過，從而保證熱塊不被過早的重用

immediate (CURRENT) block cleanout applications

獲取BUFFER（GET BUFFER）后，立即進行記錄清除操作的計數。

leaf node splits

當INSERT發生后，導致索引葉節點分裂的次數，一般來說對于插入較為頻繁的系統，這個指標一般會比較高，除非出現葉節點熱塊較為嚴重的現象，一般來所不需要特別關注該指標

logons current

當前登錄數據庫的計數

opened cursors current

當前的Open CURSORS的數量

opens of replaced files

文件由于不在打開文件緩沖中而重新打開的計數。每個Oracle會話都有一個文件打開緩沖區，保持部分打開的數據文件的句柄，以避免重復打開文件

parse count (hard)

硬分析的統計值，該值需要和parse count  (total)對比來看硬分析的比例。

parse count (soft)

軟分析的統計值

parse count (total)

發生的parse call的總數

parse time cpu

PARSE消耗的CPU的統計，單位是10毫秒

parse time elapsed

PASE的持續時間，單位是10毫秒。這個指標減去parse time cpu就是parse中等待的時間。如果parse time cpu占整個parse time elapsed的比例較低，說明parse中的等待時間過長，可能共享池存在性能問題，需要進行分析

physical reads direct

直接物理讀的數量。讀的時候不經過BUFFER。一般發生這種操作的情況有：排序操作、并行查詢操作的SLAVE或者預讀

physical writes direct

直接寫的數量，不經過BUFFER，直接寫入。一般發生這種操作的情況有：

l          直接裝載操作，比如CREATE TABLE AS SELECT

l          并行DML操作

l          排序操作中的臨時表空間寫入

l          寫入沒有緩沖的LOB字段

physical writes non checkpoint

非CHECKPOINT引起的物理寫。物理寫的發生情況包括CHECKPOINT或者無足夠的空閑BUFFER可用，或者DBWR超時等，一般情況下這個指標會超過physical  writes的一半以上，除非是CHECKPOINT十分頻繁的系統。如果該指標占physical writes的比重比較少，應該進行分析

pinned buffers inspected

當一個用戶進程掃描REPLACEMENT列表，尋找一個可重用的BUFFER的時候，發現一個冷塊被PIN了或者有一個PIN請求的等待事件。這種情況很少發生，因為冷塊很少會被PIN。如果平均每秒該指標值較大，需要進行分析

queries parallelized

并行查詢執行的次數統計

recursive cpu usage

非用戶調用的CUP時間

recovery array read time

做recovery的時候產生的IO消耗的時間

recovery array reads

做RECOVERY的時候產生的IO的次數

recovery blocks read

做recovery的時候讀取的數據塊的數量

redo entries

當一個redo信息被拷貝到log buffer的時候這個計數增加

redo entries linearized

小于等于REDO_ENTRY_PREBUILD_THRESHOLD的redo entries的數量，這些redo entries可以并發生成，不需要受閂鎖的限制，但是會增加CPU的消耗，在多CPU的系統中，這個值會比較高

redo buffer allocation retries

當申請REDO BUFFER的時候，重試的次數。一般來說重試發生的原因是REDO WRITER還沒完成或者日志切換正在進行。如果該指標較高，說明REDO  LOG產生的頻率很高，LGWR無法及時刷新LOG  BUFFER，可以考慮加大LOG BUFFER的大小。LOG  BUFFER一般可以為幾兆到幾十兆，不過由于很多數據庫版本中存在BUG，因此不建議將LOG BUFFER設置的過大，一般來說30-40M對于絕大多數系統來說都是足夠的了

如果是由于等待日志切換，那么可能是存在的問題包括：

l           REDO  LOG文件過小

l           REDO  LOG IO性能不佳

l          數據文件的IO性能不佳導致DBWR寫入較慢

l          DBWR的數量太少，導致DBWR的寫入性能不足

redo log space requests

當前ACTIVE的日志文件滿了，Oracle必須等待日志切換完成后才能分配REDO LOG磁盤空間，就會產生這個等待。如果SGA的大小和日志文件的大小不匹配，并且系統中的COMMIT十分頻繁。當日志切換的時，DBWR需要把已經提交的臟塊也寫入磁盤，在這些臟塊寫入磁盤完成前，日志切換不能完成。在這種情況下，這個統計值會比較高。

如果這個統計值較高，建議檢查以下幾個方面：

l           REDO  LOG文件的IO性能是否存在問題，如果log file parallel write的平均耗時較大，說明REDO LOG的寫性能出現了問題，建議將REDO LOG放到性能更好的磁盤上，或者將REDO LOG文件獨立存放，避免IO沖突

l           LOG  BUFFER的大小是否過小

l          應用軟件中的提交可能過于頻繁，建議采用批量提交的方式，而不要每條記錄都提交

redo log space wait time

Redo log space requests的等待時間（單位厘秒），這個指標需要和上一個指標一起看

redo size

生成的所有redo的大小，單位是字節

redo synch time

Redo synch調用消耗的時間，單位是10毫秒（厘秒）

redo sync writes

一般來說redo信息生成后，會被拷貝到log buffer中，并不需要馬上被寫入redo log文件，lgwr會周期性將這些數據寫入redo log文件。不過如果事務提交了，那么這些redo 信息必須馬上被寫入REDO LOG文件，這個時侯redo sync  writes計數器會增加

redo wastage

在把LOG BUFFER數據寫入REDO LOG文件的時候計算的LOG BUFFER空閑的空間

redo writer latching time

LGWR獲得每個COPY LATCH的時間（單位厘秒），如果該指標存在問題，需要檢查REDO LOG文件的IO性能以及LOG BUFFER的大小是否足夠，這個指標只有在LOG_SIMULTANEOUS_COPIES  > 0的時候才有意義

redo writes

LGWR將LOG BUFFER寫入REDO LOG文件的計數

remote instance undo block writes

如果遠程的實例需要讀取某個UNDO BLOCK，需要這個實例先將這個“臟的”UNDO BLOCK回寫，這個計數器就會增加

remote instance undo header writes

和上一個指標類似，只是寫入的是UNDO HEADER

remote instance undo requests

由于要做CR從遠程的實例中請求UNDO的數量，如果這個指標較大，說明RAC中的某些數據塊經常在實例間進行共享，某個實例修改過的數據也正在被其他實例使用，這種情況下需要留意CLUSTER  INTERCONNECT的性能

rollback changes - undo records applied

當用戶需要ROLLBACK的時候，提交的UNDO記錄的數量，當事務需要回滾時，需要從UNDO中取出數據，并且提交到已被修改過的數據上，這個計數和系統中ROLLBACK的數量以及每次ROLLBACK的記錄的數量有關

rollbacks only - consistent read gets

當用戶需要進行CR READ的時候，提交的UNDO記錄的數量，此時并沒有BUFFER CLEAR操作發生。當進行一致性讀的時候，也需要從UNDO中取出相關的數據，然后生成一個CR BLOCK，把這些數據提交到CR BLOCK上，這個時候這個指標就會增加。

rows fetched via callback

CALLBACK函數返回的記錄數。該統計量僅僅用于內部DEBUG

session cursor cache count

會話CURSOR緩沖區的計數，只有當session_cached_cursors大于0的時候才有意義，如果這個值已經很接近甚至到達了參數中session_cached_cursors的值，那么說明這個參數可能需要加大

session cursor cache hits

這個指標也只有當session_cached_cursors大于0才有意義，會話直接從SESSION CURSOR  CACHE中找到某個SQL的計數，這個值可以看出CURSOR CACHE產生的作用，可以將這個值和parse  count(total)進行比較

sorts (disk)

磁盤排序的數量，如果平均每秒該指標的值較高，需要檢查一下PGA_AGGREGATE_TARGET參數是否設置過低，或者*_AREA_SIZE是否設置過小（PGA手工管理模式）。檢查該指標的時候，同時應該查看一下TEMP表空間的相關文件的IO性能，如果TEMP表空間文件的IO性能不足，需要加大PGA的配置來減少硬盤排序

sorts (memory)

內存排序的統計

summed dirty queue length

每次寫請求發生的時候，臟數據塊鏈表的長度總和除以寫請求的次數，這個統計值越大，說明系統中需要回寫的臟塊較多

switch current to new buffer

將當前BUFFER移動到另外一個新的BUFFER，原有的BUFFER成為一個CR BLOCK，這種操作的次數

table fetch by rowid

通過ROWID訪問表，這種操作一般是通過索引訪問，還有一種情況是SQL直接通過rowid去訪問某個表。

table fetch continued row

如果訪問某一行數據，需要訪問多個BLOCK，這個計數器就會增加。產生這種情況的一個很主要的原因是行鏈和行遷移，如果某個表的PCT_FREE設置不合理，可能導致UPDATE的時候產生行遷移，這樣就會增加這個計數

第二種可能性是某一行計數的長度相對BLOCK SIZE來說過大，這樣一行數據被存儲在多個BLOCK中的機會就較大，這種情況下應該將這種表存放于更大的BLOCK SIZE的表空間中

還有一種可能性就是系統中訪問帶LOB字段的訪問較多，因為大的LOB字段一般來說采用獨立的SEGMENT存放，因此訪問這種數據也會增加這個統計值

total file opens

被INSTANCE打開的文件的數量（包含數據文件、控制文件、REDO  LOG等）

transaction rollbacks

被成功回退的事務的總數

write clones created in background

如果當前的BUFFER正在被寫入，那么后臺進程或者前臺進程克隆一個新的BUFFER，使原來BUFFER的寫入可以繼續進行

enqueue conversions

表或者行鎖的轉換統計

enqueue deadlocks

死鎖統計

enqueue releases

鎖釋放統計

enqueue requests   

鎖申請統計

enqueue timeouts

鎖申請超時統計

enqueue waits

鎖等待統計