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)

扫描上面二维码关注我
如果你真心觉得文章写得不错,而且对你有所帮助,那就不妨帮忙“推荐"一下,您的“推荐”和”打赏“将是我最大的写作动力!
本文版权归作者所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接.