问题现象

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

问题分析

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

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

且等待全部消耗在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等待基本消失。
平均等待时间由原来的1s降为0.08ms，问题解决。