Oracle/HP Best Practices Guide for HP IO Accelerators

Redundancy architectures 10
Administrators can use either manual or automatic failover to a Data Guard standby database to maintain
high availability for mission-critical applications.
Oracle Data Guard provides a primary/secondary solution (only one host can read and update the
database at a time) rather than the primary/primary solution provided by RAC (each server can read and
update simultaneously). Depending on the Oracle version and the type of standby database selected, the
secondary host can be used for read-only access to the database while still functioning in a standby
database role.
When configuring replication with Data Guard, make sure you select the proper Protection Mode for your
needs. The Protection Mode setting controls how Data Guard and Oracle treat the reporting of committed
transactions to the client, based on the client's state on the secondary device.
Options include both sync and async, as well as other nuances. With the sync option, transactions
must be committed on both servers before processing can continue. With the async option, transactions
must be committed only on the primary server to enable processing to continue. They are sent to the
secondary server a short time later.
The async option can allow for a small amount of data loss on failure of the primary server. For
additional details on Protection Mode settings, see the Oracle website
(http://download.oracle.com/docs/cd/E11882_01/server.112/e17022/protection.htm).
Data Guard replication types
The log_archive_dest_n parameter in a Data Guard configuration supports a number of attributes
including SYNC, ASYNC, ARCH and LGWR .
NOTE: The ARCH and LGWR attributes have been depreciated in 11g Release 2. Specify
SYNC or ASYNC. The ASYNC attribute is the default if neither attribute is specified.
SYNCH and ASYNC
These attributes specify whether the synchronous (SYNC) or asynchronous (ASYNC) redo transport mode
is to be used. The LOG_ARCHIVE_DEST_11 through LOG_ARCHIVE_DEST_31 parameters do not
support the SYNC attribute.
The redo log data generated by a transaction that is configured with the SYNC attribute must have been
received by every enabled destination before that transaction can commit. The redo data generated by a
transaction that is configured with the ASYNC attribute need not have been received at a destination
before that transaction can commit. This is the default behavior if neither SYNC nor ASYNC is specified.
ARCH and LGWR
These attributes specify whether redo transport services should use the archiving process (ARCH) or the
log writer process (LGWR) to collect transaction redo data and transmit it to standby destinations.
These attributes are optional. If neither the ARCH nor LGWR attribute is specified, the default is ARCH.
Redo transport services use ARCn processes when the ARCH attribute is specified, and the log writer
process when the LGWR attribute is specified. By default, archiving is performed by ARCn processes. You
must explicitly specify the LGWR attribute for redo transport services to use the LGWR process.
Although you cannot specify both LGWR and ARCn processes for the same destination, you can choose
to use the log writer process for some destinations, while using the archiver process to transmit redo log
data for other destinations.