Data Guard Protection Modes

1. In some situations, a business cannot afford to lose data.

2. In other situations, the availability of the database may be more important than the loss
of data.
3. Some applications require maximum database performance and can tolerate some small
amount of data loss.
The following descriptions summarize the three distinct modes of data protection.
Maximum Protection

This protection mode ensures that no data loss will occur if the primary database fails. To
provide this level of protection, the redo data needed to recover each transaction must be
written to both the local online redo log and to the standby redo log on at least one standby
database before the transaction commits. To ensure data loss cannot occur, the primary
database shuts down if any fault prevents it from writing to the standby redo log of at least
one standby database.
Maximum availability

This protection mode provides the highest level of data protection that is possible without
compromising the availability of the primary database. Like maximum protection mode, a
transaction will not commit in primary, until the redo needed to recover that transaction is
written to the local online redo log and also to the standby redo log of at least one standby
database.
Unlike maximum protection mode, the primary database does not shut down if a fault
prevents it from writing its redo stream to a remote standby redo log. Instead, the primary
database operates in maximum performance mode until the fault is corrected, and all gaps
in redo log files are resolved. When all gaps are resolved, the primary database
automatically resumes operating in maximum availability mode. This mode ensures that no
data loss will occur if the primary database fails.;
Maximum performance

This protection mode (the default) provides the highest level of data protection that is
possible without affecting the performance of the primary database. This is accomplished by
allowing a transaction to commit as soon as the redo data for the transaction is written to
the local online redo log. The primary databases redo data stream is also written to at least
one standby database, but that redo stream is written asynchronously with respect to the
transactions that create the redo data.
When network links with sufficient bandwidth are used, this mode provides a level of data
protection that approaches that of maximum availability mode with minimal impact on
primary database performance. The maximum protection and maximum availability modes
require that standby redo log files are configured on at least one standby database in the
configuration.
All three protection modes require that specific log transport attributes be specified on the
LOG_ARCHIVE_DEST_n initialization parameter to send redo data to at least one standby
database.

How to Send Redo Data

On the primary database, Oracle Data Guard uses archiver processes (ARCn) or the log
writer process (LGWR) to collect transaction redo data and transmit it to standby
destinations. Although we cannot use both the archiver and log writer processes to send
redo data to the same destination, we can choose to use the log writer process
for some destinations, while archiver processes send redo data to other destinations.
Data Guard also uses the fetch archive log (FAL) client and server to send archived redo log
files to standby destinations following a network outage, for automatic gap resolution, and
resynchronization. The FAL process and gap resolution are dealt with below:

Managing Archive Gaps

An archive gap can occur on the standby system when it is has not received one or more
archive log files generated by the primary database. The missing archived redo log files are
the gap. If there is a gap, it is automatically detected and resolved by Data Guard by
copying the missing sequence of log files to the standby destination.
For example, an archive gap can occur when the network becomes unavailable and
automatic archiving from the primary database to the standby database temporarily stops.
When the network is available again, automatic transmission of the redo data from the
primary database to the failed standby database resumes. Data Guard requires no manual
intervention by the DBA to detect and resolve such gaps. The following sections describe
gap detection and resolution.

When Is an Archive Gap Discovered?

An archive gap can occur whenever the primary database archives a log locally, but the log
is not received at the standby site. Every minute, the primary database polls its standby
databases to see if there are gaps in the sequence of archived redo log files.

How Is a Gap Resolved?

Gap recovery is handled through the polling mechanism. For physical and logical standby
databases, Oracle Change Data Capture, and Oracle Streams, Data Guard performs gap
detection and resolution by automatically retrieving missing archived redo log files from the
primary database. No extra configuration settings are required to poll the standby
databases, to detect any gaps, or to resolve the gaps. The important consideration here is
that automatic gap recovery is contingent on the availability of the primary database. If the
primary database is not available and you have a configuration with multiple physical
standby databases, you can set up additional initialization parameters so that the Redo
Apply can resolve archive gaps from another standby database

Using the Fetch Archive Log (FAL) to Resolve Archive Gaps

