Oracle 19c BUG 34482043 导致SQL节点2查询缓慢

原创 JiekeXu All China Database Union 2025-12-11

332

大家好，我是JiekeXu,江湖人称“强哥”，青学会MOP技术社区主席，荣获Oracle ACE Pro称号，金仓社区最具价值倡导者KVA，崖山最具价值专家YVP，IvorySQL开源社区专家顾问委员会成员，KWDB社区MVP，墨天轮MVP，墨天轮年度“墨力之星”，拥有Oracle OCP/OCM认证,MySQL 5.7/8.0 OCP认证以及金仓KCA、KCP、KCM、KCSM证书，PCA、PCTA、OBCA、OGCA等众多国产数据库认证证书,欢迎关注我的微信公众号“JiekeXu DBA之路”，然后点击右上方三个点“设为星标”置顶，更多干货文章才能第一时间推送，谢谢！

前言

有这样一个有趣的问题，昨天早上有一位开发同事找过来说在生产环境上通过PLSQL客户端查询相同的 SQL 在主库执行较快，大约 5s 左右，在备库执行却需要 60s 多，此 SQL 所在的应用连接的是只读备库，导致接口超时，出现故障。

然后我去执行 SQL 发现确实现象一样，主库快备库慢，但当我登录到服务器去执行 SQL 时仅需要 8s 左右，相差不大也不是特别慢，在接受范围内；于是又登陆到节点2 执行发现特别慢，需要 60s 多才查出来了三条数据。真是奇怪了，RAC 两节点查看数据居然执行时间快慢大不一样，这是一个有趣的事情，直接一探究竟。

问题排查

首先交代一下为何会出现这样的问题，大概是因为上周六这套环境刚做了主备切换，原来的备库是运行在 RHEL9.6 的 RU19.23 RAC 上，主库是运行在 RHEL7.8 的 RU19.15 RAC 上，切换后为了还可以回退暂时没有更新 RU23 补丁，备库版本还是 19.15，主备库版本不一致。

查看数据库参数文件使用的是 spfile 存在于 ASM 上，说明参数文件仅一份，创建 pfile 查看参数文件内容，实例 2 也没有单独的参数设置，和实例 1 是一样的参数设置。操作系统CPU内存资源、内核参数都是最开始配置的这块都是一样的，可以说资源、配置都一样了。

然后通过 PLSQL F5 或者 set autot on 查看执行计划，除了备库实例 2 慢之外，执行计划都一样。

图片.png

那么我们通过 10046 跟踪一下备库实例 2 会话看看有啥不一样呢。

使用 10046 跟踪

oradebug setmypid
oradebug unlimit;
oradebug event 10046 trace name context forever,level 12;
--执行查询SQL 
oradebug tracefile_name
--格式化输出
tkprof JTDB1_ora_58856.trc -output = RAC1.txt
tkprof JTDB2_ora_55007.trc -output = RAC2.txt

ALTER SESSION SET EVENTS '10046 trace name context forever, level 12'; 
ALTER SESSION SET EVENTS '10046 trace name context off';

TKPROF（Trace Kernel Profiler）是 Oracle 自带的命令行工具，用于将原始的 SQL 跟踪文件（*.trc）转换为易读的格式化报告，解析 SQL 执行的耗时、执行计划、等待事件等关键信息，是诊断慢 SQL、定位性能瓶颈的核心工具。

tkprof <原始跟踪文件.trc> <输出报告.txt> [可选参数]
tkprof /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_12345.trc \
       /home/oracle/sql_report.txt \
       sort=ela \   
       sys=NO \
       explain=scott/tiger \
       waits=YES

图片.png

如下图，通过查看 trace 发现执行 62.88 秒，“gc cr multi block mixed”等待事件最多，TIMES WAITED 等待总次数为 59118，Max wait 单次最大等待时长（以百分之一秒为单位）0.62，Total Waited 总耗时是 45.44 秒。

图片.png

tkprof JTDB2_ora_55007.trc  ins2.txt  sys=no sort=prsela,exeela,fchela

格式化之后的结果，更易于阅读，但同时也省去了一些细节信息，我是没怎么看过，很多都不理解，不过现在 AI 盛行，也算有个小助手了，如果不格式化全部能看懂的人还是比较厉害的了。

图片.png

如图，看到“gc cr multi block mixed”等待事件最多且为一个不常见的等待事件，所以只能借助搜索引擎了，在 MOS 中搜索，AI 直接给出了一个参考答案：

本答案适用于：Oracle数据库 - 企业版 - 版本11.2.0.4至21.9 [发行版11.2至21.0]
“gc cr multi block mixed”等待异常值的问题在文档标题中有所描述：Bug 34482043 - 一些“gc cr multi block mixed”等待异常值导致 19c 出现性能回归。
根据文档，此bug仅在使用Real Application Clusters (RAC)时相关，并会导致CR多块读取性能下降。
34482043的修复首次包含在19.18.0.0.230117（2023年1月）DB发布更新（DB RU）中。
早期版本可能提供临时补丁。有关此bug的问题，请咨询Oracle支持。

