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

潇湘隐者發表於2024-07-08
Database

測試環境中，新搭建的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)

相關文章