编辑说明：《Oracle性能优化与诊断案例精选》出版以来，收到很多读者的来信和评论，我们会通过连载的形式将书中内容公布出来，希望书中内容能够帮助到更多的读者朋友们。 这是我一个运营商客户的案例。其现象大致是某天凌晨某RAC节点实例被重启了，通过如下的告警日志我们可以发现RAC集群的节点2实例被强行终止掉了，以下是详细的日志信息。 从上面的数据库告警日志来看，数据库实例2从2:03就开始报错ORA-00600 [KGHLKREM1]，一直持续到2:39，lmd0进程开始报同样的错误，紧接着LMD0进程强行把数据库实例2终止掉了。 如果参照上述ORA-00600错误，直接搜索Oracle MOS，可能会搜到以下结果，Bug 14193240 : LMS SIGNALED ORA-600[KGHLKREM1] DURING BEEHIVE LOAD。但是这个Bug很容易被排除，根据系统监控就可以直接排除。在故障期间系统负载是非常低的。 这里我们需要注意，从告警日志来看，从2:03就开始报错，然而直到lmd0进程报错时，实例才被其终止掉。不难看出，数据库节点2的lmd0报错才是问题的关键。那么我们首先来分析数据库节点2的lmd0 进程的trace文件内容。 ...省略部分内容... 从上面的信息来看，确实heap存在错误的情况。根据这个错误堆栈可以在MOS上再次匹配，这时找到文档号1070812.1的文章：ORA-600 [KGHLKREM1] On Linux Using Parameter drop_cache On hugepagesConfiguration，此次故障跟描述基本上一致。 其中地址[0x679000020]后面的内容也均为0，跟文档描述一样。其次，文章中提到使用了linux 内存释放机制以及同时启用了hugepage配置。根据文档描述，这应该是Linux Bug。通过检查对比2个节点配置，发现节点2的配置确实不同。 --节点1
--节点2
当drop_caches 设置为3时，会触发linux的内存清理回收机制，可能出现内存错误的情况。然而我们检查配置发现并没有修改。 既然没有修改配置文件，那么为什么会出现这种情况呢？ 我怀疑是有人手工执行了echo3 |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
