Oracle 19c RAC登录风暴引发library cache lock生产故障分析

故障环境为 Exadata 一体机 Oracle 19.9 RAC，出现部分业务用户无法连接数据库、其他用户登录正常的现象，本文完整还原故障现象、排查思路、内核 Bug 根因、解决方案。

一、故障现象

凌晨 01:45，生产数据库收到异常告警短信，告警等待事件cursor: pin S wait on X。业务现象非常特殊：部分应用用户无法建立数据库连接，其余用户登录访问完全正常。

环境信息

硬件：Oracle Exadata 一体机
操作系统：RHEL 7.9
数据库版本：Oracle 19.9 RAC，整套集群共 8 节点，承载 5 套数据库
故障实例运行在集群 4、5、7、8 节点；集群其余数据库运行正常，故障仅发生在单套库
业务类型：OLTP

运维告警提示节点cursor: pin S wait on X等待事件计数超过阈值，初步推测硬解析、游标共享存在问题，可能影响数据库处理性能。

二、问题诊断排查

故障发生后，现场查询实时会话视图时数据库业务已经恢复，会话状态无异常。通过 ASH 历史视图回溯故障窗口01:00‑01:45时间段会话行为。

1、定位异常会话特征

在凌晨01:12:57，瞬间爆发 500 + 活跃登录会话，大量会话被少量会话阻塞。

被阻塞会话：等待事件library cache lock，SQL_ID 为空；
阻塞会话：等待事件Memory: Reg/Dereg，对应 SQL_ID：9zg9qd9bm4spu。

2、定位阻塞的内部 SQL

查询gv$sqltext获取 SQL 文本：

sql 复制代码

update user$ set spare6=DECODE(to_char(:2, 'YYYY-MM-DD'), '0000-0000', to_date(NULL), :2) where user#=:1

这是 Oracle 内部隐式 SQL。当会话首次访问数据库时，自动更新基表user$，用于维护DBA_USERS.LAST_LOGIN（用户最后登录时间）字段，每一次用户登录都会触发该语句执行。

3、关键等待事件解读

Memory: Reg/Dereg

根据 MOS 文档说明，该等待事件典型诱因就是登录风暴：短时间大量新建数据库连接，触发内存注册、注销操作，引发该等待。
library cache lock

大量新建登录会话排队，都要执行上面这条update user$，被少数持有锁的会话阻塞，形成会话雪崩排队。

4、确认 Oracle Bug

查阅 MOS 文档 Bug 33121934（Doc ID 33121934.8）

受影响版本：Oracle $12.1.0.2$ (12.1.0.2) ~ 23.1。在连接风暴场景，大量并发登录触发update user$更新 LAST_LOGIN，引发library cache lock、mutex X 锁，会话大规模排队，出现部分用户无法登录，其他用户不受影响的现象，本次 19.9 版本正好落在受影响版本区间。

5、时间线补充说明

溯源发现阻塞会话在故障前一天 23:29 就已经产生，一直持续到凌晨 01:45 故障结束，这就造成告警触发时间与 ASH 抓取异常时间不完全对齐。

根因总结

业务侧触发登录风暴：1 秒内 500 + 会话同时登录数据库，大量新建连接并发执行 Oracle 内部更新user$；
触发 Oracle 内核 Bug33121934，引发Memory: Reg/Dereg与library cache lock连锁锁等待；
仅批量登录的应用用户被阻塞，其他账号访问不受影响，并非数据库整体宕机。

该故障有很强迷惑性：容易把排错方向带到账号权限、硬解析问题，忽略 Oracle 内部基表更新逻辑。

三、解决方案与优化建议

🔹应用侧优化（优先落地，风险最低）

排查会话突增源头：定位故障时间点前后会话暴涨的根因，重点排查定时任务、应用 Pod 批量重启、连接池大规模重连、版本发布等事件；
应用连接池管控：控制并发新建连接峰值，规避瞬时登录风暴。

🔹数据库侧根治方案

方案：补丁 + 隐藏参数关闭登录时间记录

将数据库版本升级至 19.14 /19.15，安装 Bug 33121934 补丁包；也可直接升级 19.16 版本（该版本已内置修复）；
设置隐藏参数关闭 LAST_LOGIN 记录特性：

sql 复制代码

_disable_last_successful_login_time = true

参数作用：关闭登录时间记录，不再执行update user$，从根源规避 Bug 触发条件。

⚠️注意评估业务影响：开启该参数后，DBA_USERS.LAST_LOGIN字段不会更新，如果业务审计依赖此字段，需要做好替代方案。

🔹运维监控优化建议

监控增加Memory: Reg/Dereg、library cache lock等待事件告警，不只局限监控cursor:pin S wait on X；
增加数据库新建连接速率监控，识别瞬时登录风暴，实现提前预警；
Exadata RAC 环境，19c 低版本 OLTP 业务，需要重点关注 Bug33121934 风险。

四、参考 MOS 文档

1.Lots of "Memory: Reg/Dereg" waits or high CPU usage by IPC0 background process on Exadata KB792093

2.Bug 33121934.8 Library cache lock / load lock / mutex x during connection storm due to update user$

写在最后

很多生产故障不是业务 SQL、索引问题，而是业务流量场景刚好踩中 Oracle 内核 Bug。本次故障最值得吸取经验：遇到大量library cache lock且 SQL_ID 为空的会话，优先排查是不是爆发登录风暴，第一时间核查 Bug 33121934。