标题: rfs : Database mount ID mismatch [打印本页] 作者: 刘泽宇 时间: 2024-10-20 10:35 标题: 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;
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='*';