故障环境为 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 lockSQL_ID 为空阻塞会话等待事件Memory: Reg/Dereg对应 SQL_ID9zg9qd9bm4spu。2、定位阻塞的内部 SQL查询gv$sqltext获取 SQL 文本updateuser$setspare6DECODE(to_char(:2,YYYY-MM-DD),0000-0000,to_date(NULL),:2)whereuser#:1这是 Oracle 内部隐式 SQL。当会话首次访问数据库时自动更新基表user$用于维护DBA_USERS.LAST_LOGIN用户最后登录时间字段每一次用户登录都会触发该语句执行。3、关键等待事件解读Memory: Reg/Dereg根据 MOS 文档说明该等待事件典型诱因就是登录风暴短时间大量新建数据库连接触发内存注册、注销操作引发该等待。library cache lock大量新建登录会话排队都要执行上面这条update user$被少数持有锁的会话阻塞形成会话雪崩排队。4、确认 Oracle Bug查阅 MOS 文档Bug 33121934Doc 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 记录特性_disable_last_successful_login_timetrue参数作用关闭登录时间记录不再执行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 KB7920932.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。
故障环境为 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 lockSQL_ID 为空阻塞会话等待事件Memory: Reg/Dereg对应 SQL_ID9zg9qd9bm4spu。2、定位阻塞的内部 SQL查询gv$sqltext获取 SQL 文本updateuser$setspare6DECODE(to_char(:2,YYYY-MM-DD),0000-0000,to_date(NULL),:2)whereuser#:1这是 Oracle 内部隐式 SQL。当会话首次访问数据库时自动更新基表user$用于维护DBA_USERS.LAST_LOGIN用户最后登录时间字段每一次用户登录都会触发该语句执行。3、关键等待事件解读Memory: Reg/Dereg根据 MOS 文档说明该等待事件典型诱因就是登录风暴短时间大量新建数据库连接触发内存注册、注销操作引发该等待。library cache lock大量新建登录会话排队都要执行上面这条update user$被少数持有锁的会话阻塞形成会话雪崩排队。4、确认 Oracle Bug查阅 MOS 文档Bug 33121934Doc 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 记录特性_disable_last_successful_login_timetrue参数作用关闭登录时间记录不再执行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 KB7920932.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。
