名稱

注釋

CPU used by this session

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

CR blocks created   

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

current blocks converted for CR

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

DBWR buffers scanned

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

DBWR checkpoint buffers written

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

DBWR free buffers found

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

DBWR make free requests

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

DBWR summed scan depth

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

DBWR timeout

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

DBWR transaction table writes

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

DBWR undo block writes

DBWR寫入回滾段的數(shù)據(jù)塊數(shù)量

DDL statements parallelized

DDL操作并發(fā)執(zhí)行的計數(shù)

DML statements parallelized

DML操作并發(fā)執(zhí)行的計數(shù)

background checkpoints completed

后臺進程完成的CHECKPOINTS的數(shù)量。

background checkpoints started

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

branch node splits

由于插入數(shù)據(jù)導(dǎo)致的索引枝節(jié)點分裂的數(shù)量，這個指標較高說明目前存在索引產(chǎn)生了較多的枝節(jié)點分裂，可能某張表上的某個索引字段變化十分頻繁，這種頻繁的變化可能對某個應(yīng)用的性能有較大的影響

BUFFER DEADLOCK

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

buffer is not pinned count

當訪問一個BUFFER的時候，這個BUFFER已經(jīng)釋放的數(shù)量，只用于Oracle內(nèi)部調(diào)試，并不說明性能問題

buffer is pinned count

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

change write time

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

commit cleanout failures: block lost

在commit的時候準備做塊清理操作的時候，發(fā)現(xiàn)不能找到正確的塊的次數(shù)計數(shù)。

commit cleanout failures: buffer being written

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

commit cleanout failures: callback failure

Oracle在COMMIT的時候，做清除操作時調(diào)用CALLBACK函數(shù)返回FALSE的計數(shù)

commit cleanout failures: cannot pin

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

commit cleanout failures: hot backup in progress       

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

commit cleanout failures: write disabled

Oracle在COMMIT的時候，做清除操作時發(fā)現(xiàn)數(shù)據(jù)庫的寫操作暫時被關(guān)閉了。這種情況出現(xiàn)的很少

commit cleanouts

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

commit cleanouts successfully completed

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

consistent changes

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

consistent gets

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

data blocks consistent reads - undo records applied

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

deferred (CURRENT) block cleanout applications

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

dirty buffers inspected

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

l          系統(tǒng)中的贓塊數(shù)量十分巨大，而且DBWR的寫入速度不足，從而導(dǎo)致DBWR無法盡快將這些臟塊寫入硬盤

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

l          本系統(tǒng)是一個以DML為主的系統(tǒng)，數(shù)據(jù)塊的變更十分頻繁

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

enqueue waits

等待各種鎖的計數(shù)

exchange deadlocks

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

free buffer inspected

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

global cache freelist waits

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

global lock convert time

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

hot buffers moved to head of LRU

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

immediate (CURRENT) block cleanout applications

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

leaf node splits

當INSERT發(fā)生后，導(dǎo)致索引葉節(jié)點分裂的次數(shù)，一般來說對于插入較為頻繁的系統(tǒng)，這個指標一般會比較高，除非出現(xiàn)葉節(jié)點熱塊較為嚴重的現(xiàn)象，一般來所不需要特別關(guān)注該指標

logons current

當前登錄數(shù)據(jù)庫的計數(shù)

opened cursors current

當前的Open CURSORS的數(shù)量

opens of replaced files

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

parse count (hard)

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

parse count (soft)

軟分析的統(tǒng)計值

parse count (total)

發(fā)生的parse call的總數(shù)

parse time cpu

PARSE消耗的CPU的統(tǒng)計，單位是10毫秒

parse time elapsed

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

physical reads direct

直接物理讀的數(shù)量。讀的時候不經(jīng)過BUFFER。一般發(fā)生這種操作的情況有：排序操作、并行查詢操作的SLAVE或者預(yù)讀

physical writes direct

直接寫的數(shù)量，不經(jīng)過BUFFER，直接寫入。一般發(fā)生這種操作的情況有：

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

l          并行DML操作

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

l          寫入沒有緩沖的LOB字段

physical writes non checkpoint

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

pinned buffers inspected

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

queries parallelized

并行查詢執(zhí)行的次數(shù)統(tǒng)計

recursive cpu usage

非用戶調(diào)用的CUP時間

recovery array read time

做recovery的時候產(chǎn)生的IO消耗的時間

recovery array reads

做RECOVERY的時候產(chǎn)生的IO的次數(shù)

recovery blocks read

做recovery的時候讀取的數(shù)據(jù)塊的數(shù)量

redo entries

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

redo entries linearized

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

redo buffer allocation retries

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

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

l           REDO  LOG文件過小

l           REDO  LOG IO性能不佳

l          數(shù)據(jù)文件的IO性能不佳導(dǎo)致DBWR寫入較慢

l          DBWR的數(shù)量太少，導(dǎo)致DBWR的寫入性能不足

redo log space requests

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

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

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

l           LOG  BUFFER的大小是否過小

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

redo log space wait time

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

redo size

生成的所有redo的大小，單位是字節(jié)

redo synch time

Redo synch調(diào)用消耗的時間，單位是10毫秒（厘秒）

redo sync writes

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

redo wastage

在把LOG BUFFER數(shù)據(jù)寫入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文件的計數(shù)

remote instance undo block writes

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

remote instance undo header writes

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

remote instance undo requests

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

rollback changes - undo records applied

當用戶需要ROLLBACK的時候，提交的UNDO記錄的數(shù)量，當事務(wù)需要回滾時，需要從UNDO中取出數(shù)據(jù)，并且提交到已被修改過的數(shù)據(jù)上，這個計數(shù)和系統(tǒng)中ROLLBACK的數(shù)量以及每次ROLLBACK的記錄的數(shù)量有關(guān)

rollbacks only - consistent read gets

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

rows fetched via callback

CALLBACK函數(shù)返回的記錄數(shù)。該統(tǒng)計量僅僅用于內(nèi)部DEBUG

session cursor cache count

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

session cursor cache hits

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

sorts (disk)

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

sorts (memory)

內(nèi)存排序的統(tǒng)計

summed dirty queue length

每次寫請求發(fā)生的時候，臟數(shù)據(jù)塊鏈表的長度總和除以寫請求的次數(shù)，這個統(tǒng)計值越大，說明系統(tǒng)中需要回寫的臟塊較多

switch current to new buffer

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

table fetch by rowid

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

table fetch continued row

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

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

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

total file opens

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

transaction rollbacks

被成功回退的事務(wù)的總數(shù)

write clones created in background

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

enqueue conversions

表或者行鎖的轉(zhuǎn)換統(tǒng)計

enqueue deadlocks

死鎖統(tǒng)計

enqueue releases

鎖釋放統(tǒng)計

enqueue requests   

鎖申請統(tǒng)計

enqueue timeouts

鎖申請超時統(tǒng)計

enqueue waits

鎖等待統(tǒng)計