远程协助解决重建索引的危机问题 (r8笔记第80天)

最近在工作忙碌之余也帮几位网友查看了几个问题,有一个问题让我印象挺深,其实也可以分享出来作为一些参考,问题之外还是有一些值得借鉴的地方。 首先是在周末的一个晚上,白天已经比较累了,大概在晚上11点左右,就准备收拾收拾睡觉了,但是突然qq闪动起来,有一个网友发消息给我,在反复问我,在不在不?看起来还挺着急。 于是我就带着试探的口吻来问他,他说刚刚做了一个操作,系统现在的负载很高,想让我帮忙看看。 然后他就在qq那头给我焦急的解释,当时听了的大体感觉是他创建了一个索引,但是执行了19分钟还没有反应,现在的系统负载很高,希望我能够给点意见。 当我问系统负载有多高的时候,看到的截图如下:

通过这个看不到系统负载很高,所以我就想他要了最新的ash,awr报告,因为他手头刚好收集了ash报告,所以就直接发给我了。 top等待事件为:

Event

% Event

P1 Value, P2 Value, P3 Value

% Activity

Parameter 1

resmgr:cpu quantum

67.19

"3","0","0"

53.69

location

"2","0","0"

13.33

direct path read

13.54

"15","115072","128"

0.02

file number

read by other session

2.06

"15","481314","1"

0.06

file#

db file sequential read

1.11

"2","114340","1"

0.00

file#

对于第一个等待事件还真比较陌生,不过ash报告的好处是这些信息得来都不费功夫。top1的sql已经很清楚的说明了这些等待事件的归属。

SQL ID

% Activity

Event

% Event

Top Row Source

% RwSrc

fjyagwts516j8

75.71

resmgr:cpu quantum

55.01

TABLE ACCESS - FULL

55.01

direct path read

12.03

TABLE ACCESS - FULL

12.03

CPU + Wait for CPU

8.64

TABLE ACCESS - FULL

8.64

所以这个问题看起来是由于全表扫描导致的。查看了执行计划,我问他对于这个表的全表扫描,其实可以考虑添加索引来缓解。 他说刚试过了,就是重建了索引,等了19分钟没反应,所以就取消了。 等等,他说的是重建,而不是新建,经过确认,他说是重建索引,相关的一个表是分区表,之前是存在全局索引,后来想改用本地索引,但是删除快,要添加就难了。 而他在等待了19分钟之后还没有任何反应就有些慌了,不知道该怎么办,这是一个线上环境,情况还是比较紧急的。 这个时候我已经不打算早点休息了,于是就准备远程协助,看看更多的问题信息,方便诊断。 这是一套11gR2的rac环境,简单查看了一些系统情况,发现CPU使用率到到了90%以上,iowait都在30%以上,已经是一个比较严重的情况 了,而且查看session的使用情况,发现里面竟然有400多个active的session,而大部分的session都在同一条语句上卡住了,就是 刚刚看到的sql(sql_id fjyagwts516j8),队友这种情况,一种比较省事的办法就是停掉前端 应用,马上创建索引来缓解,查看有些sql语句,执行时间竟然已经达到了1个半小时,而后面还有一大堆的session被阻塞,这个时候来看,情况确实也 比较危急,而且rac环境中,两个阶段的iowait都极高,如此下去,很可能导致严重的IO问题,后果不堪设想。 我让他提供了准备的脚本,把需要执行的创建语句发给我,简单评估一下,然后就是尝试重建索引了。 当然这类操作,其实还是有一些技巧可循,本来想尝试index的online,但是发现里面都是大量的读请求,本身使用online还是有一些限制,在正 常的情况下创建,发现持续时间要高很多,而这些信息都可以完全通过v$session中绑定对应的sql_id来得到一些信息,如果不加并行,整体的索引 创建时间预估是1个小时40分钟,这个效率显然是不可接受的,现在每耽误一些时间,系统的负载和出现故障的概率就会高一些。所以看到了相关的执行计划,还 是不能接受,于是简单整理一下思绪,强制开启了会话级的并行ddl,配合查到的执行计划,根据预估需要14分钟,但是我明显感觉会晚一些,因为目前的系统 资源还是比较紧俏,所以预估时间可能要长一些,比如20分钟到30分钟的样子。 在得到了这类信息之后,就开始密切关注v$session中的数据变化情况,并行进程确实得到了启用,而且查看执行的情况还是在计划之中,到了14分钟,我安慰他说,目前系统的资源使用率较高,会有适当的延迟,应该会很快完成,需要等待一下。 又过了近10分钟,这个操作才终于顺利的完成了,我心里终于松了一口气,看看表,已经用了近半个小时的时间看问题,看来还是有一些收获。 马上查看v$session中的信息,发现那些持久运行的会话依然存在,对于这种情况和这位网友确认,他还不敢去强制停应用,或者杀掉那些会话,不过从新 进入的sql情况可以看出,性能确实是得到了改善,所以我也就安慰他,这个问题已经告一段落,剩下的事情就是等待哪些被卡住的语句顺利执行完了,因为系统 负载降低了不少,所以这个过程相对要快一些了。 在简单交代之后就去休息了,在第二天早上向他确认问题情况,他说现在一切都正常了,哪些活跃的会话连接都得到了释放。 对于这个问题,其实如果明白了其中的原委,可以看出其实处理方式还是很肯定的,需要借助索引来大幅度改善性能,但是创建索引还是最好评估一下,如果没有任 何的参考,那种大海里捞针的感觉着实不好受,无法评估这个操作的时长和影响范围,在具体实施操作的时候就会心虚很多。但是一旦你明白了问题的边界,就可以 很快调整自己的焦躁状态,哪些事情是紧急的需要马上处理,哪些是可能的问题原因需要重点关注,这些准备工作和操作都会一目了然。而对于这个问题的更多启 示,就是不要低估任何风险,这位网友说当时看后台也没有多少的session于是就想修正一些索引的情况,没想到画蛇添足了。

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

