Oracle11gR2 性能KPI 定义规则

Oracle11gR2 性能KPI 定义规则

整体性能KPI

整体KPI  根据实例运行效率计算得到一定时间内的效率值，可以通过对比运行环境等信息比较直观反映系统是否存在问题。

整体效率KPI Buffer 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

等待事件KPI latch: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 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29440247/viewspace-1817030/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/29440247/viewspace-1817030/