DBA团队维护的部分应用运行在oracle数据库平台,为及时了解数据库的运行情况,需要建立涵盖各个维度的监控体系,包括实例状态、空间使用率、ORA错误等数十项监控指标。这其中有一个有效判断数据库运行负载是否发生变化、有没有隐患或潜在异常的指标就是等待事件数量,有了它就好比给数据库安装了一个听诊器、温度计,能及时感知脉搏、体温等关键指标变化。
下面我们就来讲讲等待事件是什么含义,以及如何实施有效的监控。
一、等待事件是什么
等待事件(wait event) 是在Oracle 7.0.1版本引入的,它是诊断和优化数据库的核心利器。形象的说,如果把oracle数据库比作一个医院,分类别的等待事件就是组成医院的各个科室。每一类等待事件都有其独特的含义和处置方法,在数据库发生隐患或问题时就可以去特定的科室看病或安排联合会诊。
等待事件主要分为空闲等待事件和非空闲等待事件两类:
1)空闲等待事件(idle event):主要是指Oracle正等待某种工作,目前资源是空闲的,在优化和诊断数据库中,不需要特别关注。常见的空闲等待事件主要有:Null event、pipe get、PL/SQLlock timer等。
2)非空闲等待事件(non-idleevent): 指数据库任务或应用运行中发生的等待,指数据库正在运行过程中的活动,在数据库诊断和优化中要特别关注。常见的非空闲等待事件主要有:db file scattered read(数据块离散读)、db filesequential read(数据块顺序读)、buffer busy wait(热点块)、enq: index contention(索引争用等)。
可以用下面的方法查询当前非空闲等待事件的分类及数量:
select a.inst_id,a.event,count(*) fromgv$session a where a.username is not null and a.status='ACTIVE’and a.wait_class< > 'Idle'group by a.inst_id,a.event;
类似如下的结果:
INST_ID | EVENT | COUNT(*) |
1 | db file scattered read | 11 |
1 | gc cr request | 5 |
1 | log file sync | 2 |
2 | db file sequential read | 6 |
2 | enq:TX- row lock contention | 4 |
随着版本的演变,等待事件数量也在不断变化,在Oracle11g数据库中,等待事件有1152个,可以通过v$event_name视图查询等待事件的相关信息。
常见等待事件有33个,每一个等待事件都属于某一类,对于存在一定风险、需要关注的主要有下面几类:
1)应用程序类:主要由用户程序的代码引起,比如锁等待,主要与程序设计不优等有关。
2)集群类:和Oracle RAC资源有关,比如gc cr block busy等待,主要与RAC资源管理、节点应用分布等有关。
3)提交确认类:在执行一个commit后,等待重做日志写确认,即log file sync等待,主要与程序频繁的commit或数据库自身处理能力等有关。
4)系统IO类: 由后台进程的IO操作引起,比如DBWR等待、db file parallel write等,主要与数据库自身的处理能力、内存参数设置等有关、
5)用户IO类:有用户IO操作引起,比如db file sequentailread等,主要与程序设计、访问路径等有关。
二、如何对等待事件进行有效监控
考虑到等待事件是数据库运行状况的集中反映,就需要研究一套切实有效的监控方法。等待事件数量众多,在数据库正常运行的情况下,数十种各类等待事件都是并行存在的,如何能设置一个相对较好的方法,既能发现异常或隐患,又不能频繁产生虚警,是一个需要认真研究的问题。
我们在生产实践中反复摸索、不断优化,形成针对等待事件的监控方法,其做法是:定期对(建议分钟级)对目标数据库数据库非空闲等待事件进行检查和自动分类分析,在同时满足以下条件则触发警告:
(1)某一类等待事件的活动会话数超过总活动会话数的1/3;
(2)该等待事件的活动会话数超过20个;
(3)活动会话数超过当前总会话数的1/2或总活动会话数超过process参数设置的30%;
(4)系统总会话数超过50个。
其中第1、2两点旨在反映某一类特定等待事件引发的异常(比如发生大面积的行级锁或全表扫描等);第3、4旨在反映当前数据库整体负载的情况,是否已经出现缓慢的隐患。
相关的监控脚本如下:
insert intomaintain_user.wait_event_check_hist select * from maintain_user.wait_event_check
WHEREEVENT_ACT_SESSION/TOTAL_ACT_SESSION > 1/3
ANDEVENT_ACT_SESSION >20
AND(TOTAL_ACT_SESSION/SESSIONS > 1/2 OR SESSIONS/SESSION_TOTAL > 0.3)
AND SESSIONS> 50
ANDEVENT_ACT_SESSION<TOTAL_ACT_SESSION
ANDTOTAL_ACT_SESSION<SESSIONS;
commit;
触发阀值报会自动上送报警告给监控平台,并给DBA发邮件提醒,如下所示:
对于敏感系统还可以制定更为敏感的阀值和策略,在做好常规等待事件监控基础上,增加堵塞会话(blocking session)的监控。通过定期查询v$SESSION视图的信息,对被阻塞的会话的个数进行统计,如果超过一定数量(阀值为5)则触发警告,相关监控如下所示:
二、等待事件监控在生产运行发挥的作用
不完全统计,从去年10月分至今,各类系统共发现570多条等待事件报警,包括110条dbfile sequential read 、38条logfile sync等等,及时发现在程序设计、存储争用、应用性能变化等方面存在的异常,采取优化处置措施,有效避免生产故障的发生。
特别是版本投产后,语句效率的问题会比较突出,此时等待事件的监控可有效发生作用避免问题的进一步恶化。
等待事件 | 汇总 |
db file sequential read等待事件异常 | 110 |
gc buffer busy acquire等待事件异常 | 65 |
cursor: pin S wait on X等待事件异常 | 51 |
read by other session等待事件异常 | 51 |
direct path read等待事件异常 | 50 |
latch free等待事件异常 | 42 |
log file sync等待事件异常 | 38 |
library cache: mutex X等待事件异常 | 29 |
resmgr:cpu quantum等待事件异常 | 24 |
enq: TX - row lock contention等待事件异常 | 18 |
latch: cache buffers chains等待事件异常 | 15 |
enq: TM - contention等待事件异常 | 12 |
三、小结
Oracle等待事件是衡量数据库运行状况的重要依据及指标,针对其存在的潜在风险制定一整套切实有效的监控方法、设置合理阀值,可以尽早发现隐患,及时采取应急处置措施,有效地避免的问题的蔓延。随着生产系统的不断变化,其监控阀值设计也要针对性优化,以匹配生产实际的需要。