I got ” ORA-16401: archive log rejected by Remote File Server (RFS) ” error in Oracle database during Dataguard ( Standby installation )
ORA-16401: archive log rejected by Remote File Server (RFS)
Details of error are in the Alertlog as follows.
2021-02-25T08:44:54.997940+03:00 ORA-16401: archive log rejected by Remote File Server (RFS) 2021-02-25T08:44:55.513300+03:00 ORA-16401: archive log rejected by Remote File Server (RFS) 2021-02-25T08:44:56.310786+03:00 ORA-16401: archive log rejected by Remote File Server (RFS) 2021-02-25T08:44:56.779262+03:00 ORA-16401: archive log rejected by Remote File Server (RFS)
ORA-16401: archivelog rejected by RFS Cause: An attempt was made to re-archive an existing archivelog. This usually happens because either a multiple primary database or standby database(s) or both are trying to archive to this standby database. Action: See alert log and trace file for more details. No action is necessary; this is an informational statement provided to record the event for diagnostic purposes.
Archive log rejected by Remote File Server (RFS)
This ORA-16401 error is related with the Incorrect naming convention for fal_client parameter
Primary shipped particular log seq# to a destination pointed by log_archive_dest_2=p1ncm2_<host>
The standby can do its own GAP analysis and can request logs from the FAL_SERVERS.
The FAL servers, in this case the primary, will try to honor that request.
when standby attempts to resolve a gap, primary gets a different fal_client=p1ncm1_<host>
In effect p1ncm2_<host> and p1ncm1_<host> point the same standby
If we set up fal_client on standby with a different tns alias that we have set at primary’s LADn,
then ORA-16401 is expected.
If the TNS alias had matched, then we would have been able to see that the FAL request from the standby was the same as the FAL request created by regular LADn redo shipping,
and we would not have created the second FRB (FAL Request Block)
Consequently no ORA-16401 would have been reported
In 11gR2 we explicitly say that FAL_CLIENT is optional and should not be used. In which case we use the DB_UNIQUE_NAME of the sender of the request to match up to a LADn. So there would not have been redundant request for the same log seq#.
To Solve this error, Make sure primary's log_archive_dest_n remote desitnation and standby's fal_client share the same tns alias. ---primary -- log_archive_dest_2 service=p1ncm2_<host> optional reopen=60 valid_for=ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=p1ncm2
alter system set fal_client=p1ncm1_<host> scope=both sid='*';
— standby —
Current Parameter Value:- fal_client p1ncm2_<host>
Proposed Parameter Value:- alter system set fal_client=p1ncm2_<host> scope=both sid='*'; ## same as primary's LAD_2
1,078 views last month, 3 views today