背景:

        用户在Oracle Rac 19.6版本通过switchover方式进行主备切换，在备切主完成之后，进行open的过程中，状态长时间无法完成疑似hang住。

问题:

​        Oracle Rac 19.6版本通过switchover方式进行主备切换,切换完成之后进行open，状态长时间无法完成疑似hang住，后台日志显示Sleep 160 seconds and then try to clear SRLs in 7 time(s)

问题分析:

        查看当前会话的等待情况，数据库的会话都被SID=1的会话所等待，会话(SID=1)当前为P00H并行恢复进程，等待事件为row cache lock,正在被SID=2440的会话所堵塞

        查看SID=2440的会话，当前为P00X并行恢复进程，等待事件为cursor:pin s wait on x,正在被会话SID=1所堵塞，两个会话出现相互等待的情况

        怀疑是并行恢复出现了bug，尝试将并行进程的初始化参数parallel_min_servers设置为0，然后重新open，问题还是继续出现

ALTER SYSTEM SET parallel_min_servers=0 SCOPE=BOTH;

        接下来尝试另一种方法，将SID=1的会话kill掉，因为从分析来看，该会话是主要的堵塞源头

​​alter system kill session '1,53726';

        会话查杀完成之后，数据库open完成，从alert日志看，当时并行恢复进程正在做的是undo initialization recovery

问题原因:

        事后，在Oracle的mos上查找相关的bug，发现了文章After Switch /Failover Primary Instance Open hangs Because Of SRL Cleanup (Doc ID 2710349.1)描述的BUG-31747989与当前的案例匹配，在Oracle19.2之后的版本，switchover/failover之后open主库hangs clearing SRL由未公开的BUG 31747989所引发        

        Oracle官方给出的解决方式有两个，一个是应用oneoff补丁31747989进行解决，这个补丁目前发现在较新的RU补丁版本已经被包含，从侧面也说明低版本RU补丁的潜在风险

        另一种方式是通过设置隐含参数_min_undosegs_for_parallel_fptr=0进行规避

​alter system set "_min_undosegs_for_parallel_fptr"=0 scope=both sid='*' 

        查看这个隐含的含义，我们可以推测隐含参数规避的方式通过禁用undo segment的首次并行恢复

NAME                                 DESCRIPTION
-------------------------------- ------------------------------------------- 
_min_undosegs_for_parallel_fptr    minimum undo segments for parallel first-pass recovery