2 Where to Send Redo Data

Where to Send Redo Data



s



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 datafiles and

cannot be used for switchover or failover. This alternative is useful as a way of

holding archived redo log files for a short period of time, perhaps a day, after

which the log files can then be deleted. This avoids most of the storage and

processing expense of another fully-configured standby database.



s



Cross-instance archival database environment

A cross-instance archival database environment is possible on the primary and

standby databases. Within a Real Application Clusters environment, each

instance transmits its redo data to a single instance of the cluster. This instance,

known as the recovery instance, is typically the instance where recovery is

performed. The recovery instance typically has a tape drive available for

RMAN backup and restoration support. Cross-instance archival environments

are described in Appendix B. Oracle High Availability Architecture and Best

Practices provides additional information about RAC and Data Guard

configurations.



s



Oracle Streams downstream capture database

This destination type allows Oracle Streams to configure the capture process

remotely at a downstream database. The Streams downstream capture process

uses log transport services to transfer redo data to the downstream database

where a Streams capture process captures changes in the archived redo log files

at the remote destination. See Oracle Streams Concepts and Administration for

more information.



s



Oracle Change Data Capture staging database

This destination type allows Change Data Capture for the Asynchronous

AutoLog to use log transport services to transfer redo data from a source

database to a remote staging database where a process captures change data

from the archived redo log files. See Oracle Data Warehousing Guide for more

information.



For discussion purposes, this guide refers to the production database as a primary

database and to archival destinations as standby databases (as defined in

Section 1.1). If you are using Oracle Change Data Capture, substitute the terms

source and staging database for primary and standby database, respectively. If you

are using Oracle Streams, substitute the terms source and downstream capture

database for primary and standby database, respectively.



Log Transport Services



5-3



Where to Send Redo Data



5.2.2 Configuring Destinations with the LOG_ARCHIVE_DEST_n Parameter

The LOG_ARCHIVE_DEST_n initialization parameter defines up to ten (where n = 1,

2, 3, ... 10) destinations, each of which must specify either the LOCATION or the

SERVICE attribute to specify where to archive the redo data. (Also, see Chapter 12

for complete information about all LOG_ARCHIVE_DEST_n attributes.)

The LOCATION and SERVICE attributes describe either a local disk location or an

Oracle Net service name that represents a standby destination to which log

transport services will transmit redo data. Specifying remote destinations with the

SERVICE attribute ensures Data Guard can maintain a transactionally consistent

remote copy of the primary database for disaster recovery.

For every LOG_ARCHIVE_DEST_n initialization parameter that you define, you can

specify a corresponding LOG_ARCHIVE_DEST_STATE_n parameter. The LOG_

ARCHIVE_DEST_STATE_n (where n is an integer from 1 to 10) initialization

parameter specifies whether the corresponding destination is currently on (enabled)

or off (disabled). Table 5–1 describes the LOG_ARCHIVE_DEST_STATE_n parameter

attributes.

Table 5–1



LOG_ARCHIVE_DEST_STATE_n Initialization Parameter Attributes



Attribute



Description



ENABLE



Log transport services can transmit redo data to this

destination. ENABLE is the default.



DEFER



Log transport services will not transmit redo data to this

destination. This is a valid but unused destination.



ALTERNATE



This destination is not enabled, but it will become enabled if

communication to its associated destination fails.



RESET



Functions the same as DEFER, but clears any error messages for

the destination if it had previously failed.



Example 5–1 provides an example of one destination with the LOCATION attribute.

Example 5–1



Specifying a Local Archiving Destination



LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/'

LOG_ARCHIVE_DEST_STATE_1=ENABLE



Figure 5–2 shows what this simple configuration, consisting of a single local

destination, would look like. The log writer process writes redo data to the online

redo log file. As each online redo log file is filled, a log switch occurs and an ARCn



5-4



Oracle Data Guard Concepts and Administration



Where to Send Redo Data



process archives the filled online redo log file to an archived redo log file. The filled

online redo log file is now available for reuse.

Figure 5–2 Primary Database Archiving When There Is No Standby Database

Primary

Database

Transactions



LGWR



Online

Redo Log Files



ARC0



Archived

Redo Log Files



It is important to note that the configuration shown in Figure 5–2 does not include a

standby database and thus does not provide disaster-recovery protection. To make

this simple configuration into a basic Data Guard configuration that provides

disaster recovery, you need to add a standby database at a remote destination by

specifying the SERVICE attribute.

Example 5–2 shows the initialization parameters that enable log transport services

to archive the online redo log on the local destination chicago and transmit redo

data to a remote standby database with the Oracle Net service name boston. The



Log Transport Services



5-5



Where to Send Redo Data



example takes the default values for all of the other LOG_ARCHIVE_DEST_n

attributes:

Example 5–2



Specifying a Remote Archiving 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 basic Data Guard configuration that is

based on the premises that log transport services will use archiver (ARCn) processes

to archive to both the local and remote destinations, and the configuration provides

