FranklinFaces.com - Oracle & SQL Server Database Forums for all IT Professionals / Oracle Forum / ORA - Oracle Database Error Codes - Search via specific error codes. / ORA-10560 Through ORA-19999 / ORA-16009: remote archive log destination must be a STANDBY database ora error / Latest Posts

RE: ORA-16009: remote archive log destination must be a STANDBY database ora error

Admin — Thu, 14 May 2009 16:32:20 GMT

Just an FYI, I did that on the STANDBY database not the primary. Don't do that on the PRIMARY or it will stop shipping the archive logs all together.

Cheers,

RE: ORA-16009: remote archive log destination must be a STANDBY database ora error

Admin — Thu, 14 May 2009 16:29:43 GMT

I figured this out. It was a simple fix. The previous dba that was managing this database did a manual switchover and back.

The standby database still had the log_archive_dest_2 pointing to the primary while it was a standby and applying logs.

I updated log_archive_dest_state_2 and it stopped.

# sqlplus '/ as sysdba'

SQL*Plus: Release 9.2.0.8.0 - Production on Thu May 14 16:16:52 2009

Connected to:
Oracle9i Enterprise Edition Release 9.2.0.8.0 - Production
With the Partitioning option
JServer Release 9.2.0.8.0 - Production

SQL> alter system set log_archive_dest_state_2=defer;

System altered.

SQL> exit

tail -200 alert*.log

Media Recovery Log /u01/oradba/admin/PRDSTDBY/arch/PRDSTDBY_T1_S75807.arc
Media Recovery Waiting for thread 1 seq# 75808
Thu May 14 16:05:56 2009
Errors in file /u01/oradba/admin/PRDSTDBY/bdump/PRDSTDBY_arc0_14447.trc:
ORA-16009: remote archive log destination must be a STANDBY database
Thu May 14 16:11:56 2009
Errors in file /u01/oradba/admin/PRDSTDBY/bdump/PRDSTDBY_arc0_14447.trc:
ORA-16009: remote archive log destination must be a STANDBY database
Thu May 14 16:17:52 2009
ALTER SYSTEM SET log_archive_dest_state_2='DEFER' SCOPE=MEMORY;
Media Recovery Log /u01/oradba/admin/PRDSTDBY/arch/PRDSTDBY_T1_S75808.arc
Media Recovery Log /u01/oradba/admin/PRDSTDBY/arch/PRDSTDBY_T1_S75809.arc
Media Recovery Log /u01/oradba/admin/PRDSTDBY/arch/PRDSTDBY_T1_S75810.arc
Media Recovery Log /u01/oradba/admin/PRDSTDBY/arch/PRDSTDBY_T1_S75811.arc
Media Recovery Waiting for thread 1 seq# 75812
Media Recovery Log /u01/oradba/admin/PRDSTDBY/arch/PRDSTDBY_T1_S75812.arc
Media Recovery Log /u01/oradba/admin/PRDSTDBY/arch/PRDSTDBY_T1_S75813.arc
Media Recovery Log /u01/oradba/admin/PRDSTDBY/arch/PRDSTDBY_T1_S75814.arc
Media Recovery Log /u01/oradba/admin/PRDSTDBY/arch/PRDSTDBY_T1_S75815.arc
Media Recovery Log /u01/oradba/admin/PRDSTDBY/arch/PRDSTDBY_T1_S75816.arc
Media Recovery Waiting for thread 1 seq# 75817

Hope this helps.

ORA-16009: remote archive log destination must be a STANDBY database ora error

stacyliang83 — Tue, 05 May 2009 10:58:07 GMT

I'm in a weird situation. The dba before i joined this company setup the dataguard environment and although it's applying the logs successfully, I see these messages in the alert log. It's annoying.

PRIMARY:

Tue May 5 10:47:10 2009
RFS: Possible network disconnect with primary database
RFS: Destination database mount ID mismatch [0x9a40bd93:0x9a5d198b]
RFS: client instance is standby database instead of primary
RFS: Not using real application clusters
Tue May 5 10:53:10 2009
RFS: Possible network disconnect with primary database
RFS: Destination database mount ID mismatch [0x9a40bd93:0x9a5d198b]
RFS: client instance is standby database instead of primary
RFS: Not using real application clusters

STANDBY:

Errors in file /u01/oradba/admin/PRDSTDBY/bdump/PRDSTDBY_arc0_14447.trc:
ORA-16009: remote archive log destination must be a STANDBY database
Media Recovery Log /u01/oradba/admin/PRDSTDBY/arch/PRDSTDBY_T1_S75345.arc
Media Recovery Waiting for thread 1 seq# 75346
Tue May 5 09:48:08 2009
Errors in file /u01/oradba/admin/PRDSTDBY/bdump/PRDSTDBY_arc0_14447.trc:
ORA-16009: remote archive log destination must be a STANDBY database
Tue May 5 09:54:08 2009
Errors in file /u01/oradba/admin/PRDSTDBY/bdump/PRDSTDBY_arc0_14447.trc:
ORA-16009: remote archive log destination must be a STANDBY database
Tue May 5 10:00:08 2009

Can't seem to figure it out. Any help is appreciated.