通过定制orabbix监控分析潜在的Oracle问题 (r6笔记第32天)

在之前的博客中分享过 简单定制Orabbix监控项 http://blog.itpub.net/23718752/viewspace-1769773/ 定制的功能在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之后的效果如下,可以看到闪回区的使用率一下子降下来了。归档频率也降下来了。

通过这个问题可以看出,定制适合自己的监控项在某种程度上还是能够起到很好的监控作用。对于某些异常情况还是不要掉以轻心。

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

原文发表时间:2015-08-19

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏黑白安全

SQL(结构化查询语言)注入

SQL注入(也称为SQLI)是一种常见的攻击媒介,它使用恶意SQL代码用于后端数据库操作,以访问不打算显示的信息。此信息可能包括任何数量的项目,包括敏感的公司数...

8152
来自专栏Rgc

项目中记录影响性能的缓慢数据库查询

如果程序性能随着时间推移不断降低,那很有可能是因为数据库查询变慢了,随着数据库规模的增长,这一情况还会变得更糟。优化数据库有时很简单,需要在程序和数据库之间加入...

36811
来自专栏芋道源码1024

MySQL 大表优化方案(长文)

|原文链接:https://segmentfault.com/a/1190000006158186

1585
来自专栏数据和云

高危防范:巧用触发器,实现DDL监控

在数据运维过程中,常常因为DBA的疏忽而使数据安全面临威胁,有些威胁来自数据库外部,如rm操作,而有些威胁则来自数据库内部,如Truncate操作.因此对于数据...

2894
来自专栏Python、Flask、Django

备份博客数据的小脚本

1324
来自专栏北京马哥教育

为 Zabbix 优化 MySQL

Zabbix 和 MySQL 在大型的 Zabbix 环境中,遇到的挑战大部分是 MySQL 以及更具体的说是 MySQL 磁盘 IO。 考虑到这一点,我将提...

3203
来自专栏禁心尽力

会优化,你真的会优化吗?其实你可能真的缺少一份理解【数据库篇】

  其实,在写这篇博客之前,我也是感觉自己会点优化,至少知道不要使用“*”号啊,给经常查询的列创建索引啊什么的,其实都不是大家想的那样简单的,其实它们背后存在很...

1986
来自专栏后端技术探索

当规模到亿级,MySQL是一个更好的NoSQL!

MySQL是一个更好的NoSQL数据库。当考虑到NoSQL的使用案例,比如对Key/Value键值存储来讲,MySQL在性能、易用性和稳定性方面更有意义。MyS...

1291
来自专栏杨建荣的学习笔记

使用序列的问题ORA-02287(r5笔记第19天)

今天一个开发的同事问我一个问题,说在执行一条sql语句的时候报了ORA错误,脑海中删除了各种权限的问题之后,他提供给我的错误还是在我预料之外。 ERROR at...

3516
来自专栏跨界架构师

C#和NewSQL更配 —— CockroachDB入门(可能是C#下的全网首发)

  CockroachDB(https://www.cockroachlabs.com)是Google备受瞩目的Spanner的开源模仿,承诺提供一种高存活性、...

1115

扫码关注云+社区

领取腾讯云代金券