Alert log file - FAL archive failed, see trace file.

[Former Member]

Dear all,

Another error on my alert log file:

ARC0: Archive log rejected (thread 1 sequence 91879) at host 'PRD_STANDBY'

FAL[server, ARC0]: FAL archive failed, see trace file.

ARCH: FAL archive failed. Archiver continuing

ORACLE Instance PRD - Archival Error. Archiver continuing.

The archivelogs shipping is working fine, just checked if they are automatically applied on standby --- and no issues.

On primary, I have:

SQL> show parameter FAL_CLIENT;

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

fal_client                           string      PRD_PRIMARY

SQL> show parameter LOG_ARCHIVE_DEST_2;

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

log_archive_dest_2                   string      SERVICE=PRD_STANDBY COMPRESSIO

                                                 N=ENABLE optional reopen=60 ma

                                                 x_connections=5

On standby I have:

SQL> show parameter FAL_CLIENT;

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

fal_client                           string      PRD_STANDBY

SQL> show parameter LOG_ARCHIVE_DEST_2;

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

log_archive_dest_2                   string      SERVICE=PRD_PRIMARY COMPRESSIO

                                                 N=ENABLE optional reopen=60 ma

                                                 x_connections=5

Thanks in advance for some ideas,

J.

[Reagan · Accepted solution]

Hello

It is definitely not an archiving file system full. If it was the case then you would see archiver stuck messages in the alert log.

This is due to a bug and Oracle suggests to ignore these messages appearing in the Alert log as long as the Primary and Standby are in sync.

RC3: Archive log rejected (thread 1 sequence 136480) at host '(DESCRIPTION=  (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.26)(PORT=1530))(CONNECT_DATA=(SERVICE_NAME=sdbinfo)(SERVER=DEDICATED)))'

Errors in file /opt/dbinfo/diag/rdbms/dbinfo/dbinfo/trace/dbinfo_arc3_7445.trc:

ORA-16401: archivelog rejected by RFS

FAL[server, ARC3]: FAL archive failed, see trace file.

Errors in file /opt/dbinfo/diag/rdbms/dbinfo/dbinfo/trace/dbinfo_arc3_7445.trc:

ORA-16055: FAL request rejected

ARCH: FAL archive failed. Archiver continuing

ORACLE Instance dbinfo - Archival Error. Archiver continuing.

- RedoLog switch happens very frequently before the above Error reported

- The requested ArchiveLog by FAL requests the current Log Sequence or the Sequence currently being archived

Changes

The Problem here is that the Primary Database is switching Logs too frequently.

Using ARCH to send the archives, every time there's a log switch the Primary has to send the Archivelog to the Standby, meanwhile another Log Switch occurred on the Primary which causes also another Archivelog to be sent to the Standby, but the first one has not finished yet, a GAP is formed and detected by the Standby. At this Time the first Archivelog is also sent as FAL Request, but this one will fail because the first one is still being archiving, locked, so the second one fails.

Solution

    Ignore these Messages as long as the Standby Database keeps synchronized with the Primary

    Database Increase the Size of the Online Redologs to reduce Redolog Switch Frequency

    Increase Network Bandwith between the Primary and Standby Database

Cheers

RB

[Former Member · Accepted solution]

Many thanks Reagan for such a detailed explanation

[stefan_koehler · Accepted solution]

Hi Jordan,

that explanation would fit to your issue, if you are using ARCH as redo transport mode. Unfortunately your database version is missing, but ARCH is deprecated since Oracle 11.1.

Oracle Documentation: http://docs.oracle.com/cd/B28359_01/server.111/b28294/whatsnew.htm

The ARCH redo transport mode has been deprecated
The ARCH redo transport mode has been deprecated and will be desupported in a future release. Oracle recommends that you switch to the ASYNC transport mode if you are currently using the ARCH transport mode. The ASYNC transport mode is superior to the ARCH transport mode in all respects, and is the new default transport mode.

I assume that you are already using Oracle 11g - and in this case (regarding your posted configuration) you are using ASYNC as transport mode.

Oracle Documentation: http://docs.oracle.com/cd/E11882_01/server.112/e25608/log_arch_dest_param.htm#i78506

The redo data generated by a transaction need not have been received at a destination that has the ASYNC attribute before that transaction can commit. This is the default behavior if neither SYNC or ASYNC is specified.

LGWR ASYNC

Regards

Stefan

[former_member188883]

Hi Jordan,

Do we have archiver full situation on PRD instance ?

Regards,

Deepak Kori

[Former Member]

Hello Deepak,

What do you mean by that ?

Thanks,

J.

[former_member206552]

Hi Jordan,

can you check the location of log_archive_dest_1 on PRD and make sure the file system is not full

Best Regards

Marius

[Former Member]

Hello Marius,

primary & stby:

SQL> show parameter log_archive_dest_1;

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

log_archive_dest_1                   string      LOCATION=/oracle/PRD/oraarch/P

                                                 RDarch MANDATORY

The FS is just 12% used, so no probs there

Tx

[former_member206552]

Jordan,

ok can you upload the trace ?

have a look at the following tread and see if this helps

https://forums.oracle.com/forums/thread.jspa?threadID=2244122

also have you tried this ?

source : http://manidba.wordpress.com/2012/12/12/ora-16055-fal-request-rejected-arch-fal-archive-failed-archi...

Problem:

We have environment with Primary and Active standby Dataguard.   For some reason storage on Dataguard is crashed and I had rebuild the Dataguard DB from backup.  Noticed Archive log is not being shipped and when I look at alert log  found following errors.

FAL[server, ARC3]: FAL archive failed, see trace file.
Errors in file /local/opt/oracle/diag/rdbms/xnodbcor/XNODBCOR1/trace/XNODBCOR1_arc3_2216.trc:
ORA-16055: FAL request rejected
ARCH: FAL archive failed. Archiver continuing
ORACLE Instance XNODBCOR1 – Archival Error. Archiver continuing.

Checked parameter values on archive_dest on primary DB and noticed “RESET” value assigned to ” log_archive_dest_state_1″

log_archive_dest_state_1         string     RESET

Solution:

Enabled the dest_1 as below, that fixed the problem.   Error disappeared and logs are being shipped and applied on Standby site.

SQL> alter system set log_archive_dest_state_1=enable;

System altered.

SQL> alter system switch logfile;

System altered.

SQL>

best regards

marius