一条看似平常的报警邮件所做的分析(r8笔记第9天)

今天留意到一封报警邮件。内容如下:

ZABBIX-监控系统: 
------------------------------------
报警内容: CPU utilization is too high
------------------------------------
报警级别: PROBLEM
------------------------------------
监控项目: CPU idle time:45.92 % 
------------------------------------ 
报警时间:2016.02.14-15:45:10

这个问题发生的时间很短,持续没多长时间就自动恢复了,但是还是引起了我的注意。 登录到环境之后,查看系统的整体负载情况。发现在问题时间段里,确实CPU使用率较高。 03:20:01 PM CPU %user %nice %system %iowait %steal %idle 03:30:01 PM all 0.37 0.00 0.22 0.17 0.00 99.25 03:40:01 PM all 18.03 0.00 0.19 0.18 0.00 81.60 03:50:01 PM all 50.94 0.00 0.13 0.17 0.00 48.75 04:00:01 PM all 75.45 0.00 0.15 0.15 0.00 24.24 04:10:01 PM all 64.55 0.00 2.23 0.25 0.00 32.97 04:20:01 PM all 57.27 0.00 0.91 0.28 0.00 41.54 对于这种情况,首先通过crontab排除了例行的维护任务,从而可以初步推断系统级没有特定的任务。 这个负载很可能来自于数据库层面,那么对于数据库层面的分析如下。 这个数据库实例的DB time,抖动不够明显。 BEGIN_SNAP END_SNAP SNAPDATE DURATION_MINS DBTIME ---------- ---------- -------------------- ------------- ---------- 18981 18982 14 Feb 2016 11:00 60 4 18982 18983 14 Feb 2016 12:00 60 4 18983 18984 14 Feb 2016 13:00 60 4 18984 18985 14 Feb 2016 14:00 60 14 18985 18986 14 Feb 2016 15:00 60 8 18986 18987 14 Feb 2016 16:00 60 32 18987 18988 14 Feb 2016 17:00 59 6 18988 18988 14 Feb 2016 18:00 60 0 但是逻辑读在下午的时间段里,确实出现了一个较大的抖动。

所以可以基本断定这个问题来自数据库层面,而且很可能来自sql语句。 当然了我也确实比较懒,对于这种问题,懒得生成awr了,直接用一个脚本来挖掘问题时间段内的快照数据。 $ sh showsnapsql.sh 18987 Current Instance ~~~~~~~~~~~~~~~~ DBID DB_NAME INST_NUM INST_NAME ---------- --------------------------- ---------- ------------------------------------------------ 1825607545 TESTDB 1 testdb SNAP_ID SQL_ID EXECUTIONS_DELTA ELAPSED_TI PER_TOTAL ---------- --------------------------------------- ---------------- ---------- ---------- 18987 c1mddahtwj7y1 1051 1388s 83% 18987 cr32qwhysqkn9 65364 112s 6% 18987 fgwt4xab7fhgt 138553 40s 2% 18987 7kt7x4s5ps0hu 836 38s 2% 18987 520mkxqpf15q8 410907 16s 1% 第一条语句毫无疑问是值得注意的部分。语句情况如下: SQL_FULLTEXT ---------------------------------------------------------------------------------------------------- UPDATE TEST_DEAL_INFO SET FLAG='0',SMS_SEND_TIME=SYSDATE WHERE ID=:1 但是查看执行计划,发现走了全表扫描。 --------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------------- | 0 | UPDATE STATEMENT | | | | 70961 (100)| | | 1 | UPDATE | TEST_DEAL_INFO | | | | | |* 2 | TABLE ACCESS FULL| TEST_DEAL_INFO | 1 | 10 | 70961 (1)| 00:14:12 | --------------------------------------------------------------------------------------- 那么这个问题就很明显了。需要一个相关的索引,在简单分析相关的语句之后,发现根据表的字段情况和使用的sql情况,目前只需要在id列添加索引即可。 当然简单添加之后,问题就会引刃而解。 不过在解决之后简单看了下这个环境还是不经意发现了一些问题,既然添加了索引,对应的表空间情况如下: Tablespace Total MB Free MB Used MB ----------------------- ---------- ----------- - MEG_DATA 100 98 2 MEG_INDEX 100 98 2 RECALL_DATA 77,774 28,928 48,846 RECALL_INDEX 98,444 28,889 69,555 SYSAUX 1,120 75 1,045 SYSTEM 770 2 768 TEMP 15,187 15,187 0 UNDOTBS1 3,810 3,770 40 USERS 154 8 145 有没有发现什么问题? 问题之一就是这个表空间的使用率有些奇怪,怎么索引所在的表空间使用率比数据还高了。如果是按照这种情况下,会有大量的索引存在,过多的索引,本身对于表 的数据维护代价就比较高,而且这种索引比较多的情况很可能都是单键值索引,是否可以考虑复合索引。 带着疑问查看了一下索引的使用情况,奇怪的是没有发现什么问题,但是数据有一部分对不上,最后使用下面的语句来定位,发现了另外一个问题。 SQL> select owner,segment_type,sum(bytes/1024/1024) size_MB from dba_segments where tablespace_name='RECALL_INDEX' group by owner,segment_type; OWNER SEGMENT_TYPE SIZE_MB -------------------- -------------------- ---------- SYS INDEX 48021.4375 TEST INDEX 21528.3125 这个索引表空间是由SYS和TEST两个用户共同使用,SYS竟然使用了近48G的空间,这个确实有些奇怪。为什么呢? 进一步分析发现,有一个表存在两个索引。每个索引大概是24G左右,表里本身就含有大量的历史数据。 INDEX_NAME TABLE_NAME ----------------------------- ------------------------- RFR_CN_MASTER_INDEX TEST_TIMELY_FOX FRF_LOGIN_TIME_INDEX TEST_TIMELY_FOX 而且表的段大小是15G左右,但是索引大小已经远大于数据段了,所以这部分索引需要考虑重建。 而且可以进一步和开发的同学确实,是否需要保留很早以前的索引。 在这个基础上,其实也可以进一步分析,写个脚本找出这类问题数据段,索引段来。

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

