这几天一个网友有个比较怪异的小问题，咨询了我。简单分析了一下，感觉有点小意思，给大家分享一下；毕竟现在使用Oracle 19c的用户还是非常的多。
话不多说，我们来看看网友的问题（欢迎大家提供素材，免费分析），据反馈某个业务操作正常情况下很快就完成，在故障当天被卡了几个小时没完成，最后不得不kill进程，重新来过。我们先来看看网友提供的AWR报告。
从awr报告来看，主要是是gc current retry，进一步看看反馈的应用操作是什么？
看上去是一个JDBC过来的应用操作，那么进一步看看SQL是什么？有没有可能是SQL性能很挫呢？
看上去这个sql主要是在等待gc current retry，说明awr里面gc等待主要是这个sql导致的，该等待事件的p1,p2,p3分别表示file#,block#,retry次数。实际上就这个等待事件而言，跟gc cr failre,gc current block lost等差不多，通常表示集群心跳通信质量较差，还有一种可能是负责数据传输的LMS进程有异常或者被阻塞。如果要判断是不是这个影响，那么怎么办呢？实际上非常简单，看看awr的rac 心跳相关数据不就知道了么？
从目前来看，心跳相关指标都是正常的，大家别看后面的数据很大，实际上我们要注意的是：这里单位是us，而不是ms。从这个角度来看，基本上都低于1ms，所以大家可以忽略这个原因了。其次，我们还要注意，如果是集群心跳出问题，那受影响的应该是全局应用，而不是个别业务。
如果要看单个SQL具体是什么问题，那么还可以使用awrsqlrpt，比如：
从awr sqlreport来看，这个sql主要执行了1次，产生了3个物理读，主要等待在cluster wait time(ms)上。具体的SQL 文本这里就补贴了，就是一个简单的create table xxx as select * from xxx where 11; 本质上是个小表甚至空表。
后面我让网友查了一下这个会话的情况，发现该进程所呈现的等待事件event p3就没动过，那么这说明什么问题呢？
SQL性能没问题，集群没问题，那么 只有一个解释：Oracle Bug。
后面我搜了一下，还真有一个Bug，现象基本符合。而且网友的数据库版本也是Oracle 19.7.
大家注意看这个Bug文档的描述，提示受影响的版本是12.1+的版本，但是后面我查询Patch发现，实际上在Oracle 11.2.0.4版本都存在该问题，因为Oracle 提供了对应版本的补丁。
从这一点来看，MOS文档描述也并非100%准确。
