19c BUG 导致大量gc quiesce等待事件

墨墨导读：某省级运营商客户今年进行3套核心数据库迁移19c项目，项目进行过程中遇到不少Oracle BUG。本文介绍在业务测试过程中，由于BUG导致数据库产生大量gc quiesce等待。

问题现象

其中一套数据库在业务测试过程中，业务反馈入库进程缓慢。入库是程序调用SQL*LOADER，在入库前进程会先将表进行truncate。

问题分析

首先从v$session中，可以看到有一些gc quiesce等待，且sql_id不断变化，证明等待的时间不算太长，而且持续不断的发生，sql文本显示都是一些truncate语句，跟入库进程相关。

取awr分析，绝大部分的BD time消耗在gc quiesce等待上，平均等待时间1ms。

且等待全部消耗在truncate语句上。

gc quiesce不是一个常见的等待事件，通过搜索相关资料，信息比较有限。
下面的说明显示：该等待本身不是问题，只是其他一些问题（如：ORA-600）的副作用。

The process was waiting for a GC lock to quiesce. In general, this event should NOT be severe.
The wait event itself is not a problem, it is a side effect of other problem (eg, ora-600 or other problem which prevent it from processing further)

且搜索到在10.2.0.3版本上，有一个跟truncate相关的BUG介绍，虽然版本差距较大，但隐约感觉当前的问题依然是BUG引起。

通过SR沟通，答复与Bug 29908777的现象匹配度较高，该BUG目前没有公开的文档资料，但已经有针对我们19.6版本的补丁发布。

具体问题是buffer上的锁在关闭时存在不必要的处理，可能造成导致1秒以内的"gc quiesce"等的等待事件。而这个等待事件是否出现，可能与当时各个节点的缓存状况以及是否有热块有关；而且在涉及较多Buffer的TRUNCATE处理上会表现得明显一些。

问题解决

通过打上29908777补丁，经观察gc quiesce等待基本消失。

平均等待时间由原来的1ms降为0.08ms，问题解决。

墨天轮原文链接：https://www.modb.pro/db/27354（复制到浏览器中打开或者点击“阅读原文”）

推荐阅读：144页！分享珍藏已久的数据库技术年刊

---

视频号，新的分享时代，关注我们，看看有什么新发现？

数据和云

ID：OraNews

如有收获，请划至底部，点击“在看”，谢谢！

点击下图查看更多 ↓

云和恩墨大讲堂 | 一个分享交流的地方

长按，识别二维码，加入万人交流社群

请备注：云和恩墨大讲堂

  点个“在看”

你的喜欢会被看到❤