ORACLE rac由aix平台迁移至linux平台实例重启分析

作者简介:李飞目前就职过北京海天起点技术服务股份有限公司,提供Oracle内蒙区域技术支持;超过十年的ORACLE SUPPORT从业经验。ORACLE 10g OCP,ORACLE 11g OCP,ORACLE 11g OCM。擅长Oracle数据库各种场景问题处理,熟悉Oracle的调优,排错,实施等。主要服务:金融,通信,政府等客户。

经项目组反应情况,数据库近期完成迁移后,总是无故重启,近期发生频发,故寻找原因。

环境说明:

数据库版本:oracle 11.2.0.4

系统版本:    redhat 6.8

内       存:   189G

s w a p   :   72G(16G以上的空间基本上不会被使用)

应用类型:   OLAP

sga/pga:   72G/19G

问题分析:

查看alert日志

查看相关trace文件

并没有详细说出错误原因,根据错误号和trace可能与内存和资源使用有关

查看系统报错

通过截图发现oracle是被系统杀死了,出现这个情况都是因为内存或资源要耗尽,系统要强制kill,SWAP空间被用满,而且只是用最多16G空间,因此设置72G的SWAP不合理。

初步怀疑是由于某条执行效果差的SQL语句占用了大量的内存,但是查询这几天的AWR每日巡检报告,数据库运行很清闲,AAS数值一直保持在0.5以下,不应该是问题SQL语句造成。

内存和swap总共为261G可用空间,那个时间段并非业务高峰,且迁移前业务环境并没有出现宕库情况,这说明内存是满足现在这个情况

查询sysctl.conf

系统设置了开启大页,并设置Hugepages为36102页,每页大小默认是2M,因此是72G的Hugepages。

查看内存信息

Hugepage默认值43页,但都是FREE状态没有使用。

发现限制最大可加锁内存大小为64K,远远小于72G。

并且在ulimit里面并未对Hugepages进行设定。

也就是说明,oracle数据库设置了Hugepages,但并未使用。

HugePage设置后,即使不使用它,所占的内存空间也不能被其他进程使用,并且HugePage是pin在物理内存空间的,不会被swap,也就意味着数据库设置使用的92G物理内存,其实只有20G(92G-72G=117G)可用,故才耗尽swap。

解决方法:

  • 停止oracle数据库
  • 启动oracle前先执行

 ulimit -l unlimited或写到/etc/profile中后source。

  • 修改/etc/security/limits.conf增加:

上述修改目的:调整内存锁的限制,使得大页被oracle数据库使用。

参考mos文章:How to reduce Page Allocation Failure events on Exadata environments. (文档 ID 1605814.1)

未经允许不得转载:Oracle一体机用户组 » ORACLE rac由aix平台迁移至linux平台实例重启分析

相关推荐