Oracle Data Guard - Redo Transport Services

Redo generated on the primary database is transmitted first to online redo log files on the primary system, and from there the redo is written to archived redo log files on the primary system and transmitted over Oracle Net to standby redo log files on the standby system. This graphic shows that redo data can also be sent from the archived redo log files on the primary to standby redo log files on the standby system. On the standby database, log apply services apply the redo data to the standby database from the standby redo log files and archived redo log files.

• Oracle Data Guard standby databases

  Standby database destinations can be either physical standby databases or logical standby databases.

• Archived redo log repository

  This type of destination allows off-site archiving of redo data. An archive log repository is created by using a physical standby control file, starting the instance, and mounting the database. This database contains no data files and cannot be used for switchover or failover

• Oracle Streams real-time downstream capture database

  This destination type allows Oracle Streams to configure a capture process on a remote downstream database

• Oracle Change Data Capture staging database

  This destination type supports a Change Data Capture Asynchronous AutoLog configuration remotely at a staging database.

Oracle Data Guard - How to send Redo Data?

Configuring Destinations with the LOG_ARCHIVE_DEST_n Parameter

The LOCATION and SERVICE attributes describe either a local disk location or an Oracle Net service name that represents a standby destination to which redo transport services will transmit redo data. Specifying remote destinations with the SERVICE attribute allows Data Guard to maintain a transactionally consistent remote copy of the primary database for disaster recovery.

Specifying a Local Archiving Destination- when there is no standby database

LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
The following figure illustrates the primary database when there is no standby database.

Specifying a Remote Destination

LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_2='SERVICE=boston'
LOG_ARCHIVE_DEST_STATE_2=ENABLE

These initialization parameters set up a Data Guard configuration that uses archiver (ARCn) processes to archive to both the local and remote destinations. This configuration provides the maximum performance level of data protection

You can dynamically update most of the attribute values of the LOG_ARCHIVE_DEST_n and the LOG_ARCHIVE_DEST_STATE_n parameters using the ALTER SYSTEM SET statement.

Query the V$ARCHIVE_DEST view to see current settings of the LOG_ARCHIVE_DEST_n initialization parameter.

Oracle Data Guard - Setting up Flash Recovery Areas

To configure a flash recovery area, use the DB_RECOVERY_FILE_DEST initialization parameter. LOG_ARCHIVE_DEST_10 is implicitly set to USE_DB_RECOVERY_FILE_DEST (meaning that archived redo log files will be sent to the flash recovery area) if you create a recovery area and do not set any other local archiving destinations.

Using Other LOG_ARCHIVE_DEST_n Destinations

You can explicitly set up one or more other LOG_ARCHIVE_DEST_n destinations to point to a flash recovery area. For example, you can optionally:

Configure destinations other than LOG_ARCHIVE_DEST_10

For example, an existing Data Guard configuration may have already used the LOG_ARCHIVE_DEST_10 destination for another purpose, or you may want to release the LOG_ARCHIVE_DEST_10 destination for other uses.

To configure another archival destination to point to the flash recovery area, you must specify the LOCATION=USE_DB_RECOVERY_FILE_DEST attribute to define the new destination. For example:

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST ARCH MANDATORY REOPEN=5 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)'

The implicit setting (for LOG_ARCHIVE_DEST_10 to use the flash recovery area) will be cleared.

Configure destinations in addition to LOG_ARCHIVE_DEST_10 destination for use after a role transition

For example, you can configure one destination to be valid for standby redo log archival when the database operates in the standby role and another destination to be valid for online redo log archival when the database operates in the primary role.

To configure a LOG_ARCHIVE_DEST_n destination in addition to LOG_ARCHIVE_DEST_10, you must explicitly specify both destinations:

LOG_ARCHIVE_DEST_9='LOCATION=USE_DB_RECOVERY_FILE_DEST ARCH MANDATORY REOPEN=5 VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)'
LOG_ARCHIVE_DEST_10='LOCATION=USE_DB_RECOVERY_FILE_DEST ARCH MANDATORY REOPEN=5 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)'

Using the STANDBY_ARCHIVE_DEST Destination

On a physical standby database, you can define the STANDBY_ARCHIVE_DEST parameter to point to the flash recovery area. For example: STANDBY_ARCHIVE_DEST='LOCATION=USE_DB_RECOVERY_FILE_DEST'

Sharing a Flash Recovery Area Between Primary and Standby Databases

You can share a flash recovery area between databases provided each database that shares the flash recovery area has a unique database name, specified with the DB_UNIQUE_NAME initialization parameter.

The following examples shows how to specify initialization parameters on the primary and standby databases that will share a flash recovery area in the /arch/oradata location. it defaults to PAYROLL, which is the name specified for the DB_NAME initialization parameter.

DB_NAME=PAYROLL
LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST'
DB_RECOVERY_FILE_DEST='/arch/oradata'
DB_RECOVERY_FILE_DEST_SIZE=20G

Example Standby Database Initialization Parameters for a Shared Recovery Area