如何在五分钟内快速反馈Oracle数据库问题-阿里云开发者社区

开发者社区> 努力酱> 正文

如何在五分钟内快速反馈Oracle数据库问题

简介:
+关注继续查看

我们团队内部有一个问题升级机制,即任何故障(业务反馈问题、hang、或者crash等)必须立即升级给直接主管,并在10分钟之内第二次反馈情况。这要求一线团队对基本问题的侦查方法十分了解,并且熟悉环境。当然,绝大部分的客户环境都部署了OSWatcher之类的工具(这些工具我在之前发表的文章《Oracle DBA应该掌握的9个免费工具》中谈到过,详见文末的往期作品链接),所以效率会非常高。但有些客户环境由于条件限制部署不了这些工具。这种情况下,我们怎样才能在10分钟内及时反馈数据库情况呢?


对于一个大团队来说,及时反馈问题,比傻乎乎的去分析更重要。


节假日期间,如果你碰巧分到值班的活,那就更应该读一读这篇文章。


你正一边忙着搞MySQL数据库,一边滑动手机抢节日红包。背后的师父喊了,猴儿,你看看200.123怎么了?


你赶紧把MySQL数据库上正在敲的命令撤回,关闭窗口。(不要小看这个动作,随时关闭不用的窗口,是减少人为失误的法宝之一。)


通过堡垒机你登录到123。


第一步 先看看系统资源使用情况


20160330043827360.jpg


没有换页,运行队列没问题,等待队列平时只有60左右,今天接近200。


CPU空闲率降低了10个百分点,IOwait增加了三五个点。


第二步 检查日志有没有错误

 


单机系统,先检查alert日志,如果里面有错误,再看相应的trace日志。


20160330043835943.jpg


确认日志里是否有报错。


如下的日志文件中,我们可以看到,没有报错。同时我们还能看到,存在联机日志写的时候,cannot allocate新日志的情况,如果经常发生,考虑增加日志组,或者加大日志文件大小。


20160330043843117.jpg

第三步 查等待事件

 

其实也可以把查等待放在第二步来做。


20160330043850168.jpg
 

看到这么多等待事件,千万别慌。除了排除所谓的“空闲类等待事件”之外,还要注意,有的等待事件并不是很值得关注。


就这里显示的内容来说,我们能看到:


  • 有一个锁等待,属于正常范围。

  • 4个scattered read

  • 100多个sequential read,稍微有点多。

  • 800多个read by other session,多的有点离谱了。


这种情况发生了,就要抓大放小,重点关注800多个这个事件相关的SQL语句、应用程序或终端。


20160330043915964.jpg


并没有特殊的终端连接特别异常。


20160330043937245.jpg


我们看到所有这些连接也并非都是同一个SQL_ID执行的。


不过别急,进一步把一个个SQL ID解析成SQL语句后,我们发现,这800多个等待“read by other session”的会话,其实是2个语句:


20160330043946868.jpg



20160330043953519.jpg


它们的共同点是都对其中一个表进行查询。


通过执行awrsqrpt.sql语句来进一步分析单个sql_id,我们发现,执行频率很高:


20160330044001631.jpg

 


相对于近亿条记录的表关联查询来说,每次执行所消耗的IO,是正常的。


表和索引的统计信息都是一天前刚搜集的。实际记录数与统计信息搜集的相比,差异在1%以内,SQL的执行计划没有发生变化。


因此,猴儿反馈给师父,数据库本身没有问题。


某业务执行频率异常导致业务慢(从sqlrpt的信息来看,执行一个查询要耗时3分多钟),CPU利用率比平时高10个点左右。


执行频率有多高呢,1小时执行了上百万次。这个业务正常一小时执行上万次就了不起了。


整个CASE,从师父发出指令,到猴儿反馈信息给师父,正常应该在5分钟以内。


作为一线的工程师来说,最重要的并非是立即解决问题,而是迅速反馈,让更合适的人介入处理,避免问题蔓延。


然后呢?


