如何進(jìn)行AWR中的主要事件分析

名稱

注釋

CPU used by this session

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

CR blocks created   

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

current blocks converted for CR

一個(gè)CURRENT的BUFFER在被使用前生成了CR

DBWR buffers scanned

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

DBWR checkpoint buffers written

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

DBWR free buffers found

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

DBWR make free requests

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

DBWR summed scan depth

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

DBWR timeout

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

DBWR transaction table writes

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

DBWR undo block writes

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

DDL statements parallelized

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

DML statements parallelized

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

background checkpoints completed

后臺(tái)進(jìn)程完成的CHECKPOINTS的數(shù)量。

background checkpoints started

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

branch node splits

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

BUFFER DEADLOCK

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

buffer is not pinned count

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

buffer is pinned count

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

change write time

當(dāng)前塊的變化被寫入REDO的時(shí)間，單位厘秒（cs,10毫秒），該指標(biāo)一般不會(huì)太大，如果太大需要分析

commit cleanout failures: block lost

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

commit cleanout failures: buffer being written

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

commit cleanout failures: callback failure

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

commit cleanout failures: cannot pin

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

commit cleanout failures: hot backup in progress       

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

commit cleanout failures: write disabled

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

commit cleanouts

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

commit cleanouts successfully completed

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

consistent changes

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

consistent gets

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

data blocks consistent reads - undo records applied

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

deferred (CURRENT) block cleanout applications

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

dirty buffers inspected

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

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

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

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

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

enqueue waits

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

exchange deadlocks

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

free buffer inspected

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

global cache freelist waits

當(dāng)ping一個(gè)buffer的時(shí)候由于所有的lock element都被使用而引起的等待。

global lock convert time

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

hot buffers moved to head of LRU

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

immediate (CURRENT) block cleanout applications

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

leaf node splits

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

logons current

當(dāng)前登錄數(shù)據(jù)庫(kù)的計(jì)數(shù)

opened cursors current

當(dāng)前的Open CURSORS的數(shù)量

opens of replaced files

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

parse count (hard)

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

parse count (soft)

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

parse count (total)

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

parse time cpu

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

parse time elapsed

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

physical reads direct

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

physical writes direct

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

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

l          并行DML操作

l          排序操作中的臨時(shí)表空間寫入

l          寫入沒有緩沖的LOB字段

physical writes non checkpoint

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

pinned buffers inspected

當(dāng)一個(gè)用戶進(jìn)程掃描REPLACEMENT列表，尋找一個(gè)可重用的BUFFER的時(shí)候，發(fā)現(xiàn)一個(gè)冷塊被PIN了或者有一個(gè)PIN請(qǐng)求的等待事件。這種情況很少發(fā)生，因?yàn)槔鋲K很少會(huì)被PIN。如果平均每秒該指標(biāo)值較大，需要進(jìn)行分析

queries parallelized

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

recursive cpu usage

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

recovery array read time

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

recovery array reads

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

recovery blocks read

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

redo entries

當(dāng)一個(gè)redo信息被拷貝到log buffer的時(shí)候這個(gè)計(jì)數(shù)增加

redo entries linearized

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

redo buffer allocation retries

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

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

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

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

l           LOG  BUFFER的大小是否過小

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

redo log space wait time

Redo log space requests的等待時(shí)間（單位厘秒），這個(gè)指標(biāo)需要和上一個(gè)指標(biāo)一起看

redo size

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

redo synch time

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

redo sync writes

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

redo wastage

在把LOG BUFFER數(shù)據(jù)寫入REDO LOG文件的時(shí)候計(jì)算的LOG BUFFER空閑的空間

redo writer latching time

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

redo writes

LGWR將LOG BUFFER寫入REDO LOG文件的計(jì)數(shù)

remote instance undo block writes

如果遠(yuǎn)程的實(shí)例需要讀取某個(gè)UNDO BLOCK，需要這個(gè)實(shí)例先將這個(gè)“臟的”UNDO BLOCK回寫，這個(gè)計(jì)數(shù)器就會(huì)增加

remote instance undo header writes

和上一個(gè)指標(biāo)類似，只是寫入的是UNDO HEADER

remote instance undo requests

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

rollback changes - undo records applied

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

rollbacks only - consistent read gets

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

rows fetched via callback

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

session cursor cache count

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

session cursor cache hits

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

sorts (disk)

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

sorts (memory)

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

summed dirty queue length

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

switch current to new buffer

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

table fetch by rowid

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

table fetch continued row

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

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

還有一種可能性就是系統(tǒng)中訪問帶LOB字段的訪問較多，因?yàn)榇蟮腖OB字段一般來說采用獨(dú)立的SEGMENT存放，因此訪問這種數(shù)據(jù)也會(huì)增加這個(gè)統(tǒng)計(jì)值

total file opens

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

transaction rollbacks

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

write clones created in background

如果當(dāng)前的BUFFER正在被寫入，那么后臺(tái)進(jìn)程或者前臺(tái)進(jìn)程克隆一個(gè)新的BUFFER，使原來BUFFER的寫入可以繼續(xù)進(jìn)行

enqueue conversions

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

enqueue deadlocks

死鎖統(tǒng)計(jì)

enqueue releases

鎖釋放統(tǒng)計(jì)

enqueue requests   

鎖申請(qǐng)統(tǒng)計(jì)

enqueue timeouts

鎖申請(qǐng)超時(shí)統(tǒng)計(jì)

enqueue waits

鎖等待統(tǒng)計(jì)