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
Do you like this post? Please share this article.
HTML Link Code:
Post a Comment