the maximum performance level of data protection.

Although you can create a basic Data Guard configuration by specifying only the

LOCATION or the SERVICE attributes on the LOG_ARCHIVE_DEST_n parameter,

you can optionally specify more attributes to further define each destination’s

behavior. The following sections describe several of the LOG_ARCHIVE_DEST_n

parameter attributes.



5.2.3 Setting Up Flash Recovery Areas As Destinations

The Oracle database enables you to configure a disk area called the flash recovery

area that is a directory, file system, or Oracle Storage Manager disk group that serves

as the default storage area for files related to recovery.

To configure a flash recovery area, you specify the directory, file system, or Oracle

Storage Manager disk group that will serve as the flash recovery area using the DB_

RECOVERY_FILE_DEST initialization parameter. If no local destinations are

defined, Data Guard implicitly uses the LOG_ARCHIVE_DEST_10 destination to

refer to the default disk location for the flash recovery area and for storing the

archived redo log files. (See Oracle Database Backup and Recovery Basics to configure

the flash recovery area and Oracle Database Administrator's Guide for more

information about Oracle Storage Manager and Oracle Managed Files.)

Note: The filenames for archived redo log files stored in a flash



recovery area are generated automatically by Oracle Managed Files

(OMF); the filenames are not based on the format specified by the

LOG_ARCHIVE_FORMAT initialization parameter.



5-6



Oracle Data Guard Concepts and Administration



Where to Send Redo Data



Although the flash recovery area uses the LOG_ARCHIVE_DEST_10 destination by

default, you can explicitly set up flash recovery areas to use one or more other LOG_

ARCHIVE_DEST_n destinations or the STANDBY_ARCHIVE_DEST destination. This

section contains the following topics:

s



Using the LOG_ARCHIVE_DEST_10 Default Flash Recovery Area



s



Setting Flash Recovery Areas to Other LOG_ARCHIVE_DEST_n Destinations



s



Setting Flash Recovery Areas to the STANDBY_ARCHIVE_DEST Destination



s



Sharing a Flash Recovery Area Between Primary and Standby Databases

Note: A primary database cannot transmit redo data to the flash



recovery area of a logical standby database.

See Oracle Database Backup and Recovery Basics to configure flash recovery areas and

Section 8.4.4 for information about setting up a deletion policy for archived redo log

files in flash recovery areas.



5.2.3.1 Using the LOG_ARCHIVE_DEST_10 Default Flash Recovery Area

If a flash recovery area has been configured and no local destinations are defined,

Data Guard implicitly uses the LOG_ARCHIVE_DEST_10 destination to refer to the

default disk location for the flash recovery area and for storing the archived redo

log files.

When the LOG_ARCHIVE_DEST_10 destination is used for the flash recovery area,

Data Guard automatically uses the default values for all of the LOG_ARCHIVE_

DEST_10 parameter attributes. To override the defaults, you can dynamically set the

values for most1 of the attributes by explicitly specifying the LOG_ARCHIVE_DEST_

10 parameter. For example, the following ALTER SYSTEM SET statement specifies

several attributes on the LOG_ARCHIVE_DEST_10 initialization parameter:

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_10='LOCATION=USE_DB_RECOVERY_FILE_DEST

LGWR MANDATORY REOPEN=5 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)'



When setting LOG_ARCHIVE_DEST_n attributes, the TEMPLATE attribute of a LOG_

ARCHIVE_DEST_n parameter will override all other specifications for the flash

recovery area. If the TEMPLATE attribute is specified for a remote destination and

1



Only the QUOTA_SIZE and QUOTA_USED attributes cannot be specified when defining a

destination for the flash recovery area. This is because the amount of space allocated for the

flash recovery area is defined with the DB_RECOVERY_FILE_DEST_SIZE parameter.



Log Transport Services



5-7



Where to Send Redo Data



that destination archives redo data to a flash recovery area, the archived redo log

file will use the directory and file name specified by the TEMPLATE attribute.



5.2.3.2 Setting Flash Recovery Areas to Other LOG_ARCHIVE_DEST_n

Destinations

By default, if no local destinations are defined, flash recovery areas use the LOG_

ARCHIVE_DEST_10 destination, but you can explicitly set up one or more other

LOG_ARCHIVE_DEST_n destinations. For example, you can optionally:

s



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 the flash recovery area to use another archival destination, 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.

s



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)'



5-8



Oracle Data Guard Concepts and Administration



Where to Send Redo Data



5.2.3.3 Setting Flash Recovery Areas to the STANDBY_ARCHIVE_DEST

Destination

You can use a flash recovery area on a physical standby database by defining the

STANDBY_ARCHIVE_DEST parameter. For example:

STANDBY_ARCHIVE_DEST='LOCATION=USE_DB_RECOVERY_FILE_DEST'



Note: Flash recovery area destinations specified with the



STANDBY_ARCHIVE_DEST parameter on logical standby databases

(SQL Apply) are ignored.



