Oracle DataGuard Broker - HA AND Disaster Recovery !!
Oracle DataGuard Broker - HA AND Disaster Recovery !!
In this article I present about Data Guard Broker and also steps to configure Data Guard Broker.
The Data Guard Broker logically groups Primary and all Standby databases in a DATA GUARD setup
into a broker configuration to manage and monitor them. All operations can be performed either
through OEM (GUI) or the broker’s Command line Interface (DGMGRL).
CONFIGURATION FILES
By default, the Data Guard Broker has two copies of configuration files located at $ORACLE_HOME/dbs
with file name of dr1_db_unique_name.dat and dr2_db_unique_name.dat
When the broker is started for the first time, the configuration files are automatically created
and names using default path name and filename. You must set these parameters on the primary
(production) database as well as on any standby databases.
If you wish to override you can using alter system set command? In My Opinion, It’s a bad practice
to keep both files in same place especially on the Primary database.
You can only be set or changed when the Data Guard broker is not running (DG_BROKER_START=FALSE).
Its recommend to place these files on different disks so single disk failure does NOT affect your
broker configuration. The Primary has the master copies of the configuration files, because the
broker is Primary-Centric. All changes to these files are done by the primary, even if you are on
the standby server the configuration changes will be passed to the primary via NSV-DRC processes
and the DMON process will make the change which is then propagated back to the standby databases.
If the primary has a problem then each standby database has a copy, when a failover occurs the
Standby that becomes the primary then become the master of those configuration files.
DMON PROCESS
DMON stands for Data Guard Monitor Process specific to Data Guard Broker. If Data Guard Broker is
enabled, Oracle uses Data Guard Broker Monitor (DMON) background process to manage and monitor
the primary and standby databases as a unified configuration.
This Process runs for every database instance that is managed by broker and gets enabled when you
set DG_BROKER_START=TRUE. By default the value of DG_BROKER_START=FALSE.
DMON is the server side component that interacts with local database and the DMON process of the
other database to perform requested function. This is responsible for monitoring health of the
broker configuration and maintains consistent description of configuration files.
BACKGROUND PROCESSES
In Data Guard Broker configuration, DMON Process on the Primary database that is the owner of the
configuration, all Commands to modify any configuration comes only from the Primary (though you
may connect any database using DGMGRL Client), all Standby databases receive all configuration
changes via the Primary.
When DMON needs to execute some SQL statement, (if SQL is for Primary with the help of RFS
process, it will execute it directly. Suppose SQL is for the standby database, the RSM asks the
NSV process to send it to the standby database. The configuration commands executed by the
broker during the database startup or may be required to be run during Data Guard setup.
NSV processes are responsible for making connection with the remote database.
DMON or RSM process may ask NSV process to connect to other node for any work request.
DMON may need to send some communication to the other node and RSM may have to get some data
through SQL from other node.
Each NSV Process will have DRC process on the Standby database, which performs the actual work on
behalf of the NSV process, the DRS process on the standby will return the status back to NSV
Process on the Primary.
The DMON Process of the Primary database tries to communicate with each Standby via NSV-DRC pair
to establish communication and configuration info so that the standby can start and apply services.
DRCn
NSV Processes contact DRC process running on the other node to establish the connection, so DRC
acts like a receiver on the other node.
When using RAC environment, there are some set of processes called the internode servers (INSV).
Which maintain a connection between the nodes in the cluster to ensure that the broker on each
node knows the state of the cluster.
The third part of broker setup is the interface through which users will interact with broker.
Let’s start to configure DGMGRL.
# ON PRIMARY DATABASE
# ON STANDBY DATABASE
# ON PRIMARY DATABASE
# ON STANDBY DATABASE
The value of db_domain is null. GLOBAL_DBNAME should be set db_unique_name_DGMGRL, so the value of
GLOBAL_DBNAME = crms_DGMGRL for Primary database and for Standby GLOBAL_DBNAME = stbycrms_DGMGRL.
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.130)(PORT = 1521))
)
)
ADR_BASE_LISTENER = /u01/app/oracle
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = crms)
(GLOBAL_DBNAME = crms_DGMGRL)
(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_home1)
)
(SID_DESC =
(SID_NAME = crms)
(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_home1)
)
)
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.131)(PORT = 1521))
)
)
ADR_BASE_LISTENER = /u02/app/oracle
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = stbycrms)
(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_home1)
)
(SID_DESC =
(SID_NAME = stbycrms)
(GLOBAL_DBNAME = stbycrms_DGMGRL)
(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_home1)
)
)
$ dgmgrl
DGMGRL for Linux: Version 11.2.0.1.0 - Production
# ON PRIMARY DATABASE
DGMGRL> create configuration dgcrms as primary database is crms connect identifier is CRMSDB;
Configuration "dgcrms" created with primary database "crms"
Configuration - dgcrms
Protection Mode : MaxPerformance
Databases : crms - Primary database
Fast-Start Failover : DISABLED
Configuration Status : DISABLED
Configuration - dgcrms
Protection Mode: MaxPerformance
Databases: crms - Primary database
stbycrms - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status: DISABLED
Configuration - dgcrms
Protection Mode: MaxPerformance
Databases:
crms - Primary database
stbycrms - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status: SUCCESS
Database - crms
Role: PRIMARY
Intended State: TRANSPORT-ON
Instance(s):
crms
Properties:
DGConnectIdentifier = 'crmsdb'
ObserverConnectIdentifier = ''
LogXptMode = 'ASYNC'
DelayMins = '0'
Binding = 'optional'
MaxFailure = '0'
MaxConnections = '1'
ReopenSecs = '300'
NetTimeout = '30'
RedoCompression = 'DISABLE'
LogShipping = 'ON'
PreferredApplyInstance = ''
ApplyInstanceTimeout = '0'
ApplyParallel = 'AUTO'
StandbyFileManagement = 'AUTO'
ArchiveLagTarget = '0'
LogArchiveMaxProcesses = '4'
LogArchiveMinSucceedDest = '1'
DbFileNameConvert = '...
LogFileNameConvert = '...
FastStartFailoverTarget = ''
StatusReport = '(monitor)'
InconsistentProperties = '(monitor)'
InconsistentLogXptProps = '(monitor)'
SendQEntries = '(monitor)'
LogXptStatus = '(monitor)'
RecvQEntries = '(monitor)'
HostName = 'SERVER1.ORACLE.COM'
SidName = 'crms'
StaticConnectIdentifier =
'(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=SERVER1.ORACLE.COM)(PORT=1521))(CONNECT_DATA=
(SERVICE_NAME=crms_DGMGRL)(INSTANCE_NAME=crms)(SERVER=DEDICATED)))'
StandbyArchiveLocation = 'USE_DB_RECOVERY_FILE_DEST'
AlternateLocation = ''
LogArchiveTrace = '0'
LogArchiveFormat = '%t_%s_%r.dbf'
TopWaitEvents = '(monitor)'
Database - stbycrms
Properties:
DGConnectIdentifier = 'stby_crmsdb'
ObserverConnectIdentifier = ''
LogXptMode = 'ASYNC'
DelayMins = '0'
Binding = 'OPTIONAL'
MaxFailure = '0'
MaxConnections = '1'
ReopenSecs = '300'
NetTimeout = '30'
RedoCompression = 'DISABLE'
LogShipping = 'ON'
PreferredApplyInstance = ''
ApplyInstanceTimeout = '0'
ApplyParallel = 'AUTO'
StandbyFileManagement = 'AUTO'
ArchiveLagTarget = '0'
LogArchiveMaxProcesses = '4'
LogArchiveMinSucceedDest = '1'
DbFileNameConvert = '...
LogFileNameConvert = '...
FastStartFailoverTarget = ''
StatusReport = '(monitor)'
InconsistentProperties = '(monitor)'
InconsistentLogXptProps = '(monitor)'
SendQEntries = '(monitor)'
LogXptStatus = '(monitor)'
RecvQEntries = '(monitor)'
HostName = 'SERVER2.ORACLE.COM'
SidName = 'stbycrms'
StaticConnectIdentifier =
'(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=SERVER2.ORACLE.COM)(PORT=1521))(CONNECT_DATA=
(SERVICE_NAME=stbycrms_DGMGRL)(INSTANCE_NAME=stbycrms)(SERVER=DEDICATED)))'
StandbyArchiveLocation = 'USE_DB_RECOVERY_FILE_DEST'
AlternateLocation = ''
LogArchiveTrace = '0'
LogArchiveFormat = '%t_%s_%r.dbf'
TopWaitEvents = '(monitor)'
DGMGRL> help
SYS> alter database recover managed standby database disconnect from session;
DGMGRL> edit database 'stbycrms' set state='ONLINE';
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "crms" on database "crms"
Starting instance "crms"...
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is "stbycrms"
Configuration - dgcrms
POINTS TO NOTE
The broker automatically enables real-time-apply on standby databases. When Redo Apply in real
time, the redo data is recovered directly from the standby redo log files as they are being filled.
The standby database does not have to wait for the log files to be archived before applying redo
data from the archived redo log files. This minimizes the transactional lag between the primary
and the standby. Reference doc here
THREAD# MAX(SEQUENCE#)
---------- --------------
1 14722
# ON STANDBY DATABASE
SYS> select thread#, max(sequence#) from v$archived_log where applied='YES' group by thread#;
THREAD# MAX(SEQUENCE#)
---------- --------------
1 14722
# ON STANDBY DATABASE
Database - crms
Role: PHYSICAL STANDBY
Intended State : APPLY-ON
Transport Lag : 0 seconds
Apply Lag : 0 seconds
Real Time Query: OFF
Instance(s) : crms
Database Status : SUCCESS
Database - stbycrms
Role : PRIMARY
Intended State: TRANSPORT-ON
Instance(s) : stbycrms
Database Status : SUCCESS
Database dismounted.
ORACLE instance shut down.
Configuration - dgcrms
# ON PRIMARY DATABASE
# ON STANDBY DATABASE
Database - crms
Role: PRIMARY
Intended State: TRANSPORT-ON
Instance(s): crms
Database Status: SUCCESS
Database - stbycrms
We can change Data Guard Protection mode using Data Guard command line interface (DGMGRL).
Already Physical Standby database is configured as MAXIMUM PERFORMANCE.
This scenario sets Protection mode of the configuration would be MAXIMUM AVALIABILITY.
Maximum Availability Protection mode requires standby redolog files on the standby database. In
order to change from MAXIMUM PERFORMANCE to MAXIMUM AVAILABILITY the Log Transport Mode LogXptMode
must be set to SYNC.
Configuration - dgcrms
The broker will not allow this command to succeed unless the standby database is configured with
standby redo log files in the configuration.
Now you can change the protection mode to MAXIMUM AVAILABILITY. The protection mode is changed
using the EDIT CONFIGURATION SET PROTECTION MODE AS command.
Suppose configuration is disabled when you enter above command, protection mode is not applied
until you enable the configuration using ENABLE CONFIGURATION command.
Configuration - dgcrms
Protection Mode: MaxAvailability
Databases:
crms - Primary database
stbycrms - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status: SUCCESS
Configuration - dgcrms
Configuration - dgcrms
As we know changing the protection mode is very simple using DGMGRL. But anyhow a point to note that when
you change protection mode from MAX PERFORMANCE to MAX PROTECTION, ensure first process would be change to
max availability and then to max protection. Otherwise Primary will be taken down. Let’s see
Now you can set the protection mode to Maximum Protection from Maximum Performance. Changing
directly to Maximum Protection mode requires the restart of the primary database.
Configuration - dgcrms
# ON PRIMARY DATABASE
LOGXPTMODE =SYNC/ASYNC
ASYNC should be used when LGWR is used to transfer logs in MAX PERFORMANCE mode. This is default.
SYNC is for MAX AVAILABILITY or MAX PROTECTION mode.
Before you perform switchover process, you need to change database property LogXptMode of the
Primary database also it is taken care during a transition.
Already we have changed LogXptMode=SYNC in primary database to send redo data for standby database.
But still we maintain LogXptMode=ASYNC in standby database. Before switch over process we need to
set LogXptMode=SYNC at both side, If Protection mode is MAX AVAILABILITY or MAX PROTECTION.
Error: ORA-16627:
operation disallowed since no standby databases would remain to support protection mode Failed.
Steps to convert a Physical Standby database to Snapshot Standby database using Data Guard broker
command line interface DGMGRL. Redo data will continue to be received by the database while it is
operating as a snapshot standby database but redo will not be applied until the Snapshot Standby
is converted back into Physical Standby database.
The flashback feature is required to create a snapshot standby database. If flashback database is
disabled, it is enabled automatically during conversion to a snapshot standby database.
Configuration - dgcrms
$ tail –f alert_stbycrms.log
..
...
Configuration - dgcrms
OPEN_MODE FLASHBACK_ON
-------------------- ------------------
READ WRITE RESTORE POINT ONLY
THREAD# MAX(SEQUENCE#)
---------- --------------
1 14944
SYS> select thread#, max(sequence#) from v$archived_log where applied='YES' group by thread#;
THREAD# MAX(SEQUENCE#)
---------- --------------
1 14943
THREAD# MAX(SEQUENCE#)
---------- --------------
1 14948
SYS> select thread#, max(sequence#) from v$archived_log where applied='YES' group by thread#;
THREAD# MAX(SEQUENCE#)
---------- --------------
1 14943
As I said above, redo is being received from the primary database, but is not applied. The snapshot
standby database should be revert back to a physical Standby then only it would be resynchronized
with primary by applying redo data which was earlier shipped from the primary yet not applied.
Any updates made to the database while it was operating as a snapshot standby will be rejected. The
conversion process does perform shutdown of the standby database. The shutdown is required for the FLASHBACK
DATABASE operation.
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "stbycrms" on database "stbycrms"
Starting instance "stbycrms"...
ORACLE instance started.
Database "stbycrms" converted successfully
OPEN_MODE FLASHBACK_ON
-------------------- ------------------
MOUNTED NO
Configuration - dgcrms
# ON PRIMARY DATABSE
THREAD# MAX(SEQUENCE#)
---------- --------------
1 14964
# ON STANDBY DATABASE
SYS> select thread#, max(sequence#) from v$archived_log where applied='YES' group by thread#;
THREAD# MAX(SEQUENCE#)
---------- --------------
1 14964
Now MRP process is running. All shipped redo data has been applied on the standby side. Now the
Primary database and Standby database is in SYNC.
Suppose Primary Database crash and cannot be recovered in a short period, then we need to perform
failover operation. After failover operation, we would remove Primary database from Data guard
configuration and have to recreate it.
If Flashback enabled on the Primary database before the failover operation, you can bring the old
Primary back into the configuration as a Standby database. It’s possible to move the old Primary
database back in time to point just before where the failure occurred.
The only consideration is you must have enabled Flashback Database on the Primary database before
the failover. It’s always good idea and recommended to enable flashback in Standby database also.
ENVIRONMENT DETAILS
SWITCHOVER_STATUS FLASHBACK_ON
-------------------- ------------------
TO STANDBY YES
FLASHBACK_ON
------------------
YES
Configuration - dgcrms
Configuration Status:
ORA-01034: ORACLE not available
ORA-16625: cannot reach database "crms"
Configuration - dgcrms
Failed.
Reinstatement of database "crms" failed
STANDBY_BECAME_PRIMARY_SCN
--------------------------
221022633
After a failover (when the Physical Standby becomes the Primary), Oracle writes the failover SCN
to the control file. We can query STANDBY_BECAME_PRIMARY_SCN column of the V$DATABASE fixed view
so that it’s easy to determine at which the old standby database became the new primary database.
$ tail –f alert_crms.log
Above SQL statement will dismount the database after successfully converting the control file to
a standby control file.
STATUS
------------
STARTED
You can start Redo Apply or real-time apply on the new Physical Standby database.
# TO START REAL-TIME-APPLY
SQL> alter database recover managed standby database using current logfile disconnect;
Database altered.
6 rows selected.
Here, redo transport services do not transmit redo data to the new standby database because
destination is not available. So configure valid destination to ship redo data to the standby site.
Configuration - dgcrms
Configuration - dgcrms
Data Guard Broker command line interface (DGMGRL) utility that automates and centralizes Data
Guard management. Using DGMGRL we can run consecutive operations such as (switchover/failover)
with just one command unlike SQL*Plus interface.
$ cd $ORACLE_HOME/dbs
$ mv dr1crms.dat dr1crms.dat.bkp
$ mv dr2crms.dat dr2crms.dat.bkp
$ cd $ORACLE_HOME/dbs
$ mv dr1stbycrms.dat dr1stbycrms.dat.bkp
$ mv dr2stbycrms.dat dr2stbycrms.dat.bkp
We have safely removed Data Guard broker configuration. Help this doc helps to you.
Nice link for DGMGRL commands given here.