一则orabbix报警的分析(r6笔记第65天)

最近使用zabbix监控之后,都会在凌晨收到1台数据库服务器的报警短信,报警的内容为: No data received from Orabbix 这个错误其实就是orabbix通过jdbc已经接受不到数据库实例的信息了,但是隔了10来分钟之后,又会收到问题恢复的短信。 既然问题已经自动修复了,可能在那个时间段里有一些固定的操作,操作完成之后,数据库实例的负载就自动恢复了。 根据提示的信息查看了问题时间段的awr和对应ash报告。 先来看awr报告,这个报告中的等待时间主要就是control file sequential read,占到了大概65%的比例。

Event

Waits

Time(s)

Avg wait (ms)

% DB time

Wait Class

control file sequential read

628,810

3,843

6

65.33

System I/O

DB CPU

847

14.40

db file sequential read

90,656

314

3

5.34

User I/O

log file sync

2,572

297

116

5.06

Commit

而查看ash报告,对这个等待事件进一步解读发现对应的file#为0

Event

% Event

P1, P2 , P3

% Activity

Parameter 1

Parameter 2

Parameter 3

control file sequential read

38.21

"0","1","1"

6.14

file#

block#

blocks

"0","17","1"

3.41

file#

block#

blocks

"0","18","1"

2.71

file#

block#

blocks

对于这个等待事件的主要原因还是对于基表的大量访问,同时会有大量的控制文件读写。 然后进一步抓取top sql,可以看到存在两个查询语句。

Elapsed Time (s)

Executions

per Exec (s)

%Total

%CPU

%IO

SQL Id

SQL Module

SQL Text

1,789.17

30

59.64

30.42

0.74

8.18

92t2p1mb77fd2

JDBC Thin Client

SELECT * FROM ( select '- Tabl...

1,745.27

35

49.86

29.67

0.92

5.01

fhud2jfjwy64g

JDBC Thin Client

SELECT to_char(sum( NVL(a.byte...

我们贴出其中一条。可以看出这一条是在查询资源的使用情况。 SELECT to_char(sum( NVL(a.bytes/1024/1024 - NVL(f.bytes/1024/1024, 0), 0)), 'FM99999999999999990') retvalue FROM sys.dba_tablespaces d, (select tablespace_name, sum(bytes) bytes from dba_data_files group by tablespace_name) a, (select tablespace_name, sum(bytes) bytes from dba_free_space group by tablespace_name) f WHERE d.tablespace_name = a.tablespace_name(+) AND d.tablespace_name = f.tablespace_name(+) AND NOT (d.extent_management like 'LOCAL' AND d.contents like 'TEMPORARY') 对于这个语句还是有一些印象,这是因为在orabbix默认提供的监控项中还是有这么一个sql语句的。 看来orabbix监控的时候,默认提供的语句就把自己给弄糊涂了。 仔细查看这个语句,里面存在大量的基表数据访问。为什么其它的库没有报这种问题,而这个库报了呢,一个原因就是这个库的数据文件比较多,大概有900多个,在平时运行的时候就有些慢了,其它的库相对数据文件要少很多,所以这方面的隐患就小很多。 所以这个问题到目前为止,发现这样两个orabbix默认提供的监控sql还是存在一定的隐患,可以后续改进,但是问题至少需要缓解吧。 从上面的图表可以看到,这两条语句在一个小时内基本运行了30次左右,也就是2分钟一次。 如果从orabbix的配置来看,执行频率确实是2分钟一次。 dbsize.Perod=2 dbfilesize.Period=2 所以在执行的过程中,下次发起请求的时候上次的结果还没有返回,就有了orabbix的报警。 对于这个问题,先暂时缓解,后续进行改进,我们可以尝试调大这个执行频率,比如几个小时执行一次,因为数据文件的使用情况的监控也不需要精确到分钟去详细统计,只需要得到一个大概的增长情况即可。 所以这样改进之后,后续持续改进这个监控项会有一定的提升。 通过这个案例我们可以看到如果监控工具本身的监控语句就不够优化,结果造成了性能隐患还是比较尴尬的,还是需要借鉴它的思想,持续改进。 末尾还有个问题就是,既然这个语句相对执行较慢,为什么平时不报警告,而在特定的时间点会报警呢,下一篇中会进行进一步的分析。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2015-09-20

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏沃趣科技

初相识 | 全方位认识 sys 系统库

前阵子,我们的"全方位认识performance_schema"系列为大家完整的介绍了performance_schema系统库。在我们的发布计划中为什么要把p...

2073
来自专栏文渊之博

SQL Server内存

背景 最近一个客户找到我说是所有的SQL Server 服务器的内存都被用光了,然后截图给我看了一台服务器的任务管理器。如图 ? 这里要说明一下任务管理器不会完...

3217
来自专栏数据和云

数据恢复:AMDU数据抽取恢复

今天我们通过一则真实的案例来认识oracle 自带工具AMDU,无需将磁盘组mount即可实现数据分析,轻松进行数据恢复 某日,我们收到了一则香港用户ASM破坏...

3106

使用 Excel 分析 CloudStack 使用记录

注:本文最初由 David Nailey 在 Build a Cloud 博客上撰写。

2149
来自专栏数据和云

忘记SQL Server 管理员密码不可怕,学会这招就够了

作者 | 邹建,资深数据库专家,精通各项 SQL Server 技术,具有丰富的管理、维护、优化能力以及业务应用经验。他一直热心于技术知识的分享、传播,持续活跃...

2253
来自专栏PHP在线

优化 MySQL: 3 个简单的小调整

如果你不改变 MySQL 的缺省配置,你的服务器的性能就像题图的坏在一档的法拉利一样 “虎落平阳被犬欺” … 我并不期望成为一个专家级的 DBA,但是,在我优化...

2817
来自专栏数据和云

举一反三:跨平台版本迁移之 XTTS 方案操作指南

作者 | 罗贵林: 云和恩墨技术工程师,具有8年以上的 Oracle 数据库工作经验,曾任职于大型的国家电信、省级财政、省级公安的维护,性能调优等。精通 Ora...

1543
来自专栏数据和云

故障分析:一则library cache lock问题处理

编辑手记:library cache lock 大家都并不陌生,在MOS上对该阻塞的一般成因描述为:一般可以理解的是alter table或者alter pac...

3725
来自专栏性能与架构

Mysql 压力测试工具 mysqlslap

mysqlslap 是 Mysql 自带的压力测试工具,可以模拟出大量客户端同时操作数据库的情况,通过结果信息来了解数据库的性能状况 mysqlslap 的一个...

6285
来自专栏Java技术分享圈

杨老师课堂之JavaEE三大框架Hibernate入门第一课

671

扫码关注云+社区

领取腾讯云代金券