I'm not sure when this started, but for the time being the primary database instances in a physical standby configuration logs this message on every redo log switch.

LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2
LGWR: Standby redo logfile selected to archive thread 2 sequence 306
LGWR: Standby redo logfile selected for thread 2 sequence 306 for destination LOG_ARCHIVE_DEST_2

I'm not sure what this indicates, but I do associate this message with a standby database becoming available after downtime or network outage. E.g. the (optional) archive destination was deferred, but has now become active.

Similarly, on the standby instance, I'm seeing the following on every log switch:

Primary database is in MAXIMUM PERFORMANCE mode
Re-archiving standby log 6 thread 2 sequence 308
RFS[212]: Assigned to RFS process 8304
RFS[212]: Selected log 8 for thread 2 sequence 309 dbid 18783000 branch 804771032

Again, this is a log message I associate with a disruption in the delivery of archived redo logs or a change of delivery mode (changing the log destination parameters or the protection mode).

Any idea what may be causing these to be logged repeatedly on every log switch?


I now have a working theory: I think this will happen if real time apply have been used at all, and thus indicates that LGWR is waking up to do some archival work. Previously, I believe ARCH would take care of log transport and archival but activating real time apply may have forced a configuration change.

So far, I have found no evidence of this change being visible in data dictionary or parameter set, just the changes in alert log messages (which happened to coincide with a test involving real time apply on the standby).

If this is the case, any idea how to reverse the change now that real time log apply is disabled and no longer required?


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.