数据库负载急剧提高的应急处理(二) (r9笔记第55天)

对于之前碰到的一个数据库负载急剧提升的问题,做了应急处理之后,我们需要再冷静下来,来看看是哪些地方出现了问题,还需要哪些改进。 首先第一个问题就是为什么会突然负载提高,如果感觉,应该是业务层面出现了一些变化吧。当然没有数据,日志都是猜测。 我从监控中拿到了Zabbix监控的部分数据,发现在指定的时间点突然多了300多个进程。 而在数据库的会话层面没有发现任何的抖动,这一点就很难解释的通了。 系统级不会平白无故出现300多个进程,这些进程主要是在忙些什么,这些肯定说不通,我查看了问题时间段的报警。发现了这么一封报警信息。

ZABBIX-监控系统: ------------------------------------ 报警内容: Alive xxxx_p ------------------------------------ 报警级别: PROBLEM ------------------------------------ 监控项目: Alive:0 ------------------------------------ 报警时间:2016.07.08-11:16:03 如果是这样的情况就能说清楚了,在问题发生的时间段里,因为系统延迟,orabbix无法从服务端抓取到数据,所以出现了Alive的报警,而那个时间段的数据还是会参考之前的数据,而Zabbix是客户端的形式,在每台服务器上都有一个Agent,这些数据采集还是可以的,尽管延迟,但是还是会同步到服 务端。因为我们是后续查看的历史信息。所以这样一来我们可以推理出来是在数据库层面多了300个多会话。 而在业务层面去解释这个就比较困难了。首先业务层面的反馈是没有异常的调用情况。而系统层面反馈也没有发现特别的日志。这个工作就无形中落到了数据库层 面。大家都希望我能够给出一些解释,能够从数据库层面得到一些分析的结果,毕竟这个问题是出现在数据库端。这让我联想起之前工作中的一个有意思的故事,有 两个系统需要交互,系统会发数据到模块A,然后模块A会同步数据处理到模块B,以此类推,结果模块A的问题,模块A没有错误日志,模块B有错误日志,这下 大家都集中在模块B,然后让他们提供更多的分析和解释,最后发现问题是模块A那边过来的,没有错误日志不证明没错误,在这种多系统交互中就会有很多额外的 沟通成本。 当然这个问题也不是猜测出来的,我来看看数据库端的情况。 首先是SWAP的争用,为什么在问题时间段会突然出现争用很高的情况,之前没有吗,实际情况是之前也有的,但是不够明显,那问题出现之前SWAP情况怎么样呢。查看数据库日志发现了下面的一段。这么一段日志还是很有说服力的。 Archived Log entry 11780 added for thread 1 sequence 2581 ID 0xc5819545 dest 1: Fri Jul 08 10:27:49 2016 WARNING: Heavy swapping observed on system in last 5 mins. pct of memory swapped in [3.10%] pct of memory swapped out [0.54%]. Please make sure there is no memory pressure and the SGA and PGA are configured correctly. Look at DBRM trace file for more details. Fri Jul 08 10:28:13 2016 Thread 1 advanced to log sequence 2583 (LGWR switch) Current log# 7 seq# 2583 mem# 0: /U01/app/oracle/fast_recovery_area/STEST032/onlinelog/o1_mf_7_blsdlk1p_.log Fri Jul 08 10:28:13 2016 所以可以充分说明问题集中爆发之前已经有了SWAP的争用情况。而后面的是一个集中的触发点,导致了SWAP的争用更加严重。 那么问题发生时到底是哪些SQL或者数据库层面的操作导致的问题呢,我一看快照,因为是杀掉进程重启,那个时间段刚好没有生成快照,导致了在问题发生时间段的ASH,AWR数据生成,所以只能看到之前一个小时的数据,我们可以作为一个参考。 SQL执行的大体情况如下。

SQL ID

% Activity

Row Source

% RwSrc

Top Event

% Event

SQL Text

ag4b2tb6yxscc

31.29

MERGE

28.83

log file switch completion

24.86

MERGE INTO TEST_OPENPLATFORM_U...

ag4b2tb6yxscc

31.29

TABLE ACCESS - BY INDEX ROWID

1.04

log file switch completion

1.04

134zhd24d9p0y

10.68

** Row Source Not Available **

10.68

log file switch completion

8.88

