会话阻塞关系看ASH

只有一条insert，没有其他update和delete，目前的判断是insert相同的数据导致的lock，一个事务的insert被阻塞，另一个事务insert插入相同数据，产生锁

19c的awr下面部分提供了ash报告，所以你看最下面ash报告部分，你把这两个concurrence的解决了，第一个row cache基本就是你的sequence争用，如果不能调大cache或者对sequence 顺序有严格要求，可以考虑将对这条sql的sequence查询放到其中一个节点上执行，如果可以调大cache，考虑调大cache，再解决你的行锁等待。

尤其你第二个sql，version_count已经到了惊人的4679了，可以设置_cursor_obsolete_threshold，舍弃掉这么多高版本sql，减少父游标mutex争用，也考虑看看sql是否无法共享属于正常范畴。

row cache lock和cursor:mutex x的问题已经解决了，行锁是因为这两个问题导致的，但是具体怎么导致的，我还不清楚。那个sequence跟那个insert语句是在一个事务里面，由于sequence的问题，导致当前事务还未结束，另一个事务插入相同的数据导致lock，不知道是不是因为这个原因。我测试过，在有主键的情况下，insert相同数据会产生lock

不同的事务获取的 sequence.next_value应该是不同的 所以应该不存在插入相同的序列，是不是代码的问题导致获取序列和执行插入不在一个事务里

sequence这个序列是用于另外一个表，，不是用于insert那个语句，insert语句执行的时候，同时会有更新插入其它表的操作，更新插入其它表的时候才用到这个序列，只不过他们是在一个事务中执行的