Redo transport uses Oracle Net sessions to transport redo data.

These redo transport sessions are authenticated using either the Secure Socket Layer (SSL) protocol or a remote login password file.

To specify a redo transport destination, use the LOG_ARCHIVE_DEST_n database initialization parameter (where n is an integer from 1 to 31).

DB_UNIQUE_NAME=BOSTON
LOG_ARCHIVE_CONFIG='DG_CONFIG=(BOSTON,CHICAGO,HARTFORD)' 
LOG_ARCHIVE_DEST_2='SERVICE=CHICAGO ASYNC NOAFFIRM VALID_FOR=(ONLINE_LOGFILE, 
PRIMARY_ROLE) REOPEN=60 COMPRESSION=ENABLE  DB_UNIQUE_NAME=CHICAGO' 
LOG_ARCHIVE_DEST_STATE_2='ENABLE' 
LOG_ARCHIVE_DEST_3='SERVICE=HARTFORD SYNC AFFIRM NET_TIMEOUT=30 
VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE) REOPEN=60 COMPRESSION=ENABLE   
DB_UNIQUE_NAME=HARTFORD' 
LOG_ARCHIVE_DEST_STATE_3='ENABLE'

Redo transport destination must be configured to receive and to archive redo data from a redo source database.

See the following:

• Managing Standby Redo Logs

• Cases Where Redo Is Written Directly To an Archived Redo Log File

These steps describe how to configure a terminal destination.

1. Select a physical standby database to configure as a cascading standby database.
2. On the cascading standby database, configure the FAL_SERVER database initialization parameter with the Oracle Net alias of the primary database or of a standby database that receives redo directly from the primary database.
3. On the cascading standby database, configure a LOG_ARCHIVE_DEST_n database initialization parameter for one or more terminal destinations. Configure the SERVICE attribute of this destination with the Oracle Net alias of the terminal destination, and the VALID attribute to be valid for archival of the standby redo log while in the standby role.

   If you specify ASYNC transport mode on destinations 1 through 10, then redo is shipped in real-time. If you do not specify a transport mode or you specify SYNC on destinations 1 through 10, then redo is shipped in non-real-time. Destinations 11 through 31 operate only in ASYNC (real-time) transport mode.

4. At the terminal destination, configure the FAL_SERVER database initialization parameter with the Oracle Net alias of the cascading standby database or of another standby database that is directly connected to the primary database. Although it is also possible to specify the primary database, this would defeat the purpose of cascading, which is to reduce the redo transport overhead on the primary database.
5. Example 7-1 shows some of the database initialization parameters used by the members of an Oracle Data Guard configuration that includes a primary database named boston that sends redo to a local physical standby database named boston2, which then cascades primary database redo to a remote physical standby database named denver.

   A LOG_ARCHIVE_DEST_n database initialization parameter could also be configured on database boston that is valid for standby redo log archival to database denver when database boston is in the standby role. This would allow redo cascading to database denver to continue if a switchover is performed between database boston and database boston2.

DB_UNIQUE_NAME=boston
 
FAL_SERVER=boston2
 
LOG_ARCHIVE_CONFIG='DG_CONFIG=(boston,boston2,denver)'
 
LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston'
 
LOG_ARCHIVE_DEST_2='SERVICE=boston2 SYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston2'

DB_UNIQUE_NAME=boston2
 
FAL_SERVER=boston
 
LOG_ARCHIVE_CONFIG= 'DG_CONFIG=(boston,boston2,denver)'
 
LOG_ARCHIVE_DEST_1='LOCATION= USE_DB_RECOVERY_FILE_DEST
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston2'
 
LOG_ARCHIVE_DEST_2= 'SERVICE=denver
VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=denver'
 

DB_UNIQUE_NAME=denver
 
FAL_SERVER=boston2
 
LOG_ARCHIVE_CONFIG='DG_CONFIG=(boston,boston2,denver)'
 
LOG_ARCHIVE_DEST_1='LOCATION= USE_DB_RECOVERY_FILE_DEST
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=denver'

A Data Guard configuration can be set up to cascade to a single physical standby or to multiple physical standbys.

See the following topics:

• Cascading to a Physical Standby

• Cascading to Multiple Physical Standbys

You can query views to monitor redo transport status on a redo source database.

