断开DataGuard操作产生的问题

前几日,同事在重启一套数据库其中1个节点的CRS时出现问题,数据库instance Mounted后自动Crach,实例被后台进程LGWR KILL掉。数据库信息与特点如下:

Linux x86-64  RAC 2节点,曾经配置过DataGuard但是因为备库IO性能不佳取消了DG配置,将log_archive_config与log_archive_dest_2(我们采用dest_2为DG配置)设置为空(很久以前的事了)。所以数据库长时间都是无DG配置运行。

不巧,今日此库1节点因后台日志报出大量ORA-00600,值班同事决定重启数据库节点尝试修复异常状态,但是发现数据库1节点无法启动,报出如下错误:

DG-1018-1

数据库成功Mount后,被lgwr进程Kill掉进程,并且报出有关log_archive_config 实例间参数不值不一致的错误。 同事将log_archive_config参数设置为’NODG_CONFIG’配置后解决,成功启动了实例,但是问题来了,DG配置已经摘掉了(包括Broker配置),为何还会抛出log_archive_config此参数相关报错?

想到这里,头脑中已经猜测到了一种可能性,准备在一套未投产并且同样为标准安装配置的相同环境下模拟验证:

(1)在主库1节点上尝试断开DG配置:

DG-1018-2

alter system set log_archive_config='' scope=both;
alter system set log_archive_dest_2 ='' scope=both;

--重启数据库CRS:
/opt/app/11.2.0/grid/bin/crsctl stop crs
/opt/app/11.2.0/grid/bin/crsctl start crs

DG-1018-3

与传统认知一致,在主库1节点上更改DG相关配置参数,重启数据库节点并无异常,数据库实例随CRS成功启动。

(2)在主库2节点上更在log_archive_config参数,做一点小小的更改:

alte system set log_archive_config='  ' scope=both;  与(1)节点1不同,多出空格;

重启数据库CRS:

/opt/app/11.2.0/grid/bin/crsctl stop crs
/opt/app/11.2.0/grid/bin/crsctl start crs

DG-1018-5

重启节点1后,模拟出生产库相同报错。

DG-1018-6

把数据库实例重启到nomount状态,并且create pfile=’/tmp/pfile/ora’ from spfile;观察参数文件,发现无论是show parameter config与数据库参数文件,该参数均为空且不存在对多于空格;虽然猜测出可能是此问题导致,并且模拟出了现象,但是此时根本问题并未解决:

在主库1,2节点再次执行,均不起作用,v$dataguard_config数据字典中仍然显示原DG配置,v$dataguard_config视图不再节点间更新,并且如遇到实例启动时仍然会报上图错误导致实例无法启动。

alter system set log_archive_config='' scope=both;
alter system set log_archive_dest_2 ='' scope=both;

只能通过如下方式成功修改后,数据库实例便成功启动,不再抛出ORA-16188: LOG_ARCHIVE_CONFIG settings inconsistent with previously started instance错误

alter system set log_archive_config='NODG_CONFIG' scope=both;

(3)查阅相关Mos文档,找到了一篇针对此问题的描述文档,见下图:

DG-1018-7

DG-1018-8

总结:

(1)针对此问题的产生,断开DG配置时修改DG相关参数时避免在多节点上操作,如果           设置为空只在节点1上操作即可,不要在其他节点上再次配置(哪怕含义相同),             通过测试可避免此问题的发生。如遇到此问题,可以通过设置NODG_CONFIG参             数值解决。

(2)官方建议log_archive_config参数值默认时应设置NODG_CONFIG,配置此值无论           在节点1,2上都不会发生此问题。