一则备库CPU报警的思考(r7笔记第69天)

今天收到一封报警邮件,这引起了我的注意。当然过了一会,有收到了CPU使用率恢复的邮件。 报警邮件内容如下: ZABBIX-监控系统: ------------------------------------ 报警内容: Disk I/O is overloaded on ora_statdb2_s_xxx@xxxxx ------------------------------------ 报警级别: PROBLEM ------------------------------------ 监控项目: CPU iowait time:14.1 % ------------------------------------ 报警时间:2016.01.05-03:31:26 看到这封报警邮件,不知道大家作何感想,有什么疑问吗? 首先第一个疑问,为什么备库会报出CPU异常的邮件,到底是什么操作导致。 第二,为什么是备库报警,主库为什么没有报警。 第三,怎么去杜绝或者减少这类报警。 其实对这个问题做了分析,就会发现里面还是有一些治标治本的含义。 首先来逐步分析这个问题,为什么备库会报出CPU异常,这是一个OLAP的数据库,11gR@,CPU使用异常,是否是因为备库在做大量的报表查询? 要想验证这个问题,可以用一个直接了当的sql来说明。 SQL> select username,count(*)from v$session group by username; USERNAME COUNT(*) ------------------------------ ---------- 32 PUBLIC 3 SYS 1 所以其他的设想都不存在,这个库没有其它的应用程序连接,可以简单来说就是在默默接收归档。 那么备库的CPU使用率为什么这么高,我们也可以结合很多原因来看,当然从数据库日志里面也能看出一些端倪来,那就是归档切换频率还是蛮高的。 可以看到网卡的繁忙程度,其实在一个时间段里还是比较集中的。

那么就可以从主库来分析一下归档的情况了。 当然我也确实比较懒,能看到图形报告就肯定不愿意多去拿更多的命令去分析了。 主库的归档切换频率如下,可以看到系统在特定的时间段里还是比较繁忙的。

但是话说回来,这是一个OLAP,怎么比OLTP还繁忙。 如果排除系统的原因,那么更多的可能性就是sql语句了。不过还有一个问题需要弄明白,是不是每天都会这样,因为不是每天都收到报警邮件。 我们来看看七天之内的归档情况。可以看到在每天的固定时间段里,归档切换还是比较频繁的,尤其在今天更为明显。

当然这个地方我还要补充一下,图形结果都是片面的,更好的说明还有一个文本的报告。 也是下面的文本报告给我了思路。

如果仔细看看,发现其实在每周的周二都会有一个时间段产生大量的归档。 如此一来,想必有些朋友应猜出来了,应该是scheduler导致,这个也是我最后定位问题的一个很好的方向。结合一个星期还不够,结合了大半个月的数据才发现了这个规律。 那么可以去查看awr报告看看哪些scheduler在运行。 还是用脚本吧。62033是问题时间段附近的快照号。就得到了下面的sql列表。 $ sh showsnapsql.sh 62033 ---------- ------------- ---------------- ---------- ---------- 62033 75ubgcf0pdrkr 0 1802s 19% 62033 36s5j5zrztscz 0 1802s 19% 62033 882jz57wm9cj7 0 1802s 19% 62033 gab74zwuduz76 0 1678s 18% 62033 0fhgdzus0hu2t 0 1628s 17% 毫无疑问,这几个里面应该就有我们需要找到的目标,可以看到top 5的sql语句都是执行了近半个小时,executions都为0.所以还是有很大的可能性。 抓取到了几个大查询sql,几个update,当然最重要的就是其中的一个scheduler了。 SQL_FULLTEXT ---------------------------------------------------------------------------------------------------- BEGIN proc_update_cardinfo(); END; 其实top 5中的sql语句都会直接间接在这个scheduler中调用的存储过程中存在。而这个语句的一个核心语句就是下面的形式。 SQL_FULLTEXT ---------------------------------------------------------------------------------------------------- UPDATE TESTINFO A SET A.MAX_LEVEL = NVL((SELECT USER_CLASS FROM ROLE_CLASS_INFO B WHERE A.GROUPID = B.GROUP_ID AND B.CN_GUID = A.ROLE_GUID), A.MAX_LEVEL) WHERE DRAWED = 'Y' 表里的数据都在亿级,所以全表也会很长时间,消耗也是非常的大。 当然后续就是看看这个语句,还有什么改进的空间,这个还是得和开发的同学好好讨论一下。 然后最后的问题,为什么主库没有这类的报错。 有两个数据可以佐证,那就是主库的内存是132G,备库是32G,主库的CPU是24,而备库是8,相差比较悬殊,也难怪会出现这样的问题。 所以通过备库的CPU报警我们发现备库存在大量的日志切换,然后把注意力很自然转移到主库,发现在特定的时间段里会产生大量的归档,而大量的归档的产生会 给备库造成一些系统压力,导致CPU负载过高,但是根本的是为什么主库的归档产生非常多,和主库中的而一个scheduler有关,所以最后的根本就是调 优这个scheduler看看,有多大的改进空间。

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

