Oracle11gR2 效能KPI 定義規則

整體效能KPI

整體KPI 根據例項執行效率計算得到一定時間內的效率值，可以透過對比執行環境等資訊比較直觀反映系統是否存在問題。

整體效率KPIBuffer Nowait

session 申請一次buffer 不等待的比率，需要接近或者100%

Redo NoWait

session 在生成redo entry 是不需要等待的比率，需要接近或者100%

Buffer Hit

buffer cache 命中率，如果太低說明buffercache 太小，應該接近100%，超過90%

In-memory Sort

在記憶體中排序比率，需要接近100%

Library Hit

庫快取命中率，一個sql 申請sql cursor 時已經在library cache中的比率。應該接近100% 超過95%

Soft Parse

軟解析比率，一般需要維持在95%以上

Execute to Parse

執行解析比率，越接近100%說明curosr 重用率越高。應該超過90%，DSS系統會較低。

Latch Hit

latch 命中率，如果太低說明有較多的latch等待。需要超過99%

Parse CPU to Parse Elapsd

這個比率表示真正在執行解析的CPU 消耗比率，如果太低說明有其他等待事件影響，應該超過90%

Non-Parse CPU

表示非解析消耗CPU 的比率，一般狀態良好的資料庫此比率超過90%，表示10%CPU用來解析，90%CPU消耗來執行SQL

時間模型KPI

時間模型大致表明了整體各個部分時間消耗比率，部分值越高越好，部分值需要比較低

DB CPU

CPU 消耗的時間在整個DB time 所佔比率，需要超過90%

sql execute elapsed time

sql 執行時間所佔比率，需要超過75%至80%

parse time elapsed

解析時間所佔比率，需要少於10%

connection management call elapsedtime

連線所佔用時間的比率，需要低於5%

2.等待事件KPI

等待事件說明了整體資料庫中因為資源爭用所等待的具體原因和時間，可以明確表明當前資料庫的健康狀態和執行狀態。每個等待事件不能超過20至30

等待事件KPIlatch:cache buffers chains

一般是低效SQL 或者hot block 會產生此等待事件。可以透過v$latch_children 和x$bh 查詢得到hot block的情況。

latch:cache buffers lru chains

此類等待事件一般是因為過多的請求空閒緩衝區。一般是由低效SQL引起。

buffer busy waits/read by other session

一般以上2個等待事件可以歸為一起處理，建議客戶都進行監控

以上等待時間可以由如下操作引起

select/select ---- read by other session

由於需要從資料檔案中將資料塊讀入 buffer cache 中引起，有可能是大量的邏輯/物理讀

或者過小的 buffer cache 引起

select/update ---- buffer busy waits/ read by other session

是由於更新某資料塊後需要在undo 中重建構建過去時間的塊，有可能伴生 enq:cr-contention

是由於大量的物理讀/邏輯讀造成。

update/update ---- buffer busy waits

由於更新同一個資料塊（非同一行，同一行是enq:TX-contention）此類問題是熱點塊造成

insert/insert ---- buffer busy waits

是由於freelist 爭用造成，可以將表空間更改為ASSM 管理或者加大freelist 。

write complete watis

一般此類等待事件是由於 DBWR 將髒資料寫入資料檔案，其他程式如果需要修改 buffer cache會引起此等待事件

一般是 I/O 效能問題或者是DBWR 工作負荷過量引起

free buffer waits

是由於無法找到可用的buffer cache 空閒區域，需要等待DBWR 寫入完成引起

一般是由於

低效的sql

過小的buffer cache

DBWR 工作負荷過量

enq:TC-contention

此等待事件是由伺服器程式引發的檢查點工作同步過程中發生。

目前有可能是由於parallel query 時slave 程式direct path read ，由於direct path read 不經過SGA，發起direct path read 之前會check point。此時會發生此等待事件。

enq:CI-contention

有可能發生在大量表同事truncate 時。

latch:shared pool

為了查詢free chunk，檢索空閒列，分配適當的chunk，需要獲得latch:shared pool,此時如果發生爭用將會出現此等待事件。一般會發生在hard parse 非常嚴重的資料庫中。

