ORA-16401: archive log rejected by Remote File Server (RFS)

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

Do you want to learn more details about Dataguard, then Click this Link and read the articles.

Oracle DataGuard Physical Standby Installation Step by Step Using RMAN -1