数据库无响应问题的紧急处理和分析 (r10笔记第42天)

黄金周里处理了一起紧急的问题,在外面幸亏有同事帮忙协助,等我赶回家去,赶紧继续处理。 首先问题是在晚饭时间左右开始发生,但是过了没多久又恢复了,所以这个问题暂时就没有引起太多关注,但是后面发现问题开始反复,而且数据库的负载开始急剧提升,后面也开始收到了不少的报警信息,一下子问题就变得紧急起来。 环境是10.2.0.3的数据库,在Solaris 10环境中。 当时的DB time情况如下,从负载来看,压力是非常大的,数据库几度出现了无响应的情况,这对于核心业务而言还是影响很大的。

这是一套很稳定的数据库,很稳定的说法主要是很少有变更,而且多年来系统一直表现稳定。 查看资源的使用情况如下,可以看到在问题发生时段,没有大批量的事务,没有大批量的资源消耗。

那看看等待事件,发现都是和锁相关的。根据wait class的指示是和并发相关的。如果看到如此的情况,而且很紧急,想必是很纠结的。

我们来看看问题时间段的SQL情况,看看是否因为SQL问题导致了严重的等待和锁争用。

这个地方就有一些误区,看SQL语句,默认会定位到top的几个SQL语句,细看所占的比例也蛮高,所以同事的注意力就集中在了SQL优化上,但是查看语句是一个很简单的查询,而且也是走了唯一性索引,那问题的症结在哪里呢。 可以从awrsqrpt的报告看出端倪,那就是存在大量的等待。其实执行的时间还是很短的。

那问题的原因怎么解释,到底在等待什么呢。这个需要对整个系统的架构和技术细节需要有一些了解。 首先现在的网卡使用了逻辑IP,如下所示。服务器存在两个物理网卡,现在对外使用的是一个网卡1(e1000g0)上绑定的一个逻辑IP,当然这么做也是有一些历史原因的。

而对系统的架构有一定的了解,会发现其实和另外一个数据库有一些关联。怎么解释呢,就是在问题发生的时候,另外一台数据库的负载也急剧提升。 我直接到另外一台服务器上查看发现存在大量的活跃会话,而在等待的就是下面的这样一个语句。看起来也没有什么问题,如果查看执行计划就会发现其实另外一台服务器中是使用了DB link来访问现在出问题的数据库。

update enthralcert set logout_date = sysdate, status = 0 where cert_number in (select cert_number from enthralcn where cn = lower(:cn))

其实问题的原因也无须掉书袋,经过快速定位和分析,就是因为这样的DB link,听起来好像也不大合理,怎么会有这样的问题呢,问题服务器上存在着大量的数据库连接,会直接更新本地表,间接通过db link来引用其他的表,在业务稳定的时候没有差别,在一定程度上和设置的逻辑IP有一些关系,网络一旦发生抖动和不稳定,就会把这个网络的延迟放大,传 播,大批量的会话开始阻塞,等待,就会变成活跃会话,数据库负载急剧提升,如果应用端持续调用都存在等待,系统资源就会逐渐耗尽,导致出现无响应的情况,这种问题的解决方案目前是采用了折中的一个方案,既然通过db link,我们把一部分的网络压力放在物理网卡2上。在tnsnames.ora中修改对应的IP和端口即可。至少在一定程度上能够极大缓解问题,后续会建议从应用层面,系统层面来持续改进。 当然处理问题的过程中,发现有大量的等待,首要的等待就是library cache的争用,这个可以从下面的图示看出。可以看到shared pool确实很紧张,而且同时buffer cache其实使用一点都不紧张,我们重置一下SGA的组件,这个地方需要提醒一下,在这种情况下需要评估影响范围。

我印象中是存在一个bug,会导致实例直接宕掉,评估了之后决定先改进一下。alter system set shared_pool=xxx运行下去,实例还真宕掉了。

Errors in file /U03/app/oracle/admin/test/bdump/test_mman_944.trc:
 ORA-00600: internal error code, arguments: [kmgs_pre_process_request_6], [1],[107], [18], [3], [0xA7024DB68], [], []
 Mon Oct 3 22:45:17 2016
 MMAN: terminating instance due to error 822

赶紧把实例启动起来,因为有应用重连机制,所以问题的影响还在可控范围,火速调整shared_pool的大小,重启后,问题就得到了一定的缓解,当然问题的根本还是设计不当采用了大量的DB link的方式,把问题的影响放大。需要引以为戒。

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

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

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏VMCloud

【腾讯云的1001种玩法】在腾讯云上创建您的SQL Server 故障转移集群 (1)

在国内公有云厂商上搭建一套SQL Cluster的难度相信做Windows的童鞋都会很清楚,并非它的搭建有多少难度,只是很多细节需要注意。所以,今天我就来讲讲如...

5.4K2
来自专栏程序员互动联盟

【专业技术第四讲】如何检测浏览器的快慢?

现在做浏览器的大概有下面几个方向吧 1. 从事浏览器外壳的工作,开发基于浏览器的各种应用和扩展; 2. 做浏览器内核优化的,大概又分为几个部分: a. 渲染模块...

34312
来自专栏IT技术精选文摘

如何实现系统的可扩展性和高可用性

概述 可扩展性,高可用性和性能 可扩展性,高可用性,性能和关键任务这些术语对不同组织或组织内的不同部门来说意味着不同的事情。它们经常被互换,造成混乱,导致管理...

79710
来自专栏CSDN技术头条

Hybris平台Web架构模式演变:前后端分离

深度技术文章,第一时间送达! “前后端分离”显然已不是什么新鲜的话题,表面上看是一场架构模式的变革,但实质上是为了解决以往传统的服务端MVC设计模式的一些诟病和...

4846
来自专栏JAVA高级架构

多研究些架构,少谈些框架(3)-- 微服务和事件驱动

接上篇,我们采用了领域驱动的开发方式,使用了充血模型,享受了他的好处,但是也不得不面对他带来的弊端。这个弊端在分布式的微服务架构下面又被放大。 事务一致性 事务...

3434
来自专栏IT笔记

微服务架构实践之邮件通知系统改造

拆分背景 随着平台业务增长,功能耦合度越来越高,部署周期变长,代码样式混乱、新人入手复杂、独立功能影响系统的稳定性等等,等等,等等问题。 以邮件通知为案例对服务...

3836

比较服务网格体系结构

如果你正在围绕微服务构建您的软件和团队,那么你应该正在寻找更快迭代和灵活扩展的方法。服务网格可以帮助你在保持(或增强)可见性和控制的同时实现这一点。在这篇博客中...

3546
来自专栏JAVA高级架构

微服务架构选型实践

背景 随着公司一年多的成长,我们已经开发了数十个项目了,后台有 JAVA 的有 PHP 的,为了更好地提升开发与管理效率,各技术大牛小牛们时常进行激烈的 PK,...

4816
来自专栏程序员的SOD蜜

探寻背后的机制化繁为简:网站程序升级不过是文件同步

苹果落到地上而不是天上,这是重力的作用; 树叶从树枝上飘落的样子谁也无法预测,这是混沌过程; 热恋中的恋人总是难分难舍,这是荷尔蒙等激素作用于下丘脑的结果; 。...

2245
来自专栏小白课代表

集中式播放,给你更好的听歌体验。

随着音乐正版化的推进,想要在单一的平台听到想听的所有歌曲越来越困难,正版化是好事,但对用户来说,却绝对算不上是方便。虾米音乐、QQ音乐、网易云音乐、豆瓣音乐等等...

882

扫码关注云+社区