latch:library cache

一般此類等待事件發生在hard parse/soft parse 過多時，記憶體區域page out 時，version count 非常高時

library cache lock/library cache pin

由於此2種等待事件發生情況較複雜，建議使用者可以查閱MOS 相關文件

一般會由於如下原因引起

大部分由於不捨當的DDL 操作

硬解析頻繁的系統容易發生 library cache pin

row cache lock

許多程式使用沒有賦予cache 屬性的sequence 時候容易發生大量的 row cache lock

如果沒有使用sequence 發生大量此等待事件，建議使用者聯絡MOS 檢視

enq:SQ-contention/DFS lock handle

一般此類等待事件發生在sequence 呼叫nextinterval 時，如果sequence 的cache 值較小時會發生此類等待事件。

enq:TM-contention

執行DML 期間為了防止DML 物件被修改，需要獲得對應的TM 鎖。如果發生爭用則會發生enq:TM-contention 等待。

enq:TX-row lock contention

TX鎖是保護事物的，一般修改特性行發生爭用時會產生此類等待事件。

enq:TX-allocate ITL entry

需要在特定的ITL 槽上登記事務時，會產生此類等待事件，有可能發生於對pctfree 較小的表做了增加列的DDL 後再做大量的DML操作。

enq:TX-index contention

此類等待事件有可能發生於索引葉節點發生分裂時發生。

enq:HW-contention

一般為了防止多個程式同時修改HWM 而產生的鎖為enq:HW-contention.一般此類等待事件是大量執行insert 引發的，但是一般時由於exent 大小設定不當引起，使用ASSM 並且使用LMT 賦予合適的extent 大小可以減少此類等待發生。

enq:US-contention

為了同步將會滾段離線或者聯機的過程，每個回滾段都有一個US 鎖，需要執行的程式會需要獲得這個鎖。此等待事件有可能發生在突然增大的事物時，並且所擁有的undo 表空間較小。

db file scattered read

如果資料庫執行全表掃描或者是全索引掃描會執行 Multi block I/O ，此時等待物理I/O 結束會出現此等待事件。

一般會從應用程式（SQL），I/O 方面入手調整。

db file sequential read

相對於上面的等待事件，此等待事件是由於執行 single block I/O 引起，一般在索引掃描，

讀取控制檔案頭，透過rowid 掃描讀取資料檔案頭髮生

有可能發生在低效的索引掃描，行連結行遷移中。

direct path read

此等待事件是由於執行 parallel query 時候 slave session 執行 direct patch I/O 引發

一般從調整 paralle query 效能或者 I/O 效能入手

direct path write

出現此類等待事件說明資料庫不經過SGA 直接對資料檔案執行寫入，如果過高可以判斷為檔案系統效能問題

direct path read temp/direct path write temp

當排序操作所需要的空間比sort area 大時，需要用到臨時表空間，一般此類等待事件發生在排序操作較頻繁但是同時pga 引數設定過小時發生。

db file parallel write

一般是由於I/O效能問題導致 DBWR 寫入髒資料緩慢。

controlfile parallel write

頻繁的更新控制檔案會造成大量此類等待事件，如日誌頻繁切換，檢查點經常發生，nologgin 引起頻繁的資料檔案更改，I/O 系統效能緩慢。

log file sync

一般此類等待時間是由於 LGWR 程式講redo log buffer 寫入redo log 中發生

如果此類事件頻繁發生，可以判斷為：

commit 次數是否過多

I/O 系統問題

重做日誌是否不必要被建立

redo log buffer 是否過大

log buffer space

如果此類等待時間發生，有可能因為 redo log buffer 過小，如果和log file switch completion同時出現應該考慮是否redo log 和redo log buffer 是否大小合適

3.Latch 效能指標

主要檢視對應latch 的丟失率來檢視資料庫資源競爭情況。

Latch Pct Get Miss 率DML lock allocation

DML lock allocation

Oracle11gR2 效能KPI 定義規則

相關文章