从Oracle数据库故障到AIX内存管理

墨墨导读：本文来自墨天轮用户“你好我是李白”的投稿，详细介绍数据库告警最核心的一套数据库1节点hang的处理过程。墨天轮主页：https://www.modb.pro/u/3997

某日，数据库告警最核心的一套数据库1节点hang，立马打开连接窗口，查看当前系统负载，发现topas已经无法执行，过滤LOCAL=NO会话kill掉已经无法执行，报错无法分配内存，无法连接数据库，重启操作系统，恢复服务。

事后最终定位问题，发现在执行kill会话命令报错无法分配内存，早已指明了故障原因，服务器相关指标也早已指向内存不足，只是由于以下两方面原因导致定位问题走了许多弯路，甚至一度只能猜测原因：

1. AIX内存由于大部分情况下有很大一部分file cache，导致监控长期显示内存使用率均在90%以上，所以并未真正注意AIX内存各个部分占用比例指标，导致故障服务器内存其实早已在危险边缘试探，而我们并未及时调整。
2. 对AIX内存各个部分占比、管理方式、相关参数设置一知半解，导致未从监控数据相关信息中发现这是由于内存不足-会话增长-内存耗尽导致。

下面就故障分析过程以及AIX内存管理一些参数指标分享，供大家参考。

1. 故障现象

• 监控系统告警数据库hang，通过已连接ssh会话查看CPU 100%，服务器hang。

• 除已经连接用户外，无法再通过ssh、sqlplus连接服务器。
  环境概述
  数据库版本11.2.0.4，操作系统AIX 7.1

2. 初步分析，是Oracle还是OS出了问题？

一般对于远程连接无法执行命令，根据经验一般为swap频繁page in、page out，内存耗尽导致，那到底是哪儿出了问题呢？下面就需要结合下面两部分进行分析：

• 操作系统nmon、oswatcher数据

• Oracle集群日志、数据库日志进行诊断。、

2.1 数据库日志以及ASH分析

数据库以及集群日志

1. 故障节点alert日志

• 在故障前alert日志并无异常，故障期间，可以看到alert日志如下，15:29分之前日志并无异常，未截取。

• 结合报错Error 1013 during filling up usn avail cache，Oracle Mos有文档，但是与发生故障Oracle版本并不对应，现象也不匹配，所以可以作为参考。

Mon Jan 11 15:29:56 2021AP01: warning -- apply server 20, sid 6085 waiting for event (since 731 seconds):AP01: warning -- apply server 42, sid 6126 waiting for event (since 354 seconds):AP01: warning -- apply server 45, sid 3788 waiting for event (since 342 seconds):AP01: warning -- apply server 44, sid 3530 waiting for event (since 564 seconds):AP01: warning -- apply server 40, sid 2419 waiting for event (since 343 seconds):AP01: warning -- apply server 33, sid 4578 waiting for event (since 344 seconds):Mon Jan 11 15:30:30 2021AP01: warning -- apply server 31, sid 1049 waiting for event (since 435 seconds):Mon Jan 11 15:32:07 2021Mon Jan 11 15:32:07 2021Mon Jan 11 15:32:07 2021[27328748] Error 1013 during filling up usn avail cacheMon Jan 11 15:32:07 2021[19595412] Error 1013 during filling up usn avail cache**********************************************************************************************************************************************Mon Jan 11 15:32:17 2021[16058276] Error 1013 during filling up usn avail cacheMon Jan 11 15:32:12 2021[11799172] Error 1013 during filling up usn avail cacheMon Jan 11 15:32:19 2021[2886074] Error 1013 during filling up usn avail cacheMon Jan 11 15:32:16 2021

1. 集群日志

• 可以看到是在节点1告警hang之后，集群监测到了异常。

• 集群日志并无相关报错信息，只是监测到1节点资源无法确定状态，置为unknown，在其集群其他crsd、cssd、agent日志中均类似，并无相关资源或进程报错。

2021-01-11 15:30:48.975: [UiServer][11311]{1:44279:29645} Done for ctx=132437ab02021-01-11 15:32:27.616: [ COMMCRS][11568]clsc_auth_send: (1325a2470) Connection not active
2021-01-11 15:32:38.344: [ COMMCRS][11568]Authorization failed, network error
2021-01-11 15:32:38.344: [UiServer][11568] clscanswer returned error: 32021-01-11 15:32:55.936: [    AGFW][9769]{0:1071:37} Agfw Proxy Server received the message: RESOURCE_STATUS[Proxy] ID 20481:9128592021-01-11 15:32:55.936: [    AGFW][9769]{0:1071:37} Verifying msg rid = ora.asm wbxtdb01 12021-01-11 15:32:55.936: [    AGFW][9769]{0:1071:37} Received state change for ora.asm wbxtdb01 1 [old state = ONLINE, new state = UNKNOWN]2021-01-11 15:32:55.936: [    AGFW][9769]{0:1071:37} Received state LABEL change for ora.asm wbxtdb01 1 [old label  = Started, new label = ]2021-01-11 15:32:55.936: [    AGFW][9769]{0:1071:37} Agfw Proxy Server sending message to PE, Contents = [MIDTo:2|OpID:3|FromA:{Invalid|Node:0|Process:0|Type:0}|ToA:{Invalid|Node:-1|Process:-1|Type:-1}|MIDFrom:0|Type:4|Pri2|Id:8026336:Ver:2]2021-01-11