DATA GUARD 11g SYNCHRONOUS REDO TRANSFER PROCESS

ARCHITECTURE (SYNC)-ZERO DATA LOSS

Process flow;

1 – The user initiates a transaction. This transaction is written to a redo buffer.

When the user commit the transaction then the LGWR process writes it redo log file.

2 – LNS (logwriter Network Service) reports to RFS (Remote File Service)

committed redo. RFS writes to standby redo log file. If we use physical standby, the
MRP (Managed Recovery Process) will apply to standby database . In  Logical
Standby this is made by LSP (Logical Standby Process) .

3 – RFS sends information to LNS that data is processed successfully. LNS transmits

this information to LGWR . Finally, commit information is send to the user that
initiated the transaction (transaction) .
Data transfer is ensured by the synchronous redo transfer. But there is a
disadvantage. If  a network failure occurs between production database (Primary)
and the standby database  or  Primary database can not access  to the standby
database then the primary database  will hang until standby response. In other
words, the primary database can not serve. To avoid such situation, I think the most
logical one to use “NET_TIMEOUT” parameter. With this parameter you can
determine the timeout period. In case of an outage, Primary waits until the timeout
period and will continue to serve when timeout period expires. Default value of this
parameter in 10g is 180s and in 11g is 30s.

DATA GUARD 11g ASYNCHRONOUS REDO TRANSFER PROCESS

ARCHITECTURE (ASYNC)

Asynchronous reod transfer flow;

1 – The user initiates a transaction. This transaction is written to a redo buffer.

When the user commit the transaction then the LGWR process writes it redo log file.
2 – LNS (logwriter Network Service) reports to RFS (Remote File Service)
committed redo. RFS writes to standby redo log file. If we use physical standby, the
MRP (Managed Recovery Process) will apply to standby database . In  Logical
Standby this is made by LSP (Logical Standby Process) .

3 – Once Redo Buffer is recycled, LNS  automatically reads redo log files and begins
to send redo from log files.

RFS doesn’t send information to LNS that data is processed successfully.

The most common used process architecture. Asynchronous redo transfer does not
guarantee zero data loss. The system has recovered with minimal data loss.

DATA GUARD PROTECTION MODES

There are 3 protection modes. Summarized in the table below.

The risk of data Transfer

Mode loss method Primary status

Zero data loss –

Maximum two-sided primary waits for the receipt of information. if it
Protection protection SYNC doesn’t respond to primary, primary hangs

Zero data loss – primary waits for the receipt of information. if it

Maximum single-sided doesn’t respond to primary, primary waits until
Availability protection SYNC the timeout parameter . (NET_TIMEOUT)

Maximum primary never waits for the receipt of

Performance least data loss ASYNC information
PHYSICAL STANDBY – REDO APPLY

Physical Standby Database is block by block  copy of production database. It uses

database recovery function to apply the changes. When redo apply is active, it can be
opened for reporting and querying in read-only mode (a feature that comes with the
Active Data Guard-11g). Also it can be used for backup operations. For opening in
Read-Write mode, you must enable Flashback log . Onece Flashback log enabled you
can open it in read-write mode after creating restore point. And again you can revert
to standby. I have explained above, with one of the desired modes you can transfer
redo. I’ll write the next article on Creating Standby Database with RMAN
Active Database Duplication in 11gR2

In some cases, you may want to create a time lag between the time when redo data is
received from the primary site and when it is applied to the standby database. If you
enabled the delayed apply, then real-time apply will be disabled. Real-time apply
can be activated as follows.
SQL>alter database recover managed standby database using current logfile
disconnect;

If the real-time apply feature is enabled as shown above , log apply services can
apply redo data as it is received, without waiting for the current standby redo log file
to be archived. This results in faster switchover and failover times because the
standby redo log files have been applied already to the standby database by the time
the failover or switchover begins. As the remote file server (RFS) process writes the
redo data to standby redo log files on the standby database, log apply services can
recover redo from standby redo log files as they are being filled.

Delayed apply can be activated;

SQL> alter database recover managed standby database delay 10;

SNAPSHOT STANDBY(11g)

A snapshot standby database is a fully updatable standby database that is created by

converting a physical standby database into a snapshot standby database. Snapshot
standby is a feature that comes with 11g. A snapshot standby database receives and
archives, but does not apply, redo data from a primary database. Redo data received
from the primary database is applied when a snapshot standby database is converted
back into a physical standby database. When it is converted back into a  physical
standby database, it discars all local updates. You can do test, patch, etc.  by opening
it in Read-write mode the test.

LOGICAL STANDBY – SQL APPLY

Logical Standby Databases are logically identical to primary databases although the
physical organization and structure of the data can be different. Logical Standby
Databases are updated using SQL statements. Logical standby database can be used
for recovery and reporting simultaneously. Determine if the primary database
contains tables and datatypes that were not supported by a logical stand by database.
If the primary database contains tables that were unsupported, log apply services
will exclude the tables applying to the logical stand by database. Run the following
queries to see unsupported tables.

