Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Log gaps on standby and multiple log_archive_dests

Log gaps on standby and multiple log_archive_dests

From: Montgomerie Steve <>
Date: Wed, 7 Apr 2004 11:35:22 -0400
Message-ID: <>

Content-Type: text/plain
Good day all,  

Here's what we've got

2 node Rac Cluster on Win2k with a single instance hot standby.

log_archive_dest_1 : exists on the san shared by both instances, limited space,
rman backs up logs and deletes from that dir twice a day

log_archive_dest_2 : exists on the local file system of each node. Has lots of space, we keep archive logs there for 7 days

log_archive_dest_3 SERVICE='STBY'.... ships logs to the standby

Occasionally a gap will get detected on the standby and Oracle will automatically detect the gap and resend or send the required log to the hot standy.

For whatever reason Oracle has for the past two months always chosen log_archive_dest_2 where there are lots of logs. I can see in the alert log that
the gap is detected and that the logs from log_archive_dest_2 are sent over to
the standy.

Last week Oracle detected a gap and tried to sync up the hot standby. This time
it looked in log_archive_dest_1, the logs had been deleted and the alert log

repeated with 'can't find file' referring to log_archive_dest_1 and my standy
fell behind.

How can I tell Oracle to look in log_archive_dest_n when reconcilling gaps in
the standby or at least to look in all valid log_archive_dest_n destinations?

Even if I set Fal Server/CLient (they are not set now) I would just provide service names to those parms. So by setting those parms I don't see how that

would help me in my particular set of circumstances  

Steve Montgomerie
PeopleSoft/Oracle Administrator
SIEMENS Shared Services, LLC
4400 Alafaya Trail, M/S AL-222
Orlando, FL 32826
Phone: 407 487-5219
Cell : 407 810-8387
Fax: 407 487-5833  

Please see the official ORACLE-L FAQ:

To unsubscribe send email to: put 'unsubscribe' in the subject line.

Archives are at FAQ is at
Received on Wed Apr 07 2004 - 13:42:56 CDT

Original text of this message