1、故障描述

某日7点32，某核心数据库1节点发生重启，重启完成后pdb未自动启动到open，导致部分客户端会话直连报错，后经由用户手动启动pdb到open后故障恢复。以下内容为本次故障排查原因之明细。

2、根因分析

(1)、检查服务器重启情况

可以确定服务器在当日并没有重启。

(2)、检查集群重启情况

由上图可见1节点监听运行时间为248天，可知集群软件未发生重启，由此可排除脑裂原因，即私网心跳没有问题。

(3)、检查数据库实例重启情况

发现1节点当日发生过重启，由此可着重排查1节点的数据库日志。

(4)、排查数据库日志

可见在7点32时发生IPC通讯问题，紧接着35分实例重启。罪魁祸首是LMS相关进程，该进程主要负责缓存块的跨节点传输，属于rac的重要系统进程。“Receiver is waiting for a latch, dumping latch state for ospid 20808 [ORACLE.EXE (LMS1)] 20808”可见存在闩锁等待，需要进一步分析LMS进程的trc日志和历史等待事件。

(5)、分析 trace 日志

07:23‑07:24：msg pool 消息池 10 秒翻倍，未处理 mbuf 从 6k→20k→47k，消息大量堆积;Pending SendQ 队列积压。LMS 进程处理速度跟不上消息生成速度。

07:24‑07:32：消息池持续吃紧，LMS2 进程出现 kghalo SGA堆内存分配阻塞、大量latch free闩锁竞争抢消息池内存;LMS 后台进程自身处理能力进一步下降，消息堆积雪上加霜。

07:32:47：LMS1 进程私网 socket 报 10054 (WSAECONNRESET)，通信连接强制关闭。LMS3 进程同样报 10054。集群消息收发彻底瘫痪。

(6)、分析等待事件

等待事件中存在大量gc等待，与alert日志反映情况一致。

(7)、检查数据库版本及补丁情况

由从此可知当前数据库版本为12.1.0.1.0，且未应用任何补丁，12.1.0.1 是 12cR1 的初始版本，稳定性差，大量已知 bug，Oracle 官方不建议生产使用。

(8)、mos 资料匹配

由于12.1.0.1版本数据库非稳定版本，官方在16年停止其维护，官网相关较少，无法找到同版本故障报告，目前仅找到12.2版本相似故障的报告如图

3、解决方案

该故障发生时，数据库单节点会自动重启，目前重启后PDB无法自动拉起到open，会影响部分直连业务。12.1.0.1版本不支持pdb save state,需要手动创建触发器来实现PDB自动拉起，命令如下：

create trigger open_pdb after startup on database
begin
execute immediate 'alter pluggable database PDBNAME open';
end;
/

鉴于该版本数据库软件的不稳定情况，从源头解决该问题需要将数据库版本原地升级19.31或迁移至linux系统的19.31版本。