select * from DBA_LOGSTDBY_UNSUPPORTED;

select * from LOGSTDBY_UNSUPPORTED_TABLES;

ACTIVE DATA GUARD (11g)

Thanks to this feature that comes with 11g standby database can be open in read-
only mode while redo apply  (Read-Only with Apply). Therefore, the database is
called the Active Standby. If we look at in terms of benefits to us of the Active Data
Guard; We can make our real-time reporting (while continuing to apply
redo),backup operations through the active standby database.Thus, we will reduce
the processing load of production. Production database will serve our customers
more effectively.

The other beauty that comes with 11g R2 is standby database count. Prior to 11g R2,
you can use 9 standby database at the same time. With 11g R2 you can use 32
standby database at the same time.

SWITCHOVER & FAILOVER

Finally, I want to mention briefly the terms of switchover and failover.Switchover is

the planned role change. It does not require re-installation of a new database. It can
be used to test interoperability of  standby database, OS and hardware maintenance.
The failover is the deformation of the production (primary) database and activating
standby database as the primary. It is not reversible. When enabled, re-create the
standby database.
*******************************************************************************

Data Guard Configurations:

A Data Guard configuration consists of one production database and one or more standby databases. The
databases in a Data Guard configuration are connected by Oracle Net and may be dispersed
geographically. There are no restrictions on where the databases are located, provided they can
communicate with each other.

>Dataguard Architecture

The Oracle 9i Data Guard architecture incorporates the following items: 

• Primary Database - A production database that is used to create standby databases. The archive logs
from the primary database are transfered and applied to standby databases. Each standby can only be
associated with a single primary database, but a single primary database can be associated with multiple
standby databases.

• Standby Database - A replica of the primary database.

• Log Transport Services - Control the automatic transfer of archive redo log files from the primary
database to one or more standby destinations.

• Network Configuration - The primary database is connected to one or more standby databases using
Oracle Net.

• Log Apply Services - Apply the archived redo logs to the standby database. The Managed Recovery
Process (MRP) actually does the work of maintaining and applying the archived redo logs.

• Role Management Services - Control the changing of database roles from primary to standby. The
services include switchover, switchback and failover.

• Data Guard Broker - Controls the creation and monitoring of Data Guard. It comes with a GUI and
command line interface.

Primary Database:

A Data Guard configuration contains one production database, also referred to as the primary database,
that functions in the primary role. This is the database that is accessed by most of your applications.

Standby Database:

A standby database is a transactionally consistent copy of the primary database. Using a backup copy of
the primary database, you can create up to nine standby databases and incorporate them in a Data Guard
configuration. Once created, Data Guard automatically maintains each standby database by transmitting
redo data from the primary database and then applying the redo to the standby database.
The types of standby databases are as follows:

Physical standby database:

Provides a physically identical copy of the primary database, with on disk database structures that are
identical to the primary database on a block-for-block basis. The database schema, including indexes, are
the same. A physical standby database is kept synchronized with the primary database, through Redo
Apply, which recovers the redo data received from the primary database and applies the redo to the
physical standby database.

Logical standby database:

Contains the same logical information as the production database, although the physical organization and
structure of the data can be different. The logical standby database is kept synchronized with the primary
database through SQL Apply, which transforms the data in the redo received from the primary database
into SQL statements and then executes the SQL statements on the standby database. 

>What are the services required on the primary and standby database ?

The services required on the primary database are:

• Log Writer Process (LGWR) - Collects redo information and updates the online redo logs. It can also
create local archived redo logs and transmit online redo to standby databases.
• Archiver Process (ARCn) - One or more archiver processes make copies of online redo logs either
locally or remotely for standby databases.
• Fetch Archive Log (FAL) Server - Services requests for archive redo logs from FAL clients running on
multiple standby databases. Multiple FAL servers can be run on a primary database, one for each FAL
request. .
The services required on the standby database are:
• Fetch Archive Log (FAL) Client - Pulls archived redo log files from the primary site. Initiates transfer of
archived redo logs when it detects a gap sequence.
• Remote File Server (RFS) - Receives archived and/or standby redo logs from the primary database.
• Archiver (ARCn) Processes - Archives the standby redo logs applied by the managed recovery process
(MRP).
• Managed Recovery Process (MRP) - Applies archive redo log information to the standby database.

>What is RTS (Redo Transport Services) in Dataguard?

It controls the automated transfer of redo data from the production database to one or more archival
destinations. The redo transport services perform the following tasks:
a) Transmit redo data from the primary system to the standby systems in the configuration.
b) Manage the process of resolving any gaps in the archived redo log files due to a network failure.
c) Automatically detect missing or corrupted archived redo log files on a standby system and
automatically retrieve replacement archived redo log files from the
primary database or another standby database. 
>What are the Protection Modes in Dataguard?

Data Guard Protection Modes