The fetch archive log (FAL) client and server resolve gaps detected in the range of archived
redo log files generated at the primary database and received at the physical standby
database.
The FAL client requests the transfer of archived redo log files automatically.
The FAL server, attends to the requests coming from the FAL Client.

The FAL mechanism handles the following types of archive gaps and problems:
When creating a physical or logical standby database, the FAL mechanism can
automatically retrieve any archived log files generated during a hot backup of the primary
database.
When there are problems with archived log files that have already been received on the
standby database, the FAL mechanism can automatically retrieve archived log files to
resolve any of the following situations:
When the archived log file is deleted from disk before it is applied to the standby database.
When the archived log file cannot be applied because of a disk corruption.
When the archived log file is accidentally replaced by another file (for example, a text file)
that is not an archived redo log file before the redo data has been applied to the standby
database.
When you have multiple physical standby databases, the FAL mechanism can
automatically retrieve missing archived log files from another physical standby database.
The FAL client and FAL server are configured using the FAL_CLIENT and FAL_SERVER
initialization parameters that are set on the standby database. [Define the FAL_CLIENT and
FAL_SERVER initialization parameters only for physical standby databases in the init
parameter file]

Manually Determining and Resolving Archive Gaps

In some situations, automatic gap recovery may not take place and we will need to perform
gap recovery manually.
For example, we will need to perform gap recovery manually if we are using logical standby
databases and the primary database is not available. The following sections describe how to
query the appropriate views to determine which log files are missing and perform manual
recovery.
On a physical standby database
To determine if there is an archive gap on your physical standby database, query the
V$ARCHIVE_GAP view as shown in the following example:
SQL>SELECT*FROMV$ARCHIVE_GAP;
THREAD#
LOW_SEQUENCE# HIGH_SEQUENCE#

1
7
10

The output from the above example indicates that physical standby database is currently
missing log files from sequence 7 to sequence 10 for thread 1. After identifying the gap,
issue the following SQL statement on the primary database to locate the archived log files
on your primary database (assuming the local archive destination on the primary database
is LOG_ARCHIVE_DEST_1):
SQL>SELECTNAMEFROMV$ARCHIVED_LOGWHERETHREAD#=1ANDDEST_ID=1ANDSEQUENCE#
BETWEEN7AND10;
NAME

/primary/thread1_dest/arcr_1_7.arc

/primary/thread1_dest/arcr_1_8.arc
/primary/thread1_dest/arcr_1_9.arc

We need to manually copy these log files to our physical standby database and register
them using the ALTER DATABASE REGISTER LOGFILE statement on your physical standby
database. For example:
SQL>ALTERDATABASEREGISTERLOGFILE'/physical_standby1/thread1_dest/arcr_1_7.arc';
SQL>ALTERDATABASEREGISTERLOGFILE'/physical_standby1/thread1_dest/arcr_1_8.arc';

After we register these log files on the physical standby database, we can restart Redo
Apply.

Note:
The V$ARCHIVE_GAP fixed view on a physical standby database only returns the next gap
that is currently blocking Redo Apply from continuing. After resolving the gap and starting
Redo Apply, query the V$ARCHIVE_GAP fixed view again on the physical standby database
to determine the next gap sequence, if there is one. Repeat this process until there are no
more gaps.

Verification
Monitoring Log File Archival Information
This section describes using views to monitor redo log archival activity for the primary
database.
Step 1 Determine the status of redo log files.
Enter the following query on the primary database to determine the status of all online redo
log files:
SQL>SELECTTHREAD#,SEQUENCE#,ARCHIVED,STATUSFROMV$LOG;

Step 2 Determine the most recent archived redo log file.

