LGWR process on standby database

From: <mylesv_at_gmail.com>
Date: 18 Oct 2006 17:15:30 -0700
Message-ID: <1161216930.037701.59350@m7g2000cwm.googlegroups.com>

Oracle 9i EE (9.2.0.1.0)

I'm wondering why there's a LGWR process running on my physical standby database given that ARCH on the primary ships the archived redo to the standby, and MRP on the standby applies the redo.

Also, I believe this LGWR process is preventing me from dropping the redo log groups on the standby. (Why do I want to drop them? I recently did some tuning on the primary that involved creating larger redo log groups, and I want to do the same on the standby.) I get an ORA-1624 when I try to drop them. Unix "fuser" confirms that the redo log files are not open by any processes, and they haven't been modified since the last time the standby was in the primary role (about eight months ago).

So, what the heck is holding on to these logs? Why does Oracle insist that these are necessary for crash recovery?

Here are the relevant bits of config. from my primary:

log_archive_dest_1='location=/oradata/ICAS/arc mandatory'
log_archive_dest_state_1=ENABLE
log_archive_dest_2='service=ICAS_AUS OPTIONAL'
log_archive_dest_state_2=ENABLE
log_archive_format=%t_%s.dbf
log_archive_start=true
log_archive_max_processes = 8

ARCHIVE_LAG_TARGET = 1800
remote_archive_enable=SEND

and from my standby:

log_archive_dest_1='location=/oradata/ICAS/arc mandatory'
log_archive_dest_state_1=ENABLE
log_archive_format=%t_%s.dbf
log_archive_start=true
log_archive_max_processes = 8

standby_archive_dest='/oradata/ICAS/arc' standby_file_management=AUTO
remote_archive_enable=RECEIVE
FAL_SERVER=ICAS_ALB
FAL_CLIENT=ICAS_AUS
ARCHIVE_LAG_TARGET = 1800 I suspect that if I change roles, the redo files will be generated automatically on the standby. I'm not about to try that at this point.

Thanks!
Myles Received on Wed Oct 18 2006 - 19:15:30 CDT