_gc_defer_time 的设置 厘秒 毫秒 微秒

隐含参数的作用：RAC环境中 ping 热块能够延时多长时间（具体啥意思见下面绿色）

今日设置此参数时遇到了问题，按各种手册来说，推荐在RAC中设置为3，但是重启后发现变为32
原来是这个参数的时间单位在19c中变了。

11g中单位是毫秒

默认是0

大多数资料中应该是参考下面这段话，建议修改为3

1. 这些 SQL 语句的典型特征是使用基于索引的访问路径。由于许多进程将同时访问这些索引块，争用将集中在较少的索引块上。


2. 此外，并发进程对最近插入的行感兴趣，因此争用将集中在几个表/索引块上。


3. 争用被放大，因为这些索引列的基数，例如状态列，非常低。因此，并发的工作进程相互竞争，积极地访问同一个块。在单实例数据库中，过多的本地化访问会导致等待各种事件，例如缓冲区繁忙等待、ITL 争用等。在 RAC 数据库中，工作进程可能会连接到所有实例。表和索引的数据块在实例之间传输，从而导致严重的性能问题。在发生此性能问题期间，数据库中将显示大量等待事件，例如 gc 缓冲区繁忙获取或 gc 缓冲区繁忙释放。


4. 如果块正忙于进行更改，则全局缓存块传输可能会延迟，从而导致在其他实例中等待全局缓存事件。此延迟由 _gc_defer_time 参数控制，默认为 3 厘秒。


5. 此外，由于行被锁定以进行更新，块头中的 ITL 条目将显示活动事务。访问这些块的其他进程必须通过访问 undo 头块中的事务表来确定事务状态。由于原始事务可能已在另一个实例中启动，因此可能需要传输来自其他实例的撤消标头和撤消块。这种过度的块传输会导致复杂的性能问题。

这里说的单位是厘秒（百分之一秒），设置为3的话，在11g中应该是300毫秒，即
alter system set "_gc_defer_time"=300 scope=spfile sid='*';
但大多数手册和实际使用时设置为了3 （惊！）

19c的单位变为微秒了

再按3设置后，重启实例发现自动变为32，这是允许的最小值！

如果是单机环境设置此参数则还会被重置为0.


GC_DEFER_TIME 是一个 Oracle 并行服务器参数，它指定服务器在响应来自其他实例的热块的强制写入请求之前等待或“延迟”的时间（以 100 分之一秒为单位）。 指定 GC_DEFER_TIME 参数使缓冲区更有可能在写入之前被正确清除。 这样做可以使其他实例更容易读取缓冲区，并且还提高了在强制写入之间的实例内多次使用热块的机会。

将该值设置为 0 将禁用该功能。 在这种情况下，Oracle 根本不会推迟强制写入请求。

所以，通常情况下最好还是不要设置此参数了。

参考：

http://what-when-how.com/Tutorial/topic-108718ku082/Expert-Oracle-RAC-12c-176.html