This section describes the Data Guard protection modes.
In these descriptions, a synchronized standby database is meant to be one that meets the minimum
requirements of the configured data protection mode and that does not have a redo gap. 
Maximum Availability

This protection mode provides the highest level of data protection that is possible without compromising
the availability of a primary database. Transactions do not commit until all redo data needed to recover
those transactions has been written to the online redo log and to at least one synchronized standby
database. If the primary database cannot write its redo stream to at least one synchronized standby
database, it operates as if it were in maximum performance mode to preserve primary database
availability until it is again able to write its redo stream to a synchronized standby database.
This mode ensures that no data loss will occur 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

This protection mode provides the highest level of data protection that is possible without affecting the
performance of a primary database. This is accomplished by allowing transactions to commit as soon as
all redo data generated by those transactions has been written to the online log. Redo data is also written
to one or more standby databases, but this is done asynchronously with respect to transaction
commitment, so primary database performance is unaffected by delays in writing redo data to the standby
database(s).
This protection mode offers slightly less data protection than maximum availability mode and has
minimal impact on primary database performance.
This is the default protection mode.

Maximum Protection

This protection mode ensures that zero data loss occurs if a primary database fails. To provide this level
of protection, the redo data needed to recover a transaction must be written to both the online redo log and
to at least one synchronized standby database before the transaction commits. To ensure that data loss
cannot occur, the primary database will shut down, rather than continue processing transactions, if it
cannot write its redo stream to at least one synchronized standby database.
Because this data protection mode prioritizes data protection over primary database availability, Oracle
recommends that a minimum of two standby databases be used to protect a primary database that runs in
maximum protection mode to prevent a single standby database failure from causing the primary database
to shut down.

How to delay the application of logs to a physical standby? 

A standby database automatically applies redo logs when they arrive from the primary database. But in
some cases, we want to create a time lag between the archiving of a redo log at the primary site, and the
application of the log at the standby site.

Modify the LOG_ARCHIVE_DEST_n initialization parameter on the primary database to set a delay for
the standby database.
Example: For 60min Delay:
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=stdby_srvc DELAY=60';
The DELAY attribute is expressed in minutes.
The archived redo logs are still automatically copied from the primary site to the standby site, but the logs
are not immediately applied to the standby database. The logs are applied when the specified time interval
expires.

>Steps to create Physical Standby database?

1.Take a full hot backup of Primary database

2.Create standby control file
3.Transfer full backup, init.ora, standby control file to standby node.
4.Modify init.ora file on standby node.
5.Restore database
6.Recover Standby database
(Alternatively, RMAN DUPLICATE DATABASE FOR STANDBY DO RECOVERY can be also used)
7.Setup FAL_CLIENT and FAL_SERVER parameters on both sides
8.Put Standby database in Managed Recover mode

What are the DATAGUARD PARAMETERS in Oracle?

Set Primary Database Initialization Parameters

----------------------------------------------
On the primary database, you define initialization parameters that control redo transport services while
the database is in the primary role. There are additional parameters you need to add that control the
receipt of the redo data and log apply services when the primary database is transitioned to the standby
role.

DB_NAME=chicago
DB_UNIQUE_NAME=chicago
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'
CONTROL_FILES='/arch1/chicago/control1.ctl', '/arch2/chicago/control2.ctl'
LOG_ARCHIVE_DEST_1=
'LOCATION=/arch1/chicago/
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_2=
'SERVICE=boston LGWR ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
LOG_ARCHIVE_FORMAT=%t_%s_%r.arc
LOG_ARCHIVE_MAX_PROCESSES=30

Primary Database: Standby Role Initialization Parameters

FAL_SERVER=boston
FAL_CLIENT=chicago
DB_FILE_NAME_CONVERT='boston','chicago'
LOG_FILE_NAME_CONVERT= '/arch1/boston/','/arch1/chicago/','/arch2/boston/','/arch2/chicago/'
STANDBY_FILE_MANAGEMENT=AUTO

Prepare an Initialization Parameter File for the Standby Database

-----------------------------------------------------------------
Create a text initialization parameter file (PFILE) from the server parameter file (SPFILE) used by the
primary database; a text initialization parameter file can be copied to the standby location and modified.
For example:
CREATE PFILE='/tmp/initboston.ora' FROM SPFILE;

Modifying Initialization Parameters for a Physical Standby Database.

DB_NAME=chicago
DB_UNIQUE_NAME=boston
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'
CONTROL_FILES='/arch1/boston/control1.ctl', '/arch2/boston/control2.ctl'
DB_FILE_NAME_CONVERT='chicago','boston'
LOG_FILE_NAME_CONVERT= '/arch1/chicago/','/arch1/boston/','/arch2/chicago/','/arch2/boston/'
LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc
LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/boston/
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) 
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_2= 'SERVICE=chicago LGWR ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
STANDBY_FILE_MANAGEMENT=AUTO
FAL_SERVER=chicago
FAL_CLIENT=boston