Oracle11gR2 性能KPI 定义规则

ALLSTARS_ORACLE

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 是保护整个DMLlock，当一个transcation 需要修改表时，会获得这个latch 并且当结束时释放这个latch。

这里丢失率反映了整体transcationdml lock 的资源竞争情况。不应超过3%

cache buffers chains

这个latch 保护了cache buffers chains 资源，miss 率反映了热点块或者低效sql 引起的系统资源竞争。miss率不应高于1%

cache buffers lru chain

这个latch 保护了cache buffers lru chains 资源，miss 率反映了空闲列引起的资源竞争。miss率不应高于3%

shared pool

这个latch 保护了shared pool 资源，当需要访问shared pool 时需要获得相应的latch，miss率反映了资源竞争情况，miss 率不应高于2%

redo allocation

row cache objects

4.数据库内存 KPI

SGAMemory Usage %

此参数反映了数据库SGA使用比率，需要对比前1小时数据，如果有超过5%的改动并且超过本身使用率超过95%，需要及时注意防止4031错误

SQL with executions>1

此参数反映了sql 重复运行的比例，这个值不应低于90%,DSS系统不应低于60%，此参数过低反映了 sql 重用率调低，可能会导致hardparse 过高。

Memory for SQL w/exec>1

此参数反映了重复运行sql 在内存中所占比例，不应低于80%。

PGAPGA 变化率

根据PGA Memory Advisory 中消除 Estd PGAOveralloc Count 为准，

从以下示例来看163mb PGA 即可满足要求，母亲6540mb 属于正常取值。

PGA Target Est (MB)	Size Factr	W/A MB Processed	Estd Extra W/A MB Read/  Written to Disk	Estd PGA Cache Hit %	Estd PGA Overalloc  Count	Estd Time
818	0.13	29,472,881.80	66,796,857.88	31.00	536,097	10,732,689,175
1,635	0.25	29,472,881.80	15,324,506.07	66.00	8	4,994,263,425
3,270	0.50	29,472,881.80	15,013,973.47	66.00	0	4,959,643,513
4,905	0.75	29,472,881.80	14,995,995.21	66.00	0	4,957,639,196
6,540	1.00	29,472,881.80	14,995,992.46	66.00	0	4,957,638,890
7,848	1.20	29,472,881.80	14,726,747.46	67.00	0	4,927,621,951
9,156	1.40	29,472,881.80	14,726,747.46	67.00	0	4,927,621,951
10,464	1.60	29,472,881.80	14,726,747.46	67.00	0	4,927,621,951
11,772	1.80	29,472,881.80	14,726,747.46	67.00	0	4,927,621,951

5.文件系统 KPI

I/O 性能datefile Av Rd(ms)

数据文件平均读取时间以超过1000次block I/O 不超过40ms 为标准。

以下示例可以看到某数据文件 AvRd(ms) 超过96ms 但是读取次数只有9次，在此不具有参考意义。

Tablespace	Filename	Reads	Av Reads/s	Av Rd(ms)	Av Blks/Rd	Writes	Av Writes/s	Buffer Waits	Av Buf Wt(ms)
SYSAUX	/sysdata/worarept/worarept/sysaux01.dbf	44	0	2.73	1.00	301	0	0	0.00
SYSTEM	/sysdata/worarept/worarept/system01.dbf	1,546	0	0.71	1.00	74	0	0	0.00
TBS_DATA_INTERFACE	/oradata04/worarept/TBS_DATA_INTERFACE_01.dbf	510	0	1.80	1.01	281	0	0	0.00
TBS_DATA_INTERFACE	/oradata04/worarept/TBS_DATA_INTERFACE_02.dbf	496	0	1.09	1.00	298	0	1	0.00
TBS_DATA_INTERFACE	/oradata04/worarept/TBS_DATA_INTERFACE_03.dbf	102	0	2.45	1.00	179	0	0	0.00
TBS_DATA_INTERFACE	/oradata04/worarept/TBS_DATA_INTERFACE_04.dbf	66	0	2.12	1.00	55	0	0	0.00
TBS_DATA_INTERFACE	/oradata04/worarept/TBS_DATA_INTERFACE_05.dbf	952	0	0.43	1.00	960	0	0	0.00
TBS_DATA_INTERFACE	/oradata04/worarept/TBS_DATA_INTERFACE_06.dbf	528	0	1.95	1.00	311	0	0	0.00
TBS_DATA_INTERFACE	/oradata04/worarept/TBS_DATA_INTERFACE_07.dbf	114	0	5.09	1.00	75	0	63	0.16
TBS_DATA_RPT_01	/oradata04/worarept/TBS_DATA_RPT_01_44.dbf	9	0	96.67	2.11	6	0	0	0.00