原文发表时间:2016-01-05

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

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

通过外部表改进一个繁琐的大查询 (r8笔记第32天)

今天处理了一个比较有意思的案例,说是有意思,因为涉及多个部门,但是哪个部门似乎都不愿意接。最后还是用了一些巧力,化干戈为玉帛。 问题的背景是这样的,业务部门需要...

34290
来自专栏xingoo, 一个梦想做发明家的程序员

循序渐进,了解Hive是什么!

一直想抽个时间整理下最近的所学,断断续续接触hive也有半个多月了,大体上了解了很多Hive相关的知识。那么,一般对陌生事物的认知都会经历下面几个阶段: ...

26350
来自专栏about云

比Hive快279倍的数据库-ClickHouse到底是怎样的

1.什么是ClickHouse? 2.ClickHouse适合哪些场景? 3.为什么面向列的数据库查询如此快? 1.什么是ClickHouse ClickHo...

51940
来自专栏数据和云

从原理到实践:Oracle 12.2 Sharding技术揭秘

何剑敏 Oracle ACS华南区售后团队,首席技术工程师 曾供职于中国联通信息计费部、卓望数码,系统支撑部首席DBA,负责中国移动全网梦网业务和移动应用商城...

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

Oracle和MySQL的高可用方案对比(二)

昨天聊了一篇关于高可用方案中Oracle的RAC和MySQL的MHA的对比。 今天来说下Oracle的DG和MySQL的方案对比,相比来说,可能这方面MySQ...

37050
来自专栏程序员互动联盟

数据库常见的图形工具有哪些?

疑惑一 MySQL常用的图形化管理工具有哪些? 现在随着PHP+MySql越来越火,周边相关产品也受到众多人的关注。在PC上修改数据库,查看数据库内容是研发人员...

59690
来自专栏喵了个咪的博客空间

phalapi-进阶篇6(解决大量数据存储数据库分表分库拓展)

#phalapi-进阶篇6(解决大量数据存储数据库分表分库拓展)# ? ##前言## 时隔半个月随着PHP7的推出为PHP打了一瓶兴奋剂,在性能提升了一倍的情况...

37790
来自专栏about云

kafka sql入门

问题导读 1.kafka sql与数据库sql有哪些区别? 2.KSQL有什么作用? 3.KSQL流和表分别什么情况下使用?

29620
来自专栏数据和云

在线重定义生产环境大表分区的惨烈踩雷记录

本文来源于读者投稿,作者在此分享在线重定义生产环境大表分区的惨烈踩雷记录,感谢投稿,欢迎大家投稿分享自己日常中“难忘”的解决过程。

20830
来自专栏Hadoop数据仓库

HAWQ取代传统数仓实践(十四)——事实表技术之累积快照

一、累积快照简介         累积快照事实表用于定义业务过程开始、结束以及期间的可区分的里程碑事件。通常在此类事实表中针对过程中的关键步骤都包含日期外键,并...

50650

扫码关注云+社区

领取腾讯云代金券