Oracle-主备切换问题(BUG-31747989)

背景:

        用户在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

猜你喜欢

转载自blog.csdn.net/sinat_36757755/article/details/130190161