然后,如若是应用问题,你应该持续跟进应用改进,直到这个问题最终判定为止,形成知识库文档。


如若是数据库本身有问题,问题流转到了更专业的人手上,但作为问题第一负责人,仍然要跟着学习借鉴别人的问题思路,直到问题解决,形成文档,最后这个问题是一个闭环。


  

知识点延伸

 


1、 read by other session等待事件


  • 这个等待事件是从buffer busy wait这个等待事件剥离出来的。

  • 什么情况会发生这个等待事件呢?


    (1)某个会话正在查询某个表的数据,把这些数据从磁盘里读到高速缓存区中,而其他会话这时如果也在请求相同的数据块。如果响应的数据块还没完全读到缓存中,就会发生这样这个等待事件。


    (2)因为有会话正在读取数据在内存,因此该事件同时会伴随着sequential read或者是scattered read,一般情况不会孤立存在。

  • 通常怎么做?


    (1)由应用侧停止发起异常连接数的业务可能是最好的方式,但不一定能做到。


    (2)在应用侧的授权下,kill掉相应会话是可选的方式。

2、 单机数据库,如果这些查完都没有问题怎么办?


上述检查中,关于主机方面,主要看了CPU、内存使用情况。因此,还可以检查磁盘IO信息(iostat,sar –d等),还可以看看网络怎么样(top/topas,netstat等)。以及操作系统方面的日志信息。


3、如果是Oracle RAC数据库呢?


  • 检查多个实例的情况

  • 同时应该看看CRS的日志

  • 检查ASM的情况,ASM默认的参数偏小 


4、这个case中,有没有可能是SQL本身的问题?


  • 如果不是因为有SQL基线,确定SQL执行计划没变,正常应该确定SQL是否有优化余地。

  • 做一线运维,尽可能去做好所负责的数据库基线管理,并定期更新。这非常有助于快速分析和定位问题。


作者介绍:杨志洪


  • 【DBA+社群】联合发起人

  • 数据管理专家。Oracle ACE、OCM、 SHOUG/ZJOUG核心成员、DAMA会员/CCF会员,译著《Oracle核心技术》。

  • 在Oracle OOW、DTCC及2015Oracle数据库技术大会等全国性技术会议上发表主题分享,并主办了2014Oracle全国技术巡讲。

  • 2015年创立DBA+社群迅速成为全中国最大的涵盖数据架构师、DBA及中间件的专业社群。


本文来自云栖社区合作伙伴"DBAplus",原文发布时间:2016-02-16

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
Spring Boot Admin,贼好使!(8)
Spring Boot Admin,贼好使!(8)
15 0
Spring Boot Admin,贼好使!(5)
Spring Boot Admin,贼好使!(5)
25 0
保姆级教程,终于搞懂脏读、幻读和不可重复读了!(7)
保姆级教程,终于搞懂脏读、幻读和不可重复读了!(7)
17 0
保姆级教程,终于搞懂脏读、幻读和不可重复读了!(9)
保姆级教程,终于搞懂脏读、幻读和不可重复读了!(9)
28 0
查询MySQL字段注释的 5 种方法!(2)
查询MySQL字段注释的 5 种方法!(2)
21 0
保姆级教程,终于搞懂脏读、幻读和不可重复读了!(8)
保姆级教程,终于搞懂脏读、幻读和不可重复读了!(8)
23 0
查询MySQL字段注释的 5 种方法!(5)
查询MySQL字段注释的 5 种方法!(5)
24 0
Spring Boot Admin,贼好使!(3)
Spring Boot Admin,贼好使!(3)
24 0
Spring Boot Admin,贼好使!(4)
Spring Boot Admin,贼好使!(4)
23 0
查询MySQL字段注释的 5 种方法!(3)
查询MySQL字段注释的 5 种方法!(3)
20 0
+关注
287
文章
3
问答
文章排行榜
最热
最新
相关电子书
更多
《2021云上架构与运维峰会演讲合集》
立即下载
《零基础CSS入门教程》
立即下载
《零基础HTML入门教程》
立即下载