1. Perform the following query on the redo source database to determine the most recently archived sequence number for each thread:

   SQL> SELECT MAX(SEQUENCE#), THREAD# FROM V$ARCHIVED_LOG -
   > WHERE RESETLOGS_CHANGE# = (SELECT MAX(RESETLOGS_CHANGE#) FROM V$ARCHIVED_LOG) -
   > GROUP BY THREAD#;
   

2. Perform the following query on the redo source database to determine the most recently archived redo log file at each redo transport destination:

   SQL> SELECT DESTINATION, STATUS, ARCHIVED_THREAD#, ARCHIVED_SEQ# -
   > FROM V$ARCHIVE_DEST_STATUS -
   > WHERE STATUS <> 'DEFERRED' AND STATUS <> 'INACTIVE';
    
   DESTINATION         STATUS  ARCHIVED_THREAD#  ARCHIVED_SEQ#
   ------------------  ------  ----------------  -------------
   /private1/prmy/lad   VALID                 1            947
   standby1             VALID                 1            947
   

   The most recently archived redo log file should be the same for each destination. If it is not, a status other than VALID may identify an error encountered during the archival operation to that destination.

3. Perform a query at a redo source database to find out if an archived redo log file has been received at a particular redo transport destination. Each destination has an ID number associated with it. You can query the DEST_ID column of the V$ARCHIVE_DEST view on a database to identify each destination's ID number.

   Assume that destination 1 points to the local archived redo log and that destination 2 points to a redo transport destination. Perform the following query at the redo source database to find out if any log files are missing at the redo transport destination:

   SQL> SELECT LOCAL.THREAD#, LOCAL.SEQUENCE# FROM -
   > (SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=1) -
   > LOCAL WHERE -
   > LOCAL.SEQUENCE# NOT IN -
   > (SELECT SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=2 AND -
   > THREAD# = LOCAL.THREAD#);
    
   THREAD#    SEQUENCE#
   ---------  ---------
     1        12
     1        13
     1        14

4. Set the LOG_ARCHIVE_TRACE database initialization parameter at a redo source database and at each redo transport destination to trace redo transport progress. See Setting Archive Tracing for complete details and examples.

The V$REDO_DEST_RESP_HISTOGRAM view contains response time data for each redo transport destination.

The response time data is maintained for redo transport messages sent via the synchronous redo transport mode.

The data for each destination consists of a series of rows, with one row for each response time. To simplify record keeping, response times are rounded up to the nearest whole second for response times less than 300 seconds. Response times greater than 300 seconds are round up to 600, 1200, 2400, 4800, or 9600 seconds.

Each row contains four columns: FREQUENCY, DURATION, DEST_ID, and TIME.

The FREQUENCY column contains the number of times that a given response time has been observed. The DURATION column corresponds to the response time. The DEST_ID column identifies the destination. The TIME column contains a timestamp taken when the row was last updated.

The response time data in this view is useful for identifying synchronous redo transport mode performance issues that can affect transaction throughput on a redo source database. It is also useful for tuning the NET_TIMEOUT attribute.

The next three examples show example queries for destination 2, which corresponds to the LOG_ARCHIVE_DEST_2 parameter. To display response time data for a different destination, simply change the DEST_ID in the query.

Perform the following query on a redo source database to display the response time histogram for destination 2:

SQL> SELECT FREQUENCY, DURATION FROM -
> V$REDO_DEST_RESP_HISTOGRAM WHERE DEST_ID=2 AND FREQUENCY>1;

Perform the following query on a redo source database to display the slowest response time for destination 2:

SQL> SELECT max(DURATION) FROM V$REDO_DEST_RESP_HISTOGRAM -
> WHERE DEST_ID=2 AND FREQUENCY>1;

Perform the following query on a redo source database to display the fastest response time for destination 2:

SQL> SELECT min( DURATION) FROM V$REDO_DEST_RESP_HISTOGRAM -
> WHERE DEST_ID=2 AND FREQUENCY>1;

A redo gap occurs whenever redo transmission is interrupted.

When redo transmission resumes, redo transport services automatically detects the redo gap and resolves it by sending the missing redo to the destination.

The time needed to resolve a redo gap is directly proportional to the size of the gap and inversely proportional to the effective throughput of the network link between the redo source database and the redo transport destination. Use redo transport compression to reduce the redo gap resolution time. The COMPRESSION attribute of the LOG_ARCHIVE_DEST_n parameter is used to specify that redo data be compressed before transmission to the destination.

See LOG_ARCHIVE_DEST_n Parameter Attributes for more information about the COMPRESSION attribute.

You can use Oracle wait events to track redo transport wait time on a redo source database.