Information About Redo Transport Services

If you use dataguard, you have also other choice than standby database, but of course, it will probably be the most important part of the system. But if you want, we can also configure dataguard to transport the log to a stagging server, which is a staging disk on a remote computer.

For a maximum protection mode or maximum availability, we should use :

LOG_ARCH_DEST_x

with these attributes :

LGWR SYNC AFFIRM

They respectiv meaning are :

Use log writer process to transport the archived log.

This is the "LGWR" that copy the redo data to the REDO LOG, see this pictures taken from [http://www.oracle.com] :

basicarch.gif

In a primary database, we can choose between ARCx or LGWR to transmit redo log data to a standby database. In a very busy database, we will probably use the ARCx process to transmit the redo log data, as LGWR will already be very busy by writting the redo data in the redo log. (to be confirm).

  • Note : ARCx can only be used if we are in MAXIMUM PERFORMANCE mode, otherwise we have to use LGWR. Seems normal, as LGWR is the process that commit a transaction, and hence in MAXIMUM PROTECTION a transaction is commit only it has been writted also on the standby database.

By default, this is the ARCx process that transmit the arch redo data to a local destination or to a remote destination.
We can alter, dynamicaly or in initialization file, the number of ARCx process.

sqlplus>alter system set LOG_ARCHIVE_MAX_PROCESSES = 20;

A normal configuration with dataguard will look like this one : (picture taken from [http://www.oracle.com])

default_archiving_prim_stdb.gif

We can use this view to known which arch log was received on standby database :

v$archived_log

like that we now are able to known which arch log can be deleted on the primary database.

If you want, you can change almost all parameter of :

LOG_ARCHIVE_DEST_x

of

LOG_ARCHIVE_DEST_STATE_x

by executing this command in sqlplus with the right parameter :

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=boston
2> VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)';
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;

Notice that this changes will only taken into account at the next log switch, a changed scn or you can force this changes to be in effect now, by doing :

alter system switch logfile;

You simply do a log switch earlier than normal. If you want to see the actual setting of LOG_ARCH_DEST_x, you can query this view :

v$archive_dest

If we specify the option :

  • LGWR
  • SYNC

for a destination, a transaction will only comit, if the redo data are trasmitted to this destination (local or remote I think). So, be carreful when using this option.

Note
by default LGWR use SYNC option, so we don't need to specify it. But we can disable it by specifying ASYNC.

Here is an example when we use LGWR and SYNC, picture taken from [http://www.oracle.com] :

lgwr_sync.gif

Avec ASYNC option, the process LSNx collect his data from the REDO LOG, and so LGWR process doesn't wait anymore that LSNx complete his transmittion on the remote standby database.

lgwr_async.gif
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License