5.2.3.4 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 show how to specify initialization parameters on the

primary and standby databases that will share a flash recovery area in the

/arch/oradata location. Although the DB_UNIQUE_NAME parameter is not

specified in Example 5–3, it defaults to PAYROLL, which is the name specified for

the DB_NAME initialization parameter.

Example 5–3



Primary Database Initialization Parameters for a Shared Recovery Area



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 5–4



Standby Database Initialization Parameters for a Shared Recovery Area



DB_NAME=PAYROLL

DB_UNIQUE_NAME=boston

LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST'

STANDBY_ARCHIVE_DEST='LOCATION=USE_DB_RECOVERY_FILE_DEST'

DB_RECOVERY_FILE_DEST='/arch/oradata'

DB_RECOVERY_FILE_DEST_SIZE=5G



See Oracle Database Backup and Recovery Advanced User's Guide for more information

about sharing a flash recovery area among multiple databases.



Log Transport Services



5-9



How to Send Redo Data



5.3 How to Send Redo Data

This section contains the following topics:

s



Using Archiver Processes (ARCn) to Archive Redo Data



s



Using the Log Writer Process (LGWR) to Archive Redo Data



s



Providing for Secure Redo Data Transmission



5.3.1 Using Archiver Processes (ARCn) to Archive Redo Data

By default, log transport services use ARCn processes to archive the local online

redo log files on the primary database before transmitting the redo data to remote

standby destinations. Using ARCn processes for archival processing is described in

the following topics:

s



Initialization Parameters That Control ARCn Archival Behavior



s



Default ARCn Archival Processing



s



Nondefault ARCn Archival Processing



ARCn archival processing supports only the maximum performance level of data

protection in Data Guard configurations. You must use the LGWR process to

transmit redo data to standby locations that operate in other data protection modes.

See Section 5.6 for more information about the Data Guard data protection modes.



5.3.1.1 Initialization Parameters That Control ARCn Archival Behavior

The LOG_ARCHIVE_LOCAL_FIRST initialization parameter, the ARCH attribute on

the LOG_ARCHIVE_DEST_n parameter, and the LOG_ARCHIVE_DEST_STATE_n

parameter control ARCn archival processing. The following sections describe

setting these parameters to control archival processing.

Enabling Log Transport Services to Use ARCn Processes

The ARCH attribute of the LOG_ARCHIVE_DEST_n parameter enables log transport

services to use ARCn processes to transmit redo data to archival destinations:

s



s



5-10



If you specify the ARCH and LOCATION attributes on the LOG_ARCHIVE_DEST_

n parameter, ARCn processes archive to a local destination.

If you specify the ARCH and SERVICE attributes on the LOG_ARCHIVE_DEST_n

parameter, ARCn processes transmit redo data to a remote destination.



Oracle Data Guard Concepts and Administration



How to Send Redo Data



Controlling When ARCn Processes Transmit Redo Data

The LOG_ARCHIVE_LOCAL_FIRST initialization parameter controls when the

archiver processes (ARCn) transmit redo data to remote standby database

destinations. The following table describes possible values for this parameter.

Value



Transmits Redo Data to the Remote Standby Destination. . .



TRUE



After the online redo log file is completely and successfully archived to at

least one local destination. This is the default value. Section 5.3.1.2 provides

more information about this default ARCn behavior.



FALSE



At the same time the online redo log file is archived to the local destinations.

Section 5.3.1.3 provides more information about this ARCn behavior.



The following sections provide more information about the behavior of ARCn

processing depending on the value of the LOG_ARCHIVE_LOCAL_FIRST

initialization parameter.



5.3.1.2 Default ARCn Archival Processing

Figure 5–3 shows an example of the default archival processing in a Data Guard

configuration. This configuration represents the default ARCn archival processing

in a Data Guard configuration with a primary database located in Chicago and one

physical standby database located in Boston. (This is the configuration that was

created in Chapter 3.)

Archiving happens when a log switch occurs on the primary database. After the

ARC0 process successfully archives the local online redo log to the local destination

(LOG_ARCHIVE_DEST_1), the ARC1 process transmits redo from the local archived

redo log files (instead of the online redo log files) to the remote standby destination

(LOG_ARCHIVE_DEST_2). On the remote destination, the remote file server process

(RFS) will, in turn, write the redo data to an archived redo log file from a standby

redo log file. (Section 5.6.2 describes how to configure standby redo log files.) Log

apply services use Redo Apply (MRP process1) or SQL Apply (LSP process2) to

apply the redo to the standby database. Because the online redo log files are

archived locally first, the LGWR process reuses the online redo log files much

earlier than would be possible if the ARCn processes archived to the standby

1



2



The managed recovery process (MRP) applies archived redo log files to the physical

standby database and can start additional parallel execution (Pnnn) processes to balance

workload.

The logical standby process (LSP) uses parallel execution (Pnnn) processes to apply

archived redo log files to the logical standby database, using SQL interfaces.



Log Transport Services 5-11