运维管理4 分钟阅读
实战篇:JS kgl get object wait 等待事件分析
大家好,这里是公众号 DBA学习之路,致力于分享数据库领域相关知识。 @TOC目录 今天给客户巡检数据库时发现有一套 19C RAC CDB 数据库,AWR 报告中 JS kgl get object wait 等待事件比较重,于是记录了一下排查过程,比较简单。 这里抓取了一小时的 AWR 报告:
2025年1月19日阅读—点赞—收藏—
database
在知识库中专注阅读,并随时返回相关工具与课程
大家好,这里是公众号 DBA学习之路,致力于分享数据库领域相关知识。 @TOC目录 今天给客户巡检数据库时发现有一套 19C RAC CDB 数据库,AWR 报告中 JS kgl get object wait 等待事件比较重,于是记录了一下排查过程,比较简单。 这里抓取了一小时的 AWR 报告:
大家好,这里是公众号 DBA学习之路,致力于分享数据库领域相关知识。
本章目标:掌握本章核心知识点 前置要求:完成前序章节学习 预计时长:60 分钟
今天给客户巡检数据库时发现有一套 19C RAC CDB 数据库,AWR 报告中 JS kgl get object wait 等待事件比较重,于是记录了一下排查过程,比较简单。
这里抓取了一小时的 AWR 报告:

可以看到 Top10 等待事件排名第一是 JS kgl get object wait 等待事件:

MOS 文档上搜了一圈没找到 JS kgl get object wait 等待事件的相关文档说明,但是通过它的名字可以得到一些信息:
JS 一般指 Job Scheduler;kgl 是与 library cache 有关;这样我们就可以理解这个等待是 Job scheduler 相关的 library cache 获得 object 时的等待。
查看 Top SQL 发现确实是有很多 DBMS_SCHEDULER Job 在执行:

印证了上面等待事件与 Job scheduler 有关的可能性。
经过仔细搜索,发现在 19C 版本有 'JS kgl get object wait' 高等待主要有两个 Bug:
根据文档描述, Bug 32999541 主要在 RAC 环境 calling job 的时候产生:

而 Bug 36623712 是在 job creations 的时候:

从 AWR 看,这个高等待在 1月 9 日到 16 日持续存在,显然 Bug 32999541 更符合,而且当前 19.12 的 RU 也没有包含 Bug 32999541。
所以怀疑是这个 BUG 导致,在 MOS 上与 Oracle 确认后,确实是这个 BUG 导致 JS kgl get object wait 等待事件,需要进行补丁修复。
建议打 oneoff 补丁或者升级到最新的 RU 版本。
下载 oneoff 补丁:HIGH WAIT ON JS KGL LOCK ON SELF CALLING JOBS IN RAC

下载好补丁之后查看一下 README 文档要求(提取关键信息):
好在这个补丁支持滚动安装,所以挨个节点停机即可安装。
下载最新的 OPatch 包: OPatch 12.2.0.1.44 for DB 19.0.0.0.0 (Oct 2024)

oracle 用户下解压替换为最新的 OPatch 版本:
1unzip -oq /soft/p6880880_190000_Linux-x86-64.zip -d $ORACLE_HOME2opatch version确保满足以上条件之后,进行补丁安装前检查:
1cd /soft2unzip -q /soft/p32999541_1912000DBRU_Linux-x86-64.zip3cd /soft/329995414opatch prereq CheckConflictAgainstOHWithDetail -ph ./检查没有冲突后,关闭节点一的所有 oracle 相关服务:
1## 节点一2## oracle 用户执行3srvctl stop db -d lucifer4## root 用户执行5crsctl stop crs节点一开始补丁静默安装:
1cd /soft/329995412opatch apply -local -silent安装成功后,查看补丁:
1opatch lsinventory开启所有 oracle 相关服务:
1## root 用户执行2crsctl start crs3## oracle 用户执行4srvctl start db -d lucifer节点二重复节点一的操作即可。
这个问题解决过程比较简单,本文分享仅做记录参考。