图片水印为本人在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)