Download Data-Protection Modes Data Guard provides three high

Data-Protection Modes
Data Guard provides three high-level modes of data protection that you can configure to
balance cost, availability, performance, and transaction protection. You can configure the
Data Guard environment to maximize data protection, availability, or performance.
Maximum Protection
This protection mode guarantees that no data loss occurs if the primary database fails. To
provide this level of protection, the redo data that is 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 that data loss does not occur,
the primary database shuts down if a fault prevents it from writing its redo stream to at
least one remote standby redo log. For multiple-instance Real Application Clusters (RAC)
databases, Data Guard shuts down the primary database if it is unable to write the redo
records to at least one properly configured database instance.
Maximum Availability
This protection mode provides the highest possible level of data protection without
compromising the availability of the primary database. As with maximum protection
mode, a transaction does not commit until the redo needed to recover that transaction is
written to the local online redo log and to at least one remote standby redo log. 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 guarantees that no data loss occurs if the primary database fails, but only if a
second fault does not prevent a complete set of redo data from being sent from the primary
database to at least one standby database.
Maximum Performance (Default)
This default protection mode provides the highest possible level of data protection without
affecting the performance of the primary database. This is accomplished by allowing a
transaction to commit as soon as the redo data needed to recover that transaction is written
to the local online redo log. The primary database’s redo data stream is also written to at
least one standby database, but that redo stream is written asynchronously with respect to
the commitment of 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.
Primary Database Flow
On the primary database, Data Guard log transport services use the following processes:
• Log writer (LGWR) process: LGWR collects transaction redo information and updates
the online redo logs. In synchronous mode, it ships redo information directly to the remote
file server (RFS) process on the standby database and waits for a confirmation before
proceeding. In asynchronous mode, it ships the redo information directly but doesn’t wait
before proceeding. In asynchronous mode, LGWR submits the network I/O request to the
network server (LNSn) process for that destination.
• Archiver (ARCn) process: ARCn, or a SQL session performing an archival operation,
creates a copy of the online redo logs locally for use in a primary database recovery. The
ARCn process may also ship the redo stream to the RFS process while simultaneously
archiving the online log. ARCn is also responsible for proactively detecting and resolving
gaps on all standby databases.
• Fetch archive log (FAL) (physical standby databases only): FAL provides a client/server
mechanism for resolving gaps detected in the range of archived redo logs that are generated
at the primary database and received at the standby database. This process is started only
when needed and shuts down as soon as it is finished. It is very likely you will not see this
process running.
Note: You can configure a primary database to ship redo information by using LGWR or ARCn,
but not both.
Standby Database Flow
On the standby database, Data Guard log apply services use the following processes:
• Remote file server (RFS) process: RFS receives redo information from the primary
database. RFS can write the redo into standby redo logs or directly to archived redo logs.
Note: Standby redo logs are optional. The use of standby redo logs is discussed in more
detail later in the lesson.
• Archiver (ARCn) process: The ARCn process archives the standby redo logs.
• Managed recovery process (MRP): For physical standby databases only, MRP applies
archived redo log information to the physical standby database. If you start the managed
recovery with the SQL statement ALTER DATABASE RECOVER MANAGED STANDBY
DATABASE; this foreground session performs the recovery. If you use the optional clause
DISCONNECT [FROM SESSION], the MRP background process starts. If you use Data
Guard broker to manage your standby databases, the broker always starts the MRP
background process for a physical standby database.
• Logical standby process (LSP): For logical standby databases only, LSP controls the
applying of archived redo log information to the logical standby database.
Standby Redo Logs
A standby redo log is used only when the database is in the standby role to store redo data
received from the primary database. Standby redo logs form a separate pool of log file groups.
Configuring standby redo log files is highly recommended on all standby databases in a Data
Guard configuration, including the primary database to aid in role reversal.
A standby redo log is required to implement:
• The maximum protection and maximum availability levels of data protection
• Real-time apply
• Cascaded redo log destinations
Standby redo logs are recommended for maximum performance data protection mode.
Unless you are using the real-time apply feature, standby redo logs must be archived before the
data can be applied to the standby database. The standby archival operation occurs
automatically.
Real-Time Apply
When you enable the optional real-time apply feature, log apply services apply the redo data
from standby redo log files in real time (at the same time the log files are being written to) as
opposed to recovering redo from archived redo log files when a log switch occurs.
The RECOVERY_MODE column of the V$ARCHIVE_DEST_STATUS view contains the value
MANAGED REAL TIME APPLY when log apply services are running in real-time apply mode.
For physical standby databases, the managed recovery process (MRP) applies the redo from the
standby redo log files after the remote file server (RFS) process finishes writing. To start
realtime apply for a physical standby database, issue the following command:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT
LOGFILE;
Standby redo log files are required for real-time apply. It is highly recommended that you
have one more standby redo log group than the number of online log groups on the primary
database.