原文发表时间:2016-04-25

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏腾讯大讲堂的专栏

数据库schema设计与优化

1、 前言 对于数据库而言,在日常开发中我们主要的关注点有两块,一个是schema的结构设计,另一个就是索引的优化,这两块是影响我们最终系统结构和性能的关键部分...

3706
来自专栏IT派

520特别版Python实战:教你用微信每天给TA说晚安

导读:今天就是520,不知你是否已经准备好要表白的话语。为了助力你撩妹成功,大数据今天也提前备了点干货——教你用Python每天给妹纸发晚安。

1831
来自专栏腾讯大数据的专栏

数据库schema设计与优化

1、 前言 对于数据库而言,在日常开发中我们主要的关注点有两块,一个是schema的结构设计,另一个就是索引的优化,这两块是影响我们最终系统结构和性能的关键部分...

2325
来自专栏IMWeb前端团队

Vue2 全家桶仿 微信App 项目,支持多人在线聊天和机器人聊天

前言 这个项目是利用工作之余写的一个模仿微信app的单页面应用,整个项目包含27个页面,涉及实时群聊,机器人聊天,同学录,朋友圈等等,后续页面还是开发中。写这个...

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

MySQL DBA工作突围的一个入口-慢日志

在MySQL中,对于性能问题诊断,最开始的时候总是感觉有些束手无策,如果一个人问你,MySQL数据库响应慢了,该怎么办,如果数据库服务器CPU 100%了该怎么...

1362
来自专栏腾讯云数据库(TencentDB)

腾讯云数据库内核揭秘 TXSQL Internals @2018

2018年10月13日ACMUG南京站,来自腾讯技术工程事业群TEG基础架构部数据库内核团队专家工程师王少华,做了主题为「TXSQL Internals@201...

2063
来自专栏华章科技

【一文打尽】SQL 数据分析常用语句.....收藏

• 1 基础查询 • 2 字符串\数字\日期时间 • 3 聚合数据查询 • 4 子查询 • 5 联接\组合查询 • 6 高级查询 • 7 更新数据

831
来自专栏大数据学习笔记

Hadoop基础教程-第10章 HBase:Hadoop数据库(10.1 NoSQL介绍)(草稿)

第10章 HBase:Hadoop数据库 10.1 NoSQL介绍 10.1.1 NoSQL简介 随着互联网技术(互联网+,物联网)发展,特别是大数据时代到来,...

2219
来自专栏java一日一条

SQL vs NoSQL:如何选择?

在前一篇文章中,我们讨论了 SQL 与 NoSQL 数据库之间基本的区别。接下来,我们我们将应用我们在特定场景中的知识来确定最佳的选择。

982
来自专栏CSDN技术头条

盘点一下影响MySQL性能的因素

既然要优化数据库,我们就首先要知道,优化的是什么,或者说:什么因素影响了数据库的性能。

1304

扫码关注云+社区

领取腾讯云代金券