测试环境中,新搭建的Oracle 19c DG,在主备切换后,新的主库的告警日志中一直出现类似下面这样的错误: 在备库上检查参数log_archive_dest_2,fal_server,fal_client等参数。 如上所示,由于参数log_archive_dest_2中设置VALID_FOR=(all_logfiles,all_roles),从而导致备库(standby database)会将redo log & standby redo log发送回主库,从而导致这些消息写入到主库的告警日志当中。其实这里是因为参数不合理设置导致,简单来说,有两个解决方法。请见下面内容。 方法1:在备库上清空参数log_archive_dest_2 方法2:
在备库,将log_archive_dest_2参数的VALID_FOR调整为(ONLINE_LOGFILES,PRIMARY_ROLE) 官方文档Database mount ID mismatch ORA-16009: invalid redo transport destination (Doc ID 1450132.1)中也有相关案例介绍,文档中的例子是因为克隆了备库,但是没有移除DG的相关配置,解决方法如下所示: 本文案例就是因为没有搞清楚DG相关参数的区别,疏忽大意导致的,那么下面就简单将介绍一下VALID_FOR的意义 在DG的配置中,初始化参数LOG_ARCHIVE_DEST_n用来指定redo log的存放位置,可以存放在本地,也可以指定redo transport的位置。其中VALID_FOR属性用来控制日志传输,其格式为:VALID_FOR=(redo_log_type,database_role)。 VALID_FOR属性由2部分组成:archive_source(online_logfile,standby_logfile,all_logfiles)和database_role(primary_role,standby_role,all_role). online_logfile: 表示归档联机重做日志 standby_logfile:表示归档备用数据库的重做日志/接受来自主库的重做日志 all_logfiles: online_logfile && standby_logfile primary_role: 仅当数据库角色为主库时候生效 standby_role: 仅当数据库角色为备库时候生效 all_role: 任意角色均生效 注意事项:没有写VALID_FOR时,默认VALID_FOR=(all_logfiles,all_roles).........................................
2024-07-08T13:40:55.384302+08:00
rfs (PID:146054): Database mount ID mismatch [0x358d50ef:0x358e23cd] (898453743:898507725)
rfs (PID:146054): Client instance is standby database instead of primary
rfs (PID:146054): Not using real application clusters
.........................................原因分析
SQL> show parameter log_archive_dest_2;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_2 string service=gsp lgwr async valid_f
or=(all_logfiles,all_roles) db
_unique_name=gsp
log_archive_dest_20 string
log_archive_dest_21 string
log_archive_dest_22 string
log_archive_dest_23 string
log_archive_dest_24 string
log_archive_dest_25 string
log_archive_dest_26 string
log_archive_dest_27 string
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_28 string
log_archive_dest_29 string
SQL> show parameter fal
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
fal_client string
fal_server string gsp
SQL> 解决方案:
SQL> alter system set log_archive_dest_2='' scope=both;
System altered.SQL> alter system set log_archive_dest_2='service=gsp lgwr async valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=gsp' scope=both;
SQL> alter system set log_archive_dest_n='' scope=both sid='*';- one that points to original Primary
SQL> alter system set fal_server='' scope=both sid='*';
SQL> alter system set fal_client='' scope=both sid='*';知识总结: