从Oracle数据库故障到AIX内存管理墨墨导读：本文来自墨天轮用

墨墨导读：
本文来自墨天轮用户“你好我是李白”的投稿，详细介绍数据库告警最核心的一套数据库1节点hang的处理过程。
墨天轮主页：https://www.modb.pro/u/3997
某日，数据库告警最核心的一套数据库1节点hang ，立马打开连接窗口，查看当前系统负载，发现topas已经无法执行，过滤LOCAL=NO会话kill掉已经无法执行，报错无法分配内存，无法连接数据库，重启操作系统，恢复服务。
事后最终定位问题，发现在执行kill会话命令报错无法分配内存，早已指明了故障原因，服务器相关指标也早已指向内存不足，只是由于以下两方面原因导致定位问题走了许多弯路，甚至一度只能猜测原因：
1.AIX内存由于大部分情况下有很大一部分filecache ，导致监控长期显示内存使用率均在90%以上，所以并未真正注意AIX内存各个部分占用比例指标，导致故障服务器内存其实早已在危险边缘试探，而我们并未及时调整。
2.对AIX内存各个部分占比、管理方式、相关参数设置一知半解，导致未从监控数据相关信息中发现这是由于内存不足-会话增长-内存耗尽导致。
下面就故障分析过程以及AIX内存管理一些参数指标分享，供大家参考。
监控系统告警数据库hang ，通过已连接ssh会话查看CPU100% ，服务器hang 。
除已经连接用户外，无法再通过ssh、sqlplus连接服务器。
环境概述
数据库版本11.2.0.4 ，操作系统AIX7.1
一般对于远程连接无法执行命令，根据经验一般为swap频繁pagein、pageout ，内存耗尽导致，那到底是哪儿出了问题呢？下面就需要结合下面两部分进行分析：
操作系统nmon、oswatcher数据
Oracle集群日志、数据库日志进行诊断。、
数据库以及集群日志
故障节点alert日志
在故障前alert日志并无异常，故障期间，可以看到alert日志如下， 15:29分之前日志并无异常，未截取。
结合报错Error1013duringfillingupusnavailcache ， OracleMos有文档，但是与发生故障Oracle版本并不对应，现象也不匹配，所以可以作为参考。
集群日志
可以看到是在节点1告警hang之后，集群监测到了异常。
集群日志并无相关报错信息，只是监测到1节点资源无法确定状态，置为unknown ，在其集群其他crsd、cssd、agent日志中均类似，并无相关资源或进程报错。
ASH信息
可以看到在故障前并无异常等待事件，均为正常OGG集成投递以及一些weblogic正常执行SQL会话。
由于此时操作系统已无法响应，所以15:30~15:36相关信息ASH中未采样到。
遇到数据库严重故障，操作系统的CPU、memory、I/O等信息对定位问题就变得非常重要，
不结合操作系统监控数据往往只能根据数据库残留的一些信息对故障原因进行猜测。
oswatcher数据
oracle11.2.0.4RAC会自带oswatcher ，可通过下面命令查看oswatcher数据存放目录，默认30秒采样一次，保留48小时。
拿到oswatcherarchive目录所有数据之后，可将数据拷贝至任意安装java机器或windows机器使用如下命令解析：
可以看到在故障时间段15:30~15:45期间， CPU到最后15:45左右服务器hang都没有达到100% 。
在故障期间，发生了内存交换，这说明故障期间，可用内存不足，内存耗尽。
oswatcher还会生成每隔30秒的ps命令生成的进程信息，我们通过分析ps相关信息发现LOCAL=NO会话在故障前后如下：
在15:00到15:15分左右， LOCAL=NO会话由2800增长至3500,15:15到15:30左右，会话数维持在3500左右略有下降，在15:30到15:45服务器hang期间，会话由于得不到响应，暴涨至最高4500直到重启服务器。
注：所以oswatcher的ps统计信息也是非常重要的信息，可以真实判断会话总数趋势。
nmon数据
如果说oswatcher图粒度不够细，那么nmon数据展示则更为容易分辨趋势。
下面就从摘取最为重要的三个维度CPU、磁盘I/O、内存趋势图：

文章图片

文章图片

文章图片

文章图片
结合OS监控、数据库日志，我们可以初步推断为操作系统内存耗尽，引发swap使用，从I/Ohdisk0达到busy100%也可印证，导致服务器hang ，进而导致数据库hang 。
以前没注意过AIX内存管理机制，所以未对相关重要指标进行监控以及管理，导致服务器内存其实早就已经开始在危险边缘试探而我们却并未在意，最终导致业务期间会话突增700连接压垮服务器，引发故障。