insert into TEST_USER_INFO (CI...

fw8tvzm9zc48g

6.14

MERGE

5.01

log file switch completion

3.88

MERGE INTO CYUC_USER_LOGIN_TOK...

5nn5amat9hfjm

3.97

TABLE ACCESS - FULL

3.12

CPU + Wait for CPU

3.12

MERGE INTO TEST_OPENPLATFORM_B...

351tx6bsgk1un

3.50

TABLE ACCESS - FULL

3.31

CPU + Wait for CPU

3.31

MERGE INTO TEST_GUEST_USER_INF...

看到这个这个报告,我有些迷惑了,不知道问题的瓶颈在哪里了,因为top 1的SQL本身已经优化过,已经是最优的方式了,执行频率要高一些,而下面的两个标黄的语句仔细查看,是存在性能隐患的语句,但是执行频率相对来说不高,占用的比例也不高。 这样一来问题的分析就有些茫然了。不过这边也在和应用同学做一些确认。让他们帮忙提供一些数据信息。其中部分的信息如下

8点 9点 10点 11点 12点 /test/master 46279 43135 51140 42276 38712 /test/guest 1069 1313 1533 6148 1794 看到这些数据,在问题发生时间点,主要的执行频率还下降了,看起来说明不了问题,不过有一点比较特别的就是/test/guest这个地方,平时的执行频率是1000,而在问题发生时间点是6000多,这个确实是有些特别。 而从之前时间段的AWR可以看出,执行频率还是1000多一些。

Elapsed Time (s)

Executions

Elapsed Time per Exec (s)

%Total

%CPU

%IO

SQL Id

SQL Text

1,521.05

6,464

0.24

22.07

0.72

1.94

ag4b2tb6yxscc

MERGE INTO TEST_OPENPLATFORM_U...

69.84

1,980

0.04

1.01

6.77

8.20

5nn5amat9hfjm

MERGE INTO TEST_OPENPLATFORM_B...

507.27

1,304

0.39

7.36

3.32

0.00

351tx6bsgk1un

MERGE INTO TEST_GUEST_USER_INFO...

有了这些数据支撑,就可以明白问题的大体情况,原本系统的SWAP争用已有,但是最近比较严重,而在问题发生时间段里,问题更加严重,主要就是因为一个本 来负载不是很高的SQL执行频率从1000多提升到了6000多,执行计划中显示是全表扫描,好几百万数据的大表来说还是很明显的问题。而对于这个语句的 优化其实倒不是很难,关键有针对性的分析就尤为重要了。

本文分享自微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2016-07-09

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Hadoop数据仓库

HAWQ技术解析(十二) —— 查询优化

        即便对SELECT等数据库查询语句已经很熟悉了,但HAWQ里的查询有其自己的特点,还是需要研究一下。 一、HAWQ的查询处理流程        ...

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

分分钟搭建MySQL Group Replication测试环境(二)(r12笔记第41天)

之前总结过一篇,分分钟搭建MySQL Group Replication测试环境(r11笔记第82天),但是有一个地方还有待改善,那就是那个脚本仅仅支持s...

40570
来自专栏数据和云

一波三折:一次CPU使用率过高故障分析SQL优化解决过程

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

39630
来自专栏数据和云

【新书连载】诊断Cache buffers chains案例一则

题记:这是某移动运营商在SQL线下审核项目中,协助开发商完善数据库性能的过程。以往开发商遇到此问题总是怀疑是数据库的Bug,试图尝试重启Tuxedo、Weblo...

34980
来自专栏测试开发架构之路

爬取数据入门指南

29930
来自专栏Jerry的SAP技术分享

使用函数BAPISDORDER_GETDETAILEDLIST读取S/4HANA中Sales Order行项目数据

事务码MM03查看物料主数据,如下图所示的行项目数据,包含物料ID,描述信息,数量,单价等等:

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

物化视图中的统计信息导致的查询问题分析和修复 (r7笔记第47天)

今天开发的同事下午反馈给我一个问题,说有操作直接卡住了,听这个描述,感觉很可能是查询慢了。 于是连接到环境中,查看了一下正在执行的sql语句情况,发现下面的语句...

36550
来自专栏数据和云

分而治之:从多列到自动Oracle 12.2 分区新特性抢先一览

何剑敏 Oracle ACS华南区售后团队,首席技术工程师 曾供职于中国联通信息计费部、卓望数码、IBM。现供职于Oracle ACS华南区售后团队,首席技术...

28130
来自专栏数据和云

那些年,我们处理过的SQL问题

作者 | 郑林松,朗新科技股份有限公司数据库技术专家,从业10多年,主要服务移动运营商客户,电力客户,证券客户,制造业客户。精通 Oracle 性能优化,故障诊...

14620
来自专栏PPV课数据科学社区

SQL and R

R平台及编程语言支持浩大的数据科学技术,他拥有几十年的的历史和超过7000个包,这挂在CRAN的包纷杂的让你无法决定从哪里入手。R-Basics和Visua...

328100

扫码关注云+社区

领取腾讯云代金券