PMON (ospid: 26463): terminating the instance due to error 471

今早数据库意外宕库，经查发现是 swap耗尽导致PMON进程终止：oracle开启 HugePage ，却未被oracle使用，而HugePage（128G）设置后，即使不使用它，所占的内存空间也不能被其他进程使用，并且HugePage是pin在物理内存空间的。故导致oracle能用内存较少只能使用swap并耗尽swap，最终被系统层oom-killer。而HugePage未被使用的原因是最大可加锁内存限制远低于低于HugePage，修改ulimit限制重新启动oracle数据库即可。

下面是具体的分析：

【背景说明】

数据库版本：oracle 11.2.0.4
系统版本： CentOS release 6.5
内存： 220G
s w a p ： 31G
应用类型： OLAP
sga/pga ： 128G/50G
【问题分析】
1、查看alert日志

点击( 此处)折叠或打开

Tue Oct 11 04
:00
:11 2016

Archived Log entry 2772 added 
for thread 1 sequence 2922 ID 0x8d1dfa38 dest 1
:


Tue Oct 11 09
:
24
:
23 2016


PMON 
(
ospid
:
 26463
)
:
 terminating the instance due to error 471


Tue Oct 11 09
:
24
:
24 2016


System state dump requested by 
(
instance
=
1
,
 osid
=
26463 
(
PMON
)
)
,
 summary
=
[
abnormal instance termination
]
.


System State dumped to trace file /u01/app/oracle/diag/rdbms/retailstb/biedwshoes/trace/biedwshoes_diag_26479_20161011092424
.
trc


Dumping diagnostic data 
in
 directory
=
[
cdmp_20161011092424
]
,
 requested by 
(
instance
=
1
,
 osid
=
26463 
(
PMON
)
)
,
 summary
=
[
abnormal instance termination
]
.


Instance terminated by PMON
,
 pid 
=
 26463

Tue Oct 11 09
:30
:11 2016

Starting ORACLE instance 
(normal
)

2、查看相关的trace文件
  下面附件为 /u01/app/oracle/diag/rdbms/retailstb/biedwshoes/trace/biedwshoes_diag_26479_20161011092424 . trc
20161011.zip
oracle的日志文件并没有详细说出错误原因，根据错误号和trace可能与内存和资源使用有关
3、查看系统日志
more /var/log/messages
通过截图发现oracle是被系统杀死了，出现这个情况都是因为内存或资源要耗尽，系统要强制kill

4 、查看内存和swap历史使用情况
通过系统日志得出，是因为内存或者资源耗尽导致oracle被kill。查看zabbix对内存和swap监控，发现内存只用了不到90G，但是swap接近临界值，但是内存和swap总共为251G可用空间，那个时间段并非业务高峰且另一个类似的业务环境并没有出现宕库情况，这说明内存是满足现在这个情况。

图1可用内存空间

图2可用swap空间

5、查看 cat /pr oc/meminfo
根据上面的分析，不应该出现如此严重的swap消耗
cat /proc/meminfo

发现此服务器设置了HugePage，但状态均为Free
HugePage设置后，即使不使用它，所占的内存空间也不能被其他进程使用，并且HugePage是pin在物理内存空间的，不会被swap，也就意味着220G物理内存，其实只有92（220G-128G=92G）G可用，故才耗尽swap。
发现限制最大可加锁内存大小为64K，远远小于128G，故修改ulimit限制

6、修改limit限制，使得大页被启用
【注意】oracle重启后才能生效
1）启动oracle前先执行
ulimit -l unlimited
2）修改/etc/security/limits.conf
  增加：
  * soft memlock 136314880
   * hard memlock 136314880
3）查看huge发现已被启用

小结
1）通过分析alert日志和相关的trace，在结合系统日志定位故障原因：发现是资源耗尽被系统kill -
2）通过监控工具或系统命令查找历史信息定位问题：通过zabbix监控查看资源历史使用情况，发现是swap耗尽
3）分析为什么资源会耗尽：查看/proc/meminfo 发现大页开启却未被使用
4）解决问题，以防下次再次发生：调整内存锁的限制，使得大页被oracle使用