1. Tue Oct 11 04 :00 :11 2016
2. Archived Log entry 2772 added  for thread 1 sequence 2922 ID 0x8d1dfa38 dest 1 :
3. Tue Oct 11 09 : 24 : 23 2016
4. PMON  ( ospid :  26463 ) :  terminating the instance due to error 471
5. Tue Oct 11 09 : 24 : 24 2016
6. System state dump requested by  ( instance = 1 ,  osid = 26463  ( PMON ) ) ,  summary = [ abnormal instance termination ] .
7. System State dumped to trace file /u01/app/oracle/diag/rdbms/retailstb/biedwshoes/trace/biedwshoes_diag_26479_20161011092424 . trc
8. Dumping diagnostic data  in  directory = [ cdmp_20161011092424 ] ,  requested by  ( instance = 1 ,  osid = 26463  ( PMON ) ) ,  summary = [ abnormal instance termination ] .
9. Instance terminated by PMON ,  pid  =  26463
10. Tue Oct 11 09 :30 :11 2016
11. 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使用