rfs (PID:146054): Database mount ID mismatch案例

测试环境中，新搭建的Oracle 19c DG，在主备切换后，新的主库的告警日志中一直出现类似下面这样的错误：

.........................................
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
.........................................

原因分析

在备库上检查参数log_archive_dest_2，fal_server，fal_client等参数。

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> 

如上所示，由于参数log_archive_dest_2中设置VALID_FOR＝(all_logfiles,all_roles)，从而导致备库(standby database)会将redo log & standby redo log发送回主库，从而导致这些消息写入到主库的告警日志当中。其实这里是因为参数不合理设置导致，简单来说，有两个解决方法。请见下面内容。

解决方案：

方法1：在备库上清空参数log_archive_dest_2

SQL> alter system set log_archive_dest_2='' scope=both;

System altered.

方法2： 在备库，将log_archive_dest_2参数的VALID_FOR调整为(ONLINE_LOGFILES,PRIMARY_ROLE)

SQL> alter system set log_archive_dest_2='service=gsp lgwr async valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=gsp' scope=both;

官方文档Database mount ID mismatch ORA-16009: invalid redo transport destination (Doc ID 1450132.1)中也有相关案例介绍，文档中的例子是因为克隆了备库，但是没有移除DG的相关配置，解决方法如下所示：

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='*';

知识总结：

本文案例就是因为没有搞清楚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)