图片.png

查看文章 Bug 34482043, SQL 执行时的等待事件 gc cr multi block mixed，且执行时间过长，还是 RAC 架构，数据库版本目前还是 19.15，那么刚好命中这个Bug，MOS 给出的答案是 19.9–19.18 RAC 架构下的 bug。知道问题原因了，那么就很好解决了，直接备库补丁也升级到 19.23 就可以解决了。

图片.png

This bug is only relevant when using Real Application Clusters (RAC)
CR Multi block read performance degradation.
  
 
REDISCOVERY INFORMATION:
FG traces show IPCLW discarding messages with older sequence number than the
expected.
 
Example:
 
 IPCLW:[0.1]{-}[WAIT]:PROTO: [1659935330904717]ipclw_data_chunk_process:1219 
 Discarding msg with seq # 2030753391, expecting 2030753394

问题解决

因补丁升级需要有停机窗口，一时半会儿没法停机，则暂时折中的办法就是新建一个 service 优先连接节点1，到晚上后修改连接串重启此应用为最优，后续有停机窗口，可停机打补丁。

新建 service

分别在主备库使用 Oracle 用户创建 service 优先连接节点1，当节点1无法连接时才会考虑连接节点2，这样算临时解决了此 SQL 性能查询问题，后续寻找窗口打补丁。

srvctl add service -db jiekexudb -service r_mobile_sel -preferred "jiekexudb1" -available "jiekexudb2" -failback yes -tafpolicy basic

srvctl start  service -db jiekexudb -service r_mobile_sel
srvctl config service -db jiekexudb -service r_mobile_sel

打补丁

差不多过了快一个月申请停机窗口打完了此备库的补丁到 RU 19.23.240416，打补丁的过程需要停机，使用 root 自动打补丁时不能在家目录或者根目录执行，其他细节这里不在赘述了，然后在主库执行了datapatch SQL脚本，主备数据正常同步后查看版本为主库的版本。

set line 456
col ACTION_TIME for a30
col DESCRIPTION for a55
select patch_id, action,status,action_time,description from dba_registry_sqlpatch;

  PATCH_ID ACTION          STATUS                    ACTION_TIME                    DESCRIPTION
---------- --------------- ------------------------- ------------------------------ -------------------------------------------------------
  33806152 APPLY           SUCCESS                   18-FEB-23 12.09.24.905617 PM   Database Release Update : 19.15.0.0.220419 (33806152)
  36199232 APPLY           SUCCESS                   29-NOV-25 04.37.51.555823 PM   OJVM RELEASE UPDATE: 19.23.0.0.240416 (36199232)
  36233263 APPLY           SUCCESS                   29-NOV-25 04.38.49.343052 PM   Database Release Update : 19.23.0.0.240416 (36233263)

在打补丁的过程中尝试通过刷缓存或者重启节点 2 实例，都没有解决此慢查询问题，只有打完补丁跑完 SQL 后才恢复到和节点 1 一样的时间。

alter system flush buffer_cache;
alter system flush shared_pool;
shu immediate

主库执行都是 4 秒多，备库第一次执行 35 秒多，后面几次执行稳定在 7 秒左右。此问题算是告一段落了，具体的 SQL 暂时也就不用优化了。

主库RAC1执行时间	主库RAC2执行时间
Elapsed: 00:00:04.45	Elapsed: 00:00:04.44
Elapsed: 00:00:04.38	Elapsed: 00:00:04.29
备库升级补丁RU19.23后的执行时间
备库 RAC1 执行时间	备库 RAC2 执行时间
Elapsed: 00:00:30.76	Elapsed: 00:00:35.17
Elapsed: 00:00:06.54	Elapsed: 00:00:06.55
Elapsed: 00:00:07.61	Elapsed: 00:00:07.64

参考文章

Doc ID 34482043.8 --MOS改版前文档 id
KI35400 Bug 34482043 - Some "gc cr multi block mixed" wait outliers cause a performance regression in 19c

全文完，希望可以帮到正在阅读的你，如果觉得有帮助，可以分享给你身边的朋友，同事，你关心谁就分享给谁，一起学习共同进步~~~

欢迎关注我的公众号【JiekeXu DBA之路】，一起学习新知识！
——————————————————————————
公众号：JiekeXu DBA之路
墨天轮：https://www.modb.pro/u/4347
CSDN ：https://blog.csdn.net/JiekeXu
ITPUB：https://blog.itpub.net/69968215
腾讯云：https://cloud.tencent.com/developer/user/5645107
——————————————————————————
facebook_pro_light_1920 × 1080 副本.png