oracle数据库内存不足导致查询变慢,Oracle内存过度消耗风险提醒

前言

时间过的真快，技术人生系列·我和数据中心的故事已经来到了第六期，小y又和大家见面了！

小y今天要和大家分享的是一个综合型问题的的分析和解决过程。

解决该类问题，只懂数据库是不够的，还需要掌握比较扎实的操作系统技能。

同时引出了另外一种不太常见形式的优化，内存优化。

由于今天要分享的问题具有普遍性，建议大家可以按照文中方法检查自己的系统中有无类似问题。分享的最后将对该共性的风险进行总结和提示。

另外，近期有不少朋友问，小y所在团队是否可以做一些线下的分享？

确实，如果可以把大家组织起来，哪怕是一个会议室或者一个咖啡厅，除了面对面的技术分享，还可以聊聊人生，兴致来了还可以一起烧烤啤酒，结识更多的朋友，也是人生幸事！

既然大家有兴趣，那我们就开始第一期线下分享吧！

Part 1

问题来了

2015年12月28日，北京。

晚上8点，刚吃完晚饭，电话响起，是一位运营商客户的电话。

“小y,出事了，今天下午17点到18点，xx数据库监听和实例crash，不过现在库已经起来了。这个业务系统很重要，领导非常重视，务必要求查明原因。其他厂商都已经到了，暂时没有查到问题。你们能不能马上派个工程师到现场分析一下？争取今晚就有个结论！”

接到电话后，小y立刻安排兄弟赶往现场。之后还了解到，上周也出现过类似的问题。

环境介绍：

操作系统 AIX 6.1 TL8, 64-bit

数据库 ORACLE 11.2.0.3,2节点RAC

配置：16CPU 50G内存

Part 2

分析过程

过一会儿，收到日志，一下子来了精神，我们先来看看日志，确认下客户提到的数据库crash和监听crash的问题。

确认监听和数据库实例宕的问题

2.1.1

数据库alert.log

1.png (7.42 KB, 下载次数: 41)

2017-7-21 10:43 上传

可以看到：

>>17:42:39，数据库alert日志有关键报错信息，负责GCS的进程LMS的调用有89秒没有得到响应。意味着从17:41:10秒开始，数据库就开始出现问题了。

>>接下来，就来到了18:02:48，直接转到启动数据库的日志，没有数据库停止、被异常终止的日志，这20分钟内alert日志没有任何输出。期间操作系统并没有发生重启现象。

原因初步分析：

导致LMS的调用没有响应的最常见的原因是数据库所在的Lpar的系统资源如内存/CPU出现瓶颈。而通常在操作系统资源紧张的情况下，会伴随着以下表现：

>> CRS作为集群资源管理的进程，在检测资源时可能也会出现超时的情况，从而启动异常处理，例如将资源自动重启

>> RAC节点之间的某些心跳检测得不到响应的情况下，为了恢复整个RAC集群的对外服务能力，11g后将优先启动MemberKill,即终止数据库实例的方式尝试恢复，如果memberKill无法解决问题，则升级为NodeKill,即重启OS的方式来恢复整个集群的对外服务能力

接下来检查CRSD进程的日志

从中可以看到，包括VIP/监听等在内的资源，由于OS资源紧张的问题，检测超时，继而启动了异常处理。

2.1.2

节点1 CRSD.LOG

从下图可以看到：

17:42:30,CRSD检测VIP的健康情况，10秒后，检测超时，于是状态变UNKNOWN(然后被CRSD尝试重启)