图片水印为本人在csdn账号
故障描述
2022 年 7 月 16 号早上 9 点 49 左右，客户 jsbas 生产库。客户反馈应用系统慢并且报超时错误； 后续反馈应用用户无法连接数据库，其他用户登录没问题。
这套 RAC 环境总共 6 个节点，上面运行 5 套数据库。 出问题的是 jsbas 数据库， jsbas 数据库实例运行在节点 3 ， 4 ， 5 ， 6 。其他数据库都正常。
临时处理方法
检查当前等待事件：
检查发现，大部分都是 library cache lock 等待事件，大概有 1904 个会话。
让客户杀掉会话，杀掉之后，随后又发起 300 多个会话。最后停掉实例 5 解决。
问题详细诊断过程
检查会话情况：
2022/7/16 9:14:22 到 2022/7/16 9:15:22 1 分钟之内活动会话数从 785 增加到 1524 ，增加 739 左右。
检查 ash 视图会话情况：
select a.INSTANCE_NUMBER,to_char(a.sample_time, 'yyyy-mm-dd hh24:mi:ss') as "DATE",
session_id,
session_serial#, a.USER_ID, sql_id, wait_time,a.P1,a.p1text,
a.event,a.MACHINE,a.PROGRAM, a.BLOCKING_SESSION,a.BLOCKING_SESSION_SERIAL#,BLOCKING_INST_ID,BLOCKING_SESSION_STATUS
from dba_hist_active_sess_history a
where a.sample_time > to_date('2022-07-16 9:00:00', 'yyyy-mm-dd hh24:mi:ss')
and a.sample_time < to_date('2022-07-16 9:15:00', 'yyyy-mm-dd hh24:mi:ss') order by to_char(a.sample_time, 'yyyy-mm-dd hh24:mi:ss');
从上面可以看出 2022-07-16 09:14:53 这个时间点，大概有 70 个活动会话，而且这些会话基本被其中几个会话阻塞。 被阻塞的会话等待事件： library cache lock SQL_ID 为空； 阻塞会话的等待事件： Memory: Reg/Dereg SQL_ID 为 9zg9qd9bm4spu
检查阻塞会话 sql 文本：
完整语句为： update user$ set spare6=DECODE(to_char(:2, 'YYYY-MM-DD'), '0000- 00-00', to_date(NULL), :2) where user#=:1
这个 update 语句的作用是每当用户会话登录数据库，会话第一次访问数据库的时候记录用户的本次登录时间。对应的是 DBA_USERS 视图里面的 LAST_LOGIN 字段。
检查所有阻塞会话：
从上面可以发现，所有的阻塞会话为上面 6 个会话。
检查 Memory: Reg/Dereg 等待事件：
Mos 上解释如下：
造成这个等待的原因是 登录风暴，也就是高并发的登录数据库会导致这个等待事件。
检查 library cache lock 等待事件：
2022-07-16 09:14:53 这个时间点，本次所有的 library cache lock 会话都被 Memory: Reg/Dereg 等待事件会话阻塞，可以判断这些 library cache lock 会话是登录会话，等待更新登录时间，也就是说上面 70 多个会话都是登录会话。
检查 MOS(Doc ID 33121934.8) 发现， update user$ 表确实会导致 library cache lock 这个是 oracle bug 。 oracle 12.1.0.2 及以上版本， 23.1 以下都存在这个问题。
另外，检查受影响用户，除了 JOUR 用户，还有其他用户，如下所示：
上面都是应用用户，由于多个应用用户的阻塞会话正在执行 update 登录时间，导致后面这些用户登录会话无法更新底层表的登录时间，所以无法连接数据库，而其他用户登录没问题。
总结， 2022-07-16 09:14:53 时间点，应用会话暴增， 70 个用户会话（主要集中在 jour 用户）同时登录到数据库，导致触发 oracle bug 无法及时更新用户登录时间。
解决办法和建议
1. 建议应用查找 2022-07-16 09:14:53 时间点，应用会话暴增的原因。
2. 建议从应用角度控制每次并发的会话量。
3. 可以考虑升级到 19.14,19.15 ，然后可以打 oracle bug 补丁（不推荐）。
参考文档
Lots of “ Memory: Reg/Dereg ” waits or high CPU usage by IPC0 background process on Exadata (Doc ID 2832480.1)
Bug 33121934 - Library cache lock / load lock / mutex x during connection storm due to update user$ (Doc ID33121934.8)