redo log 切换速度

当alert log 中出现过多的checkpoint not complete 和 cannot allocate new log 时说明redo log 配置出现问题，前者表示redo log 大小太小，在一次checkpoint时间中即需要再次切换，后者说明redo log 日志组太小，最先需要轮询使用的日志组还没有完成归档即需要重用。每个所在日志切换比例已不超过10%(以4小时为单位)

Total log switches found	3821
Total Checkpoint not complete messages found	13
Total Cannot allocate new log messages found	134

6.SEGMENTS KPI

Logical Reads

某个对象的逻辑读占到整体逻辑读的40%以上，此时可以明显表明性能瓶颈。

例如以下示例，优化相关语句可以极大提升性能。

Owner	Tablespace Name	Object Name	Subobject Name	Obj. Type	Logical Reads	%Total
DBCUSTADM	TBS_DATA_INTERFACE	IN_CRINTERFACE_INFO		TABLE	87,958,480	35.22
DBCUSTADM	TBS_DATA_INTERFACE	IN_CMINTERFACE_INFO		TABLE	46,550,960	18.64
DBRPTADM	TBS_IDX_RPT_01	RPT_BUSIMOBJ_RD_201306_K_UK		INDEX	9,951,648	3.99
DBRPTADM	TBS_IDX_RPT_01	RPT_BUSIMOBJ_RD_201306_A_UK		INDEX	8,124,320	3.25
DBRPTADM	TBS_DATA_RPT_01	RPT_BUSIFEE_RD_201306_A		TABLE	5,326,528	2.13

physical reads

某个对象的物理读占到整体物理读的40%以上，此时可以明显表明性能瓶颈。

例如以下示例

Owner	Tablespace Name	Object Name	Subobject Name	Obj. Type	Physical Reads	%Total
TP2	TP2_TS_TABLES	TPI_OE_ORDER_ITEMS_REG_ID		INDEX	451	31.56
TP2	TP2_TS_TABLES	TPPK_OFFERING_ACTION_ID		INDEX	441	30.86
TP2	TP2_TS_TABLES	TPI_REG_SID		INDEX	342	23.93
TP2	TP2_TS_TABLES	CMT_PERSON		TABLE	26	1.82
TP2	TP2_TS_TABLES	CMPK_PERSON_ID		INDEX	3	0.21

7.OS KPI

cpu 使用率  

CPU 使用率大致反映了数据库服务器的繁忙程度。一般认为CPU使用率每5分钟的平均值的变化率不超过20%，并且CPU使用率绝对值不超过90%。 如果超过即需要注意。

当CPU 使用率达到100%说明有进程已经可能无法及时响应了，这时要单独判断数据库不健康需要立即注意处理。

内存使用率  

内存使用率不超过90%

page in/page out

整体oracle 使用内存不会发生page in/page out 。

8.Alert Log KPI
alert log

监控整个alert log 中出现的ORA 错误，

由于ORA 错误出现种类较多，这里监控采用排除法，例如排除部分不需要处理的错误编号

例如以下ORA 3297 表示用户中断了操作，不需要处理。

ORA-3297signalled during

出现任何需要处理的ORA 错误需要立即判定数据库处于不健康状态。

10.可用性KPI
session 连接数

每分钟探测数据库session 数，并且对比上一时间段的数据，如果session 数对比上一时间变化超过20%，对比昨天和上一周同一时间内的session 数变化超过20%，需要判定数据库不健康。

监听可用性

每隔5秒，探测tnsping 连接延时，延时超过30ms 即需要判定数据库不健康，因为此时外界连接可明显感觉延迟较高，中间件或者部分应用会变得不可用。

不了峰

收藏

定出这些KPI不容易

枕霜卧雪

我比较关心的是，如何系统的配置监控和告警。
这些KPI都是从em后者gc中可以动态监控么？