I have a oracle 11g (11.3) database running with two standby databases (at different locations) in Maximum performance mode. The platform is Linux.

Log transport parameters are:

log_archive_dest_5 string SERVICE= * * * * **ASYNC NOAFFIRM** valid_for= ... **

Correct me if i'm wrong, so ASYNC noaffirm means the log transfer method is ARCH right? Meaning the archives generated in primary gets copied to standby and then applied there. Right?

The database is primary has been generating too much archives beccause of which my DR lags behind when archives are more. Oracle MOS asks me to create standby redo to resolve the same. My question is that how will standby redo help in reducing the lag since the SRL is used so as not to lose data in case of disaster right?

Also, SRL should be used only when the parameter is LGWR right? Since i have mentioned it as ASYNC NOAFFIRM and there is no standby, the archives are only sent to DR and not redo.

IF I do not have Standby redo, then how does redo gets shipped? Does it gets shipped as archive logs from primary to standby's archive directly and gets applied?

Help me clear out my doubts. Thanks!

  • In 11.2, LNS does the log transport, not ARCH or LGWR (those parameters are no longer documented for >= 11.something).
    – Mat
    Aug 30, 2015 at 8:34
  • then how does my primary ship its redo in my case? I have mentioned it as ASYNC - and since I do not have standby redo logs enabled, through what way redo gets shipped to dr.?
    – tesla747
    Aug 30, 2015 at 8:41

1 Answer 1


NOAFFIRM means the redo transport will be acknowledged before writing the received redo to disk (standby redo logs).

ASYNC noaffirm means the log transfer method is ARCH right?

No, it does not. Without specifying LGWR or ARCH, LGWR is the default. You can check it on the primary database by:

select archiver from v$archive_dest where dest_id = 5;

There you should see LGWR. However, specifying ARCH or LGWR became deprecated in 11g:


Deprecated does not mean it will not work, so it is still possible to specify ARCH in log_archive_dest_n and revert to the way it worked in 10.2 (and what you described). But that is not how you configure MAXIMUM PERFORMANCE anymore, because of the changes, even MAXIMUM PERFORMANCE uses LGWR and standby redo logs. See below:


The synchronous and asynchronous redo transport modes require that a redo transport destination have a standby redo log.

  • if LGWR is the default, I do not have SRL in my standby databases, then how does the redo gets shipped? archives has to get shipped to the standby and then applied right?
    – tesla747
    Aug 30, 2015 at 8:40
  • 1
    @tesla747 As it was pointed out in a comment to your question, the transport is actually not done by LGWR, but redo transport processes. If you check the CLIENT_PROCESS, CLIENT_PID from V$MANAGED_STANDBY, you will see LGWR and a PID number. If you check that PID number on the primary host, that process will not be the LGWR, but a NSAx background process, which is a redo transport process for asynchronous destinations. Aug 30, 2015 at 9:14
  • alright got it. so LGWR is being used, but how does the redo gets shipped? so the LGWR ships the redo to the standby and how does it apply there if there are no standby redo logs?
    – tesla747
    Aug 30, 2015 at 9:22
  • select archiver from v$archive_dest where dest_id = 5; I have checked this, It gives me as ARCH. So if I have AYSNC noaffirm without anything mentioned, it has to be LGWR but here it is ARCH. ??
    – tesla747
    Aug 31, 2015 at 10:27
  • @tesla747 Well, it is LGWR on my sandbox environment. Aug 31, 2015 at 10:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.