Introduction
to Oracle Data Guard
Oracle Data Guard ensures high availability,
data protection, and disaster recovery for enterprise data. Data Guard provides
a comprehensive set of services that create, maintain, manage, and monitor one
or more standby databases to enable production Oracle databases
to survive disasters and data corruptions. Data Guard maintains these standby
databases as copies of the production database. Then, if the production
database becomes unavailable because of a planned or an unplanned outage, Data
Guard can switch any standby database to the production role, minimizing the
downtime associated with the outage.
Protection
Mode:
There are three protection modes
for the primary database:
Maximum Availability: Transactions on the primary do not commit
until redo information has been written to the online redo log and the standby
redo logs of at least one standby location. If no standby location is
available, it acts in the same manner as maximum performance mode until a
standby becomes available again.
Maximum Performance: Transactions on the primary commit as soon
as redo information has been written to the online redo log. Transfer of redo
information to the standby server is asynchronous, so it does not impact on
performance of the primary.
Maximum Protection: Transactions on the primary do not commit
until redo information has been written to the online redo log and the standby
redo logs of at least one standby location. If not suitable standby location is
available, the primary database shuts down.
Data Guard Services
The
following sections explain how Data Guard manages the transmission of redo
data, the application of redo data, and changes to the database roles:
Control the automated transfer of redo data
from the production database to one or more archival destinations.
·
Apply redo data on
the standby database to maintain transactional synchronization with the primary
database. Redo data can be applied either from archived redo log files, or,
if real-time apply is enabled, directly from the
standby redo log files as they are being filled, without requiring the redo
data to be archived first at the standby database.
Change the role of a database from a standby
database to a primary database, or from a primary database to a standby
database using either a switchover or a failover operation.
Redo
Transport Services
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 you cannot use both the archiver and log writer
processes to send redo data to the same destination, you 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.
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.
Enabling ARCn Processes to Archive to Local or
Remote Destinations
You 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.
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.
We can change by following
command, it is dynamic parameter
ALTER SYSTEM SET
LOG_ARCHIVE_MAX_PROCESSES = 20;
Archiving to Local Destinations Before
Archiving to Remote Destinations
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), theARC1 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. Log apply services use Redo Apply (MRP processFoot 1 ) or SQL Apply (LSP processFoot 2 ) to apply the redo to the standby
database.
Using the Log Writer
Process (LGWR) to Archive Redo Data
Using
the LGWR process differs from ARCn processing, because instead of waiting
for the online redo log to switch at the primary database and then writing the
entire archived redo log at the remote destination all at once, the LGWR
process selects a standby redo log file at the standby site that reflects the
log sequence number (and size) of the current online redo log file of the
primary database. Then, as redo is generated at the primary database, it is
also transmitted to the remote destination. The transmission to the remote
destination will either be synchronous or asynchronous, based on whether
the SYNC or the ASYNC attribute is set on
the LOG_ARCHIVE_DEST_n parameter. Synchronous LGWR processing is
required for the maximum protection and maximum availability modes of data
protection in Data Guard configurations.
LOG_ARCHIVE_DEST_n
Attributes for LGWR Archival Processing
-
LGWR, SYNC, and ASYNC
You must
specify the LGWR and SERVICE attributes on
the LOG_ARCHIVE_DEST_n parameter to enable redo transport services to
use the LGWR process to transmit redo data to remote archival destinations.
The SYNC attribute
performs all network I/O synchronously, in conjunction with each write
operation to the online redo log file, and waits for the network I/O to
complete. This is the default network transmission setting.
The ASYNC attribute
performs all network I/O asynchronously and control is returned to the
executing application or user immediately, without waiting for the network I/O
to complete.
Above image shows
a Data Guard configuration that uses the LGWR process to
synchronously transmit redo data to the standby system at the same time it is
writing redo data to the online redo log file on the primary database:
- On the primary database, the
LGWR process submits the redo data to one or more network server (LNSn)
processes, which then initiate the network I/O in parallel to multiple
remote destinations. Transactions are not committed on the primary
database until the redo data necessary to recover the transaction is
received by all LGWR SYNC destinations.
- On the standby system, the remote file server (RFS) receives redo data over the
network from the LGWR process and writes the redo data to the standby redo
log files.
A log switch
on the primary database triggers a log switch on the standby database, causing
ARCn processes on the standby database to archive the standby redo log
files to archived redo log files on the standby database. Then, Redo Apply (MRP process) or SQL Apply (LSP
process) applies the redo data to the standby database. If real-time apply is
enabled, Data Guard recovers redo data directly from the current standby redo
log file as it is being filled up by the RFS process.
Apply Services
The redo
data transmitted from the primary database is written to the standby redo log
on the standby database. Apply services automatically apply the redo data on the standby database to maintain consistency
with the primary database. It also allows read-only access to the data.
The main
difference between physical and logical standby
databases is the manner in which apply services apply the archived redo data:
·
For physical standby
databases, Data Guard uses Redo Apply technology, which applies redo
data on the standby database using standard recovery techniques of an Oracle
database, as shown in
Automatic
Updating of a Physical Standby Database
By default, for a newly created
standby database, the primary database is in maximum performance mode.
SELECT protection_mode FROM
v$database;
PROTECTION_MODE
--------------------
MAXIMUM PERFORMANCE
SQL>
The mode can be switched using
the following commands. Note the alterations in the redo transport attributes.
-- Maximum Availability.
ALTER SYSTEM SET
LOG_ARCHIVE_DEST_2='SERVICE=db11g_stby AFFIRM SYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DB11G_STBY';
ALTER DATABASE SET STANDBY
DATABASE TO MAXIMIZE AVAILABILITY;
-- Maximum Performance.
ALTER SYSTEM SET
LOG_ARCHIVE_DEST_2='SERVICE=db11g_stby NOAFFIRM ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DB11G_STBY';
ALTER DATABASE SET STANDBY
DATABASE TO MAXIMIZE PERFORMANCE;
-- Maximum Protection.
ALTER SYSTEM SET
LOG_ARCHIVE_DEST_2='SERVICE=db11g_stby AFFIRM SYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DB11G_STBY';
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE SET STANDBY
DATABASE TO MAXIMIZE PROTECTION;
ALTER DATABASE OPEN;
steps for setup datagaurd 11gr2