原文发表时间:2016-02-14

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Java后端技术栈

在一个千万级的数据库查寻中,如何提高查询效率?

A. 对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引。

1113
来自专栏漫漫全栈路

Oracle数据库项目——MC服务器管理系统

数据库设计内容,分为:系统功能说明,数据库分析与设计,数据库实现。本数据库系统提供的功能用于项目MC-Servers-Web,详情内容参见MC-Service...

7244
来自专栏跟着阿笨一起玩NET

SQL语句使用总结(一)

1>. FROM 2>. WHERE 3>. GROUP BY 4>. HAVING 5>. SELECT 6>. ORDER BY

561
来自专栏沃趣科技

会话和锁信息查询视图 | 全方位认识 sys 系统库

在上一篇《等待事件统计视图 | 全方位认识 sys 系统库》中,我们介绍了sys 系统库中的等待事件统计视图,本期的内容先给大家介绍会话信息和锁等待信息查询视图...

1410
来自专栏扎心了老铁

Elasticsearch-sql 用SQL查询Elasticsearch

Elasticsearch的查询语言(DSL)真是不好写,偏偏查询的功能千奇百怪,filter/query/match/agg/geo各种各样,不管你是通过封装...

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

MySQL中使用pt-osc的一些小结

Percona的pt-osc工具算是DBA的一个福利工具。想想一个数据量有些大的表,在上面做DDL操作真是一种煎熬,我们也基本理解了这是一种空间换时间的...

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

undo retention的思考(一)

最近有个网友咨询我一个问题,是关于undo_retention的,对于这个参数没有过多关注,只是知道需要设置undo_retention搭配使用undotabl...

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

一个SQL性能问题的优化探索(一)(r11笔记第33天)

今天同事问我一个问题,看起来比较常规,但是仔细分析了一圈,发现实在是有些晕,我隐隐感觉这是一个bug,但是有感觉问题还有很多需要确认和理解的细节。 同事...

3519
来自专栏Java面试通关手册

Mysql锁机制简单了解一下

Java面试通关手册(Java学习指南,欢迎Star,会一直完善下去,欢迎建议和指导):https://github.com/Snailclimb/Java_G...

16711
来自专栏Hadoop实操

如何使用Phoenix在CDH的HBase中创建二级索引

3312

扫码关注云+社区

领取腾讯云代金券