Oracle 19c hang ‘TTnn Sleep 10 seconds and then try to clear SRLs in N time(s)’ wait ‘row cache lock’ & ‘cursor: pin S wait on X’
环境oracle 19c(19.7) on linux, 数据库做了failover后在open resetlogs数据库时，等待了很久的时间，数据库里查询wait event是’row cache lock’ & ‘cursor: pin S wait on X’， DB alert log显示下面的信息:可以看到不断的在输出TTnn Sleep 10 seconds and then try to clear SRLs in N time(s)， TTnn进程为异步模式下的REDO传输进程， 在清理standby redo log时hang, 还出现了row cache enqueue生成了SSD（system state dump）trace
Oracle 12C wait ‘library cache lock’ after change password even set 28401 event 案例
主要是在11g引入的安全特性延迟密码认证在3-10秒，在延迟期间以X模式持有row cache lock防止同一用户的并发失败尝试。通常是配置28401 event禁用延迟认证特性,但这也不是“万能药”，像这次的案例。 除了密码延迟认证，PASSWORD_LIFE_TIME和FAILED_LOGIN_ATTEMPTS 也是用户的警惕的地方。
Troubleshooting performance wait event ‘row cache lock’
Row Cache 或 Data Dictionary Cache 是共享池中的一个内存区域，用于保存数据字典信息以减少数据字典表的物理 I/O。行高速缓存锁主要用于序列化对数据字典的更改，当需要对数据字典高速缓存进行锁定时，将等待该锁,数据字典行上的锁称为row cache lock。等待此事件通常表示发生了某种形式的 DDL，或者可能是递归操作，例如存储管理和递增序列号。
Troubleshoot DDL递归SQL触发的row cache lock deadlock(死锁)
两个同时启动的JOB， truncate 了不同的对象DDL， 递归触发了DDL trigger的审计操作，在insert DDL日志表时，遇到了回收站空间再利用，再次递归触发了drop table BIN$ purge, 又属于DDL操作, 并且申请的回收站对象的row cache enqueue时，在2个跨实例会话互相等待对方持有对象lock造成死锁
