【云和恩墨，提供7*24最专业的数据恢复（Oracle，MySQL，SQL server）服务，致力于为您的数据库系统做最后一道安全防护！服务热线：010-59007017-7030】数据恢复|数据库运维|性能优化|安全保障|Oracle培训|MySQL培训

编辑手记：linux 文件系统的cache分为2种：page cache和 buffer cache.在RAC环境中，不同节点间的设置不合理很可能会触发操作系统bug，而引起数据库宕机。今天我们拣选Roger的案例与大家共享。

这是1个月之前处理的某个客户的案例，现象大致是某天凌晨某RAC节点实例被重启了，通过如下是alert log我们可以发现RAC集群的节点2实例被强行终止掉了，如下是详细的告警日志信息：

从上面的日志来看,在2：03分就开始报错ORA-00600,一直持续到2:39分,lmd0进程开始报同样的错误；然后接着LMD0进程强行把数据库实例终止掉了。。直接搜索Oracle MOS,看上去有点类似这个bug，不过很容易就可以排除。
Bug 14193240 : LMS SIGNALED ORA-600[KGHLKREM1] DURING BEEHIVE LOAD 从日志看，2:03分就开始报错，然而直到lmd0报错时，实例才被终止掉，也就是说lmd0报错才是问题的关键。那么我们首先来分析下lmd0 进程的trace文件内容，如下所示：

从上面的信息来看，确实是heap 存在错误的情况。根据oracle mos文档ORA-600 [KGHLKREM1] On Linux Using Parameter drop_cache On hugepages Configuration (1070812.1) 的描述来看，此次故障跟文档描述基本上一致，如下：

其中地址[0x679000020] 后面的内容也均为0，跟文档描述一样，其次，文章中提到使用了linux 内存释放机制以及同时启用了hugepage配置。
根据文档描述，这应该是Linux bug。通过检查对比2个节点配置，发现节点2的配置确实不同：

当drop_caches 设置为3，会触发linux的内存清理回收机制，可能出现内存错误的情况；然而我们检查配置发现并没有修改：

因此，我认为是之前人为进行了echo 3 > /proc/sys/vm/drop_caches  操作来强制释放内存导致。    通过分析发现只能查看到最近几分钟的操作记录，如下

?
1
2
3
4
5
6
7
8
9

看操作记录确实发现了操作，那么同时我检查操作系统日志也发现了一些蛛丝马迹，如下：

可以看到也确实出现了drop_cache的相关操作。大家注意看上面红色的地方，提到了是执行了一个shell脚本，然后还导致一共cpu stuck了，而且也能看出该脚本是在执行回收cache的动作。

我坚持认为客户环境上肯定进行了强制的内存回收，但是客户说他们没有进行任何人为操作，不过经过我检查发现确实有一个crontab脚本。

那么为什么主机上会部署这样的脚本呢？ 我猜想肯定是操作系统的内存使用率看起来很高，通过检查发现确实如此：

检查free memory

我们可以看到128G的物理内存,cache 就占据了88G的样子目前。

linux 文件系统的cache分为2种：page cache和 buffer cache.page cache是用于文件，inode等操作的cache，而buffer cache是用于块设备的操作。从上面的数据来看，我们所看到的free -m 命令中的cached 88552 全是page cache。而实际上该数据库实例的内存分配一共也就40G，且使用的是linux raw。

我们可以看到，整个主机物理内存为128G,而Oracle SGA+pga 才40g，另外将近90G的内存都是fs cache所消耗。完全可以调整linux的参数去释放cache，而不需要使用echo 这种比较暴力的方式；根据Oracle mos的几个文档的描述，推荐设置如下几个参数：
sysctl -w vm.min_free_kbytes=4096000
sysctl -w vm.vfs_cache_pressure=200
sysctl -w vm.swappiness=40   （老版本的linux是设置vm.pagecache参数)

关于linux cache的一些知识请参考：
http://www.ibm.com/developerworks/cn/linux/l-cache/
File System’s Buffer Cache versus Direct I/O (文档 ID 462072.1)

----the  end