Enter the following query on the primary database to determine recently archived thread
and sequence number:
SQL>SELECTMAX(SEQUENCE#),THREAD#FROMV$ARCHIVED_LOGGROUPBYTHREAD#;

Step 3 Determine the most recent archived redo log file at each destination.
Enter the following query on the primary database to determine which archived redo log file
was most recently transmitted to each of the archiving destinations:
SQL>SELECTDESTINATION,STATUS,ARCHIVED_THREAD#,ARCHIVED_SEQ#FROM
V$ARCHIVE_DEST_STATUS
WHERESTATUS<>'DEFERRED'ANDSTATUS<>'INACTIVE';
DESTINATION
STATUSARCHIVED_THREAD#ARCHIVED_SEQ#

/private1/prmy/lad VALID 1
947
standby1VALID1947

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

Step 4 Find out if archived redo log files have been received.
You can issue a query at the primary database to find out if an archived log file was not
received at a particular site. Each destination has an ID number associated with it. You can
query the DEST_ID column of the V$ARCHIVE_DEST fixed view on the primary database to
identify each destinations ID number.
Assume the current local destination is 1, and one of the remote standby destination IDs is
2.
To identify which log files are missing at the standby destination, issue the following query:
SQL>SELECTLOCAL.THREAD#,LOCAL.SEQUENCE#FROM
2>(SELECTTHREAD#,SEQUENCE#FROMV$ARCHIVED_LOGWHEREDEST_ID=1)
3>LOCALWHERE
4>LOCAL.SEQUENCE#NOTIN
5>(SELECTSEQUENCE#FROMV$ARCHIVED_LOGWHEREDEST_ID=2AND
6>THREAD#=LOCAL.THREAD#);
THREAD#
SEQUENCE#

1
12
1
13
1
14

Step 5 Trace the progression of transmitted redo on the standby site.

To see the progression of the transmission of redo data to the standby destination, set the
LOG_ARCHIVE_TRACE parameter in the primary and standby initialization parameter files.

Using Archiver Processes (ARCn) to Archive Redo Data

By default, redo transport services use ARCn processes to archive the online redo log files on
the primary database. 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.

Init Parameters That Control ARCn Archival Behavior

The following descriptions tell how to use the LOG_ARCHIVE_DEST_n and the
LOG_ARCHIVE_MAX_PROCESSES initialization parameters.
Enabling ARCn Processes to Archive to Local or Remote Destinations
We specify attributes on the LOG_ARCHIVE_DEST_n initialization parameter to control the
automated transfer of redo data from the primary database to other destinations. Because
ARCn archiver processing is the default archival behavior, specifying the ARCH attribute on
the LOG_ARCHIVE_DEST_n parameter is optional. However, we must specify either the
LOCATION attribute to archive to a local destination or the SERVICE attribute for remote
archival.
Specifying the Number of ARCn Processes to be Invoked
The LOG_ARCHIVE_MAX_PROCESSES initialization parameter specifies the maximum number
of ARCn processes. By default, 4 archiver processes are invoked when the
primary database instance starts and Oracle Database dynamically adjusts the number of
processes to balance the archiver workload. Thus, the actual number of archiver
processes may vary at any time.

If you anticipate a heavy workload for archiving, you can increase the maximum number of
archiver processes to as many as 30 by setting the initialization parameter
LOG_ARCHIVE_MAX_PROCESSES. This initialization parameter is dynamic and can be altered
by the ALTER SYSTEM command to increase or decrease the maximum
number of archiver processes.
For example:
ALTERSYSTEMSETLOG_ARCHIVE_MAX_PROCESSES=20;

ARCn Archival Processing

The following figure shows an example of archival processing in a Data Guard configuration,
with a primary database and one physical standby database.

Archiving happens when a log switch occurs on the primary database:

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 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 log file from a standby redo log file.
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 database concurrently with the local destination.
In the Primary location, We need to have at least 2 ARCn processes - to separate local
archival from remote archival. This can be done by setting the
LOG_ARCHIVE_MAX_PROCESSES initialization parameter (the default setting is 4, but the
maximum value is 30)
Because the default ARCn (Archiver process) disassociates local archiving from remote
archiving, sites that may have policies to delete archived log files on the primary database
immediately after backing them up, must make sure that the standby destinations receive
the corresponding redo data before deleting the archived log files on the primary database.
We can query the V$ARCHIVED_LOG view to verify the redo data was received on standby
destinations.
Note:

1 The managed recovery process (MRP) applies archived redo log files to the physical
standby database, and automatically determines the optimal number of parallel recovery
processes at the time it starts. The number of parallel recovery slaves spawned is based
on the number of CPUs available on the standby server.
2 The logical standby process (LSP) uses parallel execution (Pnnn) processes to apply
archived redo log files to the logical standby database, using SQL interfaces.