在新的事务绑定到某个undo段某个slot上，将递增wrap#，但是递增后的wrap#超过最大值 KSQNMAXVAL(0xffffffff)的时候分以下2种情况

• 未安装19700135补丁的情况就会抛出ORA-00600 [4187]（12.2.0.1之前默认未安装）
• 安装补丁19700135补丁的情况就会抛出ORA-1558（12.2.0.1开始默认安装）

**在12c以上的RAC环境中，如果设置_gc_undo_affinity=FALSE,会让wrap#更快的增长，一般情况下这个参数为了最佳实践关闭DRM特性是设置为FALSE的

这个现象没有补丁修复，只有考虑不要设置_gc_undo_affinity=FALSE

1.监控undo段上的wrap#的增长，当达到一定程度进行undo表空间重建，mos上给出了一个使用率达到90%语句

wrap#的最大值为0xffffffff(转换为10进制为4294967295)，但是数字是用补码进行存储，所以当wrap#递增到0x7fffffff(2147483647)时，下一个值为0x80000000(-2147483648)向-1进行递增，例如-2147483648、-2147483647、-2147483646

** 所以这里sql采用的是****a.ktuxesqn > -429496730 and a.ktuxesqn < 0，也就是使用率达到90%**

select b.segment_name, b.tablespace_name 
         ,a.ktuxeusn "Undo Segment Number"
         ,a.ktuxeslt "Slot"
         ,a.ktuxesqn "Wrap#"
   from  x$ktuxe a, dba_rollback_segs b
   where a.ktuxesqn > -429496730 and a.ktuxesqn < 0
       and a.ktuxeusn = b.segment_id;

2.考虑不要设置_gc_undo_affinity=FALSE

总结建议

本次关于Oracle的缺陷提醒，下面我们尝试梳理如下

wrap#的上限0xffffffff(转换为10进制为4294967295)是一个硬编码值，经Oracle内部设计这个值一般情况下都不会达到上限，在每个版本达到上限时undo都不可用，但是在12c以上的RAC环境中，若设置**_gc_undo_affinity=FALSE,会让wrap#更快的增长，从而达到上限**

⚠️ 综上所述，建议如下：

添加对undo段上的wrap#的监控，当达到90%时进行undo重建