ITPub博客

首页 > 数据库 > Oracle > Oracle11gR2 性能KPI 定义规则

Oracle11gR2 性能KPI 定义规则

原创 Oracle 作者:xulongxc 时间:2015-10-28 08:43:23 0 删除 编辑
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
等待事件说明了整体数据库中因为资源争用所等待的具体原因和时间,可以明确表明当前数据库的健康状态和运行状态。每个等待事件不能超过2030
等待事件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 

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

全部评论

注册时间:2014-01-13

  • 博文量
    58
  • 访问量
    213941