rfs : 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



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