一则orabbix报警的分析(第一篇)

最近使用zabbix监控之后，都会在凌晨收到1台数据库服务器的报警短信，报警的内容为 : No data received from Orabbix
这个错误其实就是orabbix通过jdbc已经接受不到数据库实例的信息了，但是隔了10来分钟之后，又会收到问题恢复的短信。
既然问题已经自动修复了，可能在那个时间段里有一些固定的操作，操作完成之后，数据库实例的负载就自动恢复了。
可以从监控DB time的趋势图中看出一些端倪。

根据提示的信息查看了问题时间段的awr和对应ash报告。
先来看awr报告，这个报告中的等待时间主要就是 control file sequential  rea d，占到了大概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的报警。
对于这个问题，先暂时缓解，后续进行改进，我们可以尝试调大这个执行频率，比如几个小时执行一次，因为数据文件的使用情况的监控也不需要精确到分钟去详细统计，只需要得到一个大概的增长情况即可。
所以这样改进之后，后续持续改进这个监控项会有一定的提升。
通过这个案例我们可以看到如果监控工具本身的监控语句就不够优化，结果造成了性能隐患还是比较尴尬的，还是需要借鉴它的思想，持续改进。
末尾还有个问题就是，既然这个语句相对执行较慢，为什么平时不报警告，而在特定的时间点会报警呢，下一篇中会进行进一步的分析。

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

转载于:http://blog.itpub.net/23718752/viewspace-1804757/