通过定制Orabbix监控分析潜在的Oracle问题
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了通过定制Orabbix监控分析潜在的Oracle问题,小编现在分享给大家,供广大互联网技能从业者学习和参考。文章包含3922字,纯文字阅读大概需要6分钟。
内容图文
![通过定制Orabbix监控分析潜在的Oracle问题](/upload/InfoBanner/zyjiaocheng/535/80e348bacf994d65bcd70c3bcd586f43.jpg)
定制的功能在Orabbix中实现非常灵活而且轻巧,还是能够感受到一种开源风的清爽。在orabbix原有模板的基础上添加了几个监控项,一
在之前的文章中分享过 简单定制Orabbix监控项
定制的功能在Orabbix中实现非常灵活而且轻巧,还是能够感受到一种开源风的清爽。
我在orabbix原有模板的基础上添加了几个监控项,一个是监控闪回区的使用率,,还有一个是监控归档的切换频率,这两个功能看似微不足道,但是会在细节中反应出数据库中是否有明显的异常行为。
中午的时候注意到有一个库的闪回区使用率和归档频率比较高。还是有一些反常,而从我这边的信息来看,没有得到开发人员的反馈说需要做什么数据变更。
得到的orabbix监控图如下:
闪回区的使用情况如下:
归档频率如下:
通过这个图可以看到还是有一些异常情况的。这个库是一个统计库,案例来说并发访问量应该不高,但是现在从早上的某个时间点开始,归档量急剧提升,已经快触及警报线。
在这个时候也是带着疑问去检查了一下这个库,结果通过ash视图去看,是否正在进行大量的并发操作,结果没有任何的active session,然后查看数据库负载,又很高。
抓取了一个awr报告来看。赫然发现top1的sql竟然是一个update语句。
Elapsed Elapsed Time
Time (s) Executions per Exec (s) %Total %CPU %IO SQL Id
---------------- -------------- ------------- ------ ------ ------ -------------
3,604.9 0 N/A 26.9 32.5 68.2 3jggcpxmv6w8g
Module: sqlplus@stat.xxxxx.com (TNS V1-V3)
update "xxxx"."TEST_BILLING" set "ID" = 'xxxxxxxxxx'
这个语句可以明显看出来存在一定的问题,因为这是一个大表,数据量在亿级,进行这样一个dml操作,代价还是相当大的。
为了一探究竟我们来看看到底是谁在执行这样一个dml。
结果一看还是让人大吃一惊,竟然是在本地的sys的操作,问题又指向了自己,因为这个库开发人员是没有任何权限直接访问的。
USERNAME SID SERIAL# PROGRAM MACHINE
--------------- ---------- ------------------------------------------------ --------------------
SYS 22 50043 sqlplus@stat.xxxxxxxxxx,com (TNS V1-V3) xxxxxxxx.cyou.com
SYS 3560 63187 sqlplus@stat.xxxxxxxxxx,com (TNS V1-V3) xxxxxxxx.cyou.com
但是我确实也没有做任何的操作,不至于说哪个脚本很神奇的执行了?
带着疑问和同事进行排查,最后发现,这个dml语句是在做log miner解析的时候出了点问题。
因为一些数据同步的考虑,需要从另外一个核心库中同步一部分的数据到这个统计库中,但是又不想直接在主库中进行任何的额外配置,这个时候就使用了log miner来定制抽取归档中的sql语句,然后部署在这个统计库中。这个过程是通过crontab来触发的。
但是在log miner解析的过程中还是出了一点解析的问题,有一条update语句没有where字句结果就直接应用到这个统计库中了,结果生成了大量的redo,归档切换也很频繁。
比如说解析log miner的视图的时候,默认是使用下面的方式。
SELECT sql_redo FROM v$logmnr_contents WHERE seg_owner='XXXX' AND TABLE_NAME IN ('XXXX','XXXXXX') AND OPERATION in ('INSERT','UPDATE','DELETE')
结果某一条语句在解析的过程中出了问题,结果导致对于这类不规范的update语句,应用到统计库的时候把影响放大了。
可以通过交半年进行过滤,也可以直接在sql中进行过滤。比如修改为下面的形式。
SELECT sql_redo FROM v$logmnr_contents WHERE seg_owner='XXXXX' AND TABLE_NAME IN ('XXXX','XXXX') AND OPERATION in ('INSERT') or (operation in ('DELETE','UPDATE') and upper(sql_redo) like '%WHERE %')
这样对于update和delete操作都hi进行必要的过滤,那些不指定条件的delete,update操作都可以直接屏蔽。
当然对这个问题的紧急修复也很明确,就是kill那个运行很长时间的session.
Kill session之后的效果如下,可以看到闪回区的使用率一下子降下来了。归档频率也降下来了。
通过这个问题可以看出,定制适合自己的监控项在某种程度上还是能够起到很好的监控作用。对于某些异常情况还是不要掉以轻心。
内容总结
以上是互联网集市为您收集整理的通过定制Orabbix监控分析潜在的Oracle问题全部内容,希望文章能够帮你解决通过定制Orabbix监控分析潜在的Oracle问题所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错,欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 gblab@vip.qq.com 举报,一经查实,本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。