Oracle Data Guard Operation Reference V1.0

AHMED MOAWAD
IT Operation
Technical Documents
Operation Reference for

Oracle Data Guard
Written by Ahmed S. Moawad

Samy_ahmed@hotmail.com
November 1st, 2020
Document Version 1.0
Version Control Table
Date Requester Reviewer Subject location
03/11/2020 Adel Ali Shiran Author v0.2 Add Static listenerAdded to
registration to general
manual prerequisites
configuration @page6
(Listener Setup)
04/11/2020 Saad Mahdi Alboqami Author v0.3 Enhance RMAN Channels added
duplication Script to duplicate
performance by commands
adding/controlling @page13
explicit channels.
04/11/2020 Aijaz Khan Author v0.4 Consider windows Page 10.
Commands, in
case used
platform is
windows
05/11/2020 Ahmed Moawad Author v0.5 Add performance Adding page
Tuning Elements. 18/19
08/11/2020 Ahmed Moawad Author v0.6 Adding snapshot Adding page
Standby using 25/26
broker
Ahmed S. Moawad <samy_ahmed@hotmail.com>

2
Table of Contents
Version Control Table ...................................................................................................................... 1
Introduction ..................................................................................................................................... 5
Setup Options .................................................................................................................................. 5
Assumptions ................................................................................................................................ 5
Primary Server Setup ................................................................................................................... 5
Logging..................................................................................................................................... 5
Initialization Parameters ......................................................................................................... 6
Service Setup ........................................................................................................................... 7
Listener Setup .......................................................................................................................... 7
Backup Primary Database........................................................................................................ 8
Create Standby Controlfile and PFILE ...................................................................................... 8
Standby Server Setup (Manual)................................................................................................... 9
Windows Consideration ........................................................................................................ 10
Start Listener ......................................................................................................................... 10
Restore Backup ...................................................................................................................... 10
Create Redo Logs ................................................................................................................... 10
Standby Server Setup (DUPLICATE) ........................................................................................... 11
Copy Files ............................................................................................................................... 11
Start Listener ......................................................................................................................... 11
Create Standby Redo Logs on Primary Server ....................................................................... 12
Create Standby Using (DUPLICATE) ....................................................................................... 12
Start & Stop Apply Process ............................................................................................................ 14
Configure Oracle Data Guard Broker............................................................................................. 14
Create an Oracle Data Guard Broker configuration for the primary database. ........................ 14
Add the standby database to the Oracle Data Guard Broker configuration. ............................ 15
Configure the apply instance for the standby database. .......................................................... 15
To verify that the Oracle Data Guard Broker configuration is working correctly, .................... 15
Monitoring Scripts and informational views ................................................................................. 17
Redo Transport Performance Consideration ................................................................................ 18
AFFIRM and NOAFFIRM ............................................................................................................. 18
SYNC and ASYNC ........................................................................................................................ 19
COMPRESSION........................................................................................................................... 19

3
DELAY......................................................................................................................................... 19
Apply Process Tuning Elements..................................................................................................... 20
Option#1: Set Parallel Recovery to Twice the Number of CPUs on One Standby Host ............ 20
Option#2: Set PARALLEL_EXECUTION_MESSAGE_SIZE = 4096 or more ................................... 21
Option#3: Set DB_BLOCK_CHECKING=FALSE for Faster Redo Apply Rates .............................. 21
Option#4: Tune Disk I/O ............................................................................................................ 21
Basic Administration Tasks ............................................................................................................ 21
Read-Only Standby and Active Data Guard............................................................................... 21
Changing Protection Mode........................................................................................................ 22
Database Switchover ................................................................................................................. 23
Failover ...................................................................................................................................... 24
Flashback Database ................................................................................................................... 24
Snapshot Standby (11g+) (Manual Approach) .......................................................................... 26
Snapshot Standby (11g+) (Using Broker)................................................................................... 27
Skip Unresolvable Gap for missing or corrupted archive log for physical standby ................... 29

4
Introduction
This document written by Ahmed Moawad as an Oracle Expert Consultant for Bank Albilad, to
cover oracle data guard operation an administration aspect.
The content of this document applied to:
Oracle Database - Enterprise Edition - Version 10.2.x.x to 12.2.x.x
And Aimed to cover following subjects:
 Setup Options
 Start and stop replication
 Monitoring Scripts and informational views
 Basic Administration Tasks
 Troubleshooting Scenarios
Setup Options
Oracle Data guard can be settled via various methods and option manual, via OEM, via Grid
Control, .. etc., we will consider only here manual options as it easier to debug and discover
errors if occurred, simply first you have to prepare the primary DB, then create the standby via
rman duplicate for standby command, or manual via regular backup and restore options.
Assumptions
 You have two servers with an operating system and Oracle installed on them.
 The primary server has a running database instance.
 The standby server has a software only installation.
 Oracle 11g used as example during the document and version differences mentioned
during document.
Primary Server Setup

all following steps and checks to be performed on primary database.
Logging
Check that the primary database is in archivelog mode, and if not set it on archivelog mode.
> SELECT log_mode FROM v$database;
LOG_MODE
------------
NOARCHIVELOG
If it is noarchivelog mode, switch is to archivelog mode.
> SHUTDOWN IMMEDIATE;

> STARTUP MOUNT;
> ALTER DATABASE ARCHIVELOG;

5
> ALTER DATABASE OPEN;
Enabled forced logging by issuing the following command.
ALTER DATABASE FORCE LOGGING;
Initialization Parameters
Check the setting for the DB_NAME and DB_UNIQUE_NAME parameters. In this case they are
both set to "DB11G" on the primary database.
> show parameter db_name
NAME TYPE VALUE

------------------------------------ ----------- -------------------------
db_name string DB11G
> show parameter db_unique_name
NAME TYPE VALUE

------------------------------------ ----------- -------------------------
db_unique_name string DB11G
The DB_NAME of the standby database will be the same as that of the primary, but it must have
a different DB_UNIQUE_NAME value. The DB_UNIQUE_NAME values of the primary and
standby database should be used in the DG_CONFIG setting of the LOG_ARCHIVE_CONFIG
parameter. For this example, the standby database will have the value "DB11G_STBY".
> ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(DB11G,DB11G_STBY)';
Set suitable remote archive log destinations. In this case I'm using the fast recovery area for the
local location, but you could specify a location explicitly if you prefer. Notice the SERVICE and
the DB_UNIQUE_NAME for the remote location reference the standby location.
> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=db11g_stby NOAFFIRM ASYNC

VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DB11G_STBY';
> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;
The LOG_ARCHIVE_FORMAT and LOG_ARCHIVE_MAX_PROCESSES parameters must be set to

appropriate values and the REMOTE_LOGIN_PASSWORDFILE must be set to exclusive.
ALTER SYSTEM SET LOG_ARCHIVE_FORMAT='%t_%s_%r.arc' SCOPE=SPFILE;

ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=4;
ALTER SYSTEM SET REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE SCOPE=SPFILE;
In addition to the previous setting, it is recommended to make sure the primary is ready to
switch roles to become a standby. For that to work properly we need to set the following
parameters. Adjust the *_CONVERT parameters to account for your filename and path
differences between the servers.

6
ALTER SYSTEM SET FAL_SERVER=DB11G_STBY;
--ALTER SYSTEM SET DB_FILE_NAME_CONVERT='DB11G_STBY','DB11G' SCOPE=SPFILE;
--ALTER SYSTEM SET LOG_FILE_NAME_CONVERT='DB11G_STBY','DB11G' SCOPE=SPFILE;
ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;
Remember, some of the parameters are not modifiable, so the database will need to be
restarted before they take effect.
Service Setup
Entries for the primary and standby databases are needed in the
"$ORACLE_HOME/network/admin/tnsnames.ora" files on both servers. You can create these
using the Network Configuration Utility (netca) or manually. The following entries were used
during this setup.
DB11G =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = ol5-112-dga1)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = DB11G.WORLD)
)
)
DB11G_STBY =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = ol5-112-dga2)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = DB11G.WORLD)
)
)
Listener Setup
This setup is important and should be typically performed on both servers, can be summarized
in flowing points
 Static Service Registration

 Start Listener
1. Static Service Registration
Use “netca” to add required service, or edit listener.ora file as following example
# Global Name, hostname listed with listener is different based on Server Role
#
SID_LIST_LISTENER =
(SID_LIST =

7
(SID_DESC =
(GLOBAL_DBNAME = DB11G.WORLD)
(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)
(SID_NAME = DB11G)
)
)
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = ol5-112-dga1.localdomain)(PORT =
1521))
)
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
)
)
ADR_BASE_LISTENER = /u01/app/oracle
2. Start Listener
Make sure the listener is started on the standby server.
$ lsnrctl reload
or
$ lsnrctl stop
$ lsnrctl start
Backup Primary Database

If you are planning to use an active duplicate to create the standby database, then this step is
unnecessary. For a backup-based duplicate, or a manual restore, take a backup of the primary
database.
$ rman target=/
RMAN> BACKUP DATABASE PLUS ARCHIVELOG;
Create Standby Controlfile and PFILE

Create a controlfile for the standby database by issuing the following command on the primary
database.
ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/db11g_stby.ctl';
Create a parameter file for the standby database.

8
CREATE PFILE='/tmp/initDB11G_stby.ora' FROM SPFILE;
Amend the PFILE making the entries relevant for the standby database. I'm making a replica of
the original server, so in my case I only had to amend the following parameters.
*.db_unique_name='DB11G_STBY'
*.fal_server='DB11G'
*.log_archive_dest_2='SERVICE=db11g ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DB11G'
Standby Server Setup (Manual)

Copy Files
Create the necessary directories on the standby server.
$ mkdir -p /u01/app/oracle/oradata/DB11G
$ mkdir -p /u01/app/oracle/fast_recovery_area/DB11G
$ mkdir -p /u01/app/oracle/admin/DB11G/adump
Copy the files from the primary to the standby server.
 Standby controlfile
 Backups and archivelogs
 Parameter files
 Password file
$ # Standby controlfile to all locations.

$ scp oracle@ol5-112-dga1:/tmp/db11g_stby.ctl
/u01/app/oracle/oradata/DB11G/control01.ctl
$ cp /u01/app/oracle/oradata/DB11G/control01.ctl
/u01/app/oracle/fast_recovery_area/DB11G/control02.ctl
$ # Archivelogs and backups

$ scp -r oracle@ol5-112-
dga1:/u01/app/oracle/fast_recovery_area/DB11G/archivelog
/u01/app/oracle/fast_recovery_area/DB11G
$ scp -r oracle@ol5-112-
dga1:/u01/app/oracle/fast_recovery_area/DB11G/backupset
/u01/app/oracle/fast_recovery_area/DB11G
$ # Parameter file.
$ scp oracle@ol5-112-dga1:/tmp/initDB11G_stby.ora /tmp/initDB11G_stby.ora
$ # Remote login password file.

$ scp oracle@ol5-112-dga1:$ORACLE_HOME/dbs/orapwDB11G $ORACLE_HOME/dbs
Notice, the backups were copied across to the standby server as part of the FRA copy. If your
backups are not held within the FRA, you must make sure you copy them to the standby server
and make them available from the same path as used on the primary server.

9
Windows Consideration
In case we running on windows consider to create windows service using oracle utility ”oradim”
as following
> oradim -new -sid DATAGUARD -startmode m
Start Listener
Make sure the listener setup performed in previous steps and started on the standby server.
$ lsnrctl start
Status should show static service registration
$ lsnrctl status
Restore Backup
Create the SPFILE form the amended PFILE.
$ export ORACLE_SID=DB11G (use “set” in case of windows)

$ sqlplus / as sysdba
SQL> CREATE SPFILE FROM PFILE='/tmp/initDB11G_stby.ora';
Restore the backup files.
$ export ORACLE_SID=DB11G (use “set” in case of windows)

$ rman target=/
RMAN> STARTUP MOUNT;

RMAN> RESTORE DATABASE;
Create Redo Logs

Create online redo logs for the standby. It's a good idea to match the configuration of the
primary server.
ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL;

ALTER DATABASE ADD LOGFILE ('/u01/app/oracle/oradata/DB11G/online_redo01.log')
SIZE 50M;
SIZE 50M;
SIZE 50M;
ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;
In addition to the online redo logs, you should create standby redo logs on both the standby and
the primary database (in case of switchovers). The standby redo logs should be at least as big as

10
the largest online redo log and there should be one extra group per thread compared the online
redo logs. In my case, the following standby redo logs must be created on both servers.
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 10

('/u01/app/oracle/oradata/DB11G/standby_redo01.log') SIZE 50M;
Once this is complete, we can start the apply process.
Standby Server Setup (DUPLICATE)

This section is just repeat to manual setup with different “standby server” restore option, in this
case with RMAN “duplicate for standby” command, use it if you have good / local network
between primary and standby servers.
Copy Files
Create the necessary directories on the standby server.
$ mkdir -p /u01/app/oracle/oradata/DB11G
$ mkdir -p /u01/app/oracle/fast_recovery_area/DB11G
$ mkdir -p /u01/app/oracle/admin/DB11G/adump
Copy the files from the primary to the standby server.
 Standby controlfile
 Parameter files
 Password file
$ # Standby controlfile to all locations.

$ scp oracle@ol5-112-dga1:/tmp/db11g_stby.ctl
/u01/app/oracle/oradata/DB11G/control01.ctl
$ cp /u01/app/oracle/oradata/DB11G/control01.ctl
/u01/app/oracle/fast_recovery_area/DB11G/control02.ctl
$ # Parameter file.
$ scp oracle@ol5-112-dga1:/tmp/initDB11G_stby.ora /tmp/initDB11G_stby.ora
$ # Remote login password file.

$ scp oracle@ol5-112-dga1:$ORACLE_HOME/dbs/orapwDB11G $ORACLE_HOME/dbs
Start Listener
When using active duplicate, the standby server requires static listener configuration in a
"listener.ora" file. In this case I used the following configuration.

11
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = DB11G.WORLD)
(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)
(SID_NAME = DB11G)
)
)
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = ol5-112-dga2.localdomain)(PORT =
1521))
)
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
)
)
ADR_BASE_LISTENER = /u01/app/oracle
Make sure the listener is started on the standby server.
$ lsnrctl start
Status should show static service registration
$ lsnrctl status
Create Standby Redo Logs on Primary Server

The DUPLICATE command automatically creates the standby redo logs on the standby. To make
sure the primary database is configured for switchover, we must create the standby redo logs
on the primary server.
ALTER DATABASE ADD STANDBY LOGFILE

Create Standby Using (DUPLICATE)

Start the auxillary instance on the standby server by starting it using the temporary "init.ora"
file.
$ export ORACLE_SID=DB11G

12
$ sqlplus / as sysdba
SQL> STARTUP NOMOUNT PFILE='/tmp/initDB11G_stby.ora';
Connect to RMAN, specifying a full connect string for both the TARGET and AUXILLARY
instances. DO not attempt to use OS authentication.
$ rman TARGET sys/password@DB11G AUXILIARY sys/password@DB11G_STBY
Now issue the following DUPLICATE command.
RUN
{
allocate channel prmy1 type disk;
ALLOCATE AUXILIARY CHANNEL aux1 DEVICE TYPE DISK;

DUPLICATE TARGET DATABASE
FOR STANDBY
FROM ACTIVE DATABASE
DORECOVER
SPFILE
SET db_unique_name='DB11G_STBY' COMMENT 'Is standby'
SET LOG_ARCHIVE_DEST_2='SERVICE=db11g ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DB11G'
SET FAL_SERVER='DB11G' COMMENT 'Is primary'
NOFILENAMECHECK;
}
A brief explanation of the individual clauses is shown below.
 FOR STANDBY: This tells the DUPLICATE command is to be used for a standby, so it will
not force a DBID change.
 FROM ACTIVE DATABASE: The DUPLICATE will be created directly from the source
datafile, without an additional backup step.
 DORECOVER: The DUPLICATE will include the recovery step, bringing the standby up to
the current point in time.
 SPFILE: Allows us to reset values in the spfile when it is copied from the source server.
 NOFILENAMECHECK: Destination file locations are not checked.
*Note: if you use different file path don’t forget to set convert* option parameter.

13
Once the command is complete, we can start the apply process.
Start & Stop Apply Process

Start the apply process on standby server.
# Foreground redo apply. Session never returns until cancel.

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;
# Background redo apply. Control is returned to the session once the apply
process is started.
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
If you need to cancel the apply process, issue the following command.
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
If you prefer, you can set a delay between the arrival of the archived redo log and it being
applied on the standby server using the following commands.

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DELAY 30 DISCONNECT FROM
SESSION;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY DISCONNECT FROM
SESSION;
Provided you have configured standby redo logs, you can start real-time apply using the
following command.
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;

Or
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE
DISCONNECT FROM SESSION;
Configure Oracle Data Guard Broker

Broker is an optional in most of sites but it mandatory for automation within third party clusters
like Sun Cluster, Cloud Automation, .. etc.
For both instances enable broker option,
> alter system set dg_broker_start=TRUE scope=both;
Create an Oracle Data Guard Broker configuration for the primary database.
You use the “dgmgrl” command to create the Oracle Data Guard Broker configuration. You
need to know the name of the Oracle Data Guard Broker configuration that you want to create,
the name of the primary database, and the net service name through which to connect. You will

14
need to know these properties again, when you specify the configuration to Sun Cluster
Geographic Edition.
oracle (phys-paris-1)$ dgmgrl sys/sysdba_password@sales-svc

DGMGRL> create configuration mysales.com as primary
DGMGRL> database is sales connect identifier is sales-svc;
If you find errors when you connect to the Oracle Data Guard Broker, check the
${ORACLE_HOME}/admin/sales/bdump/alert_prim_sid.log file. You can check that the
configuration has been created by using the following command:

DGMGRL> show configuration;
Configuration
Name: mysales.com
Enabled: NO
Protection Mode: MaxPerformance
Fast-Start Failover: DISABLED
Databases:
sales - Primary database
Current status for "mysales.com":

DISABLED
Add the standby database to the Oracle Data Guard Broker configuration.
You need to know the name of the standby database, the net service name through which to
connect, and the type of standby (physical or logical).

DGMGRL> add database salesdr as connect identifier is
salesdr-svc maintained as physical;
Configure the apply instance for the standby database.

If the standby database is also a multi-instance Oracle RAC database, you can specify the
instance on which you would prefer the transmitted archive redo logs to be applied. Before you
enable the configuration, issue the following command:
oracle$ dgmgrl sys/sysdba_password@sales-svc

DGMGRL> edit database salesdr set property PreferredApplyInstance='salesdr1';
To verify that the Oracle Data Guard Broker configuration is working correctly,
1. enable the configuration.

DGMGRL> enable configuration;
2. If you have successfully performed all steps, you can check the status of the
configuration by using the following command:

15
oracle$ dgmgrl sys/sysdba_password@sales-svc
Configuration
Name: mysales.com
Enabled: YES
Databases:
sales - Primary database
salesdr - Physical standby database
Current status for "mysales.com":

SUCCESS
3. Verify that the Oracle Data Guard Broker configuration can switch over.
oracle (phys-paris-1)$ dgmgrl sys/sysdba_password@sales-svcDGMGRL> switchover

to salesdr
Performing switchover NOW, please wait...
Operation requires shutdown of instance "sales1" on database "sales"
Shutting down instance "sales1"...
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
Operation requires shutdown of instance "salesdr1" on database "salesdr"
Shutting down instance "salesdr1"...
Operation requires startup of instance "sales1" on database "sales"
Starting instance "sales1"...
ORACLE instance started.
Database mounted.
Operation requires startup of instance "salesdr1" on database "salesdr"
Starting instance "salesdr1"...
Database mounted.
Switchover succeeded, new primary is "salesdr"
DGMGRL switchover to sales;

Performing switchover NOW, please wait...
Operation requires shutdown of instance "salesdr1" on database "salesdr"
Shutting down instance "salesdr1"...
Operation requires shutdown of instance "sales1" on database "sales"
Shutting down instance "sales1"...

16
Operation requires startup of instance "salesdr1" on database "salesdr"
Starting instance "salesdr1"...
Database mounted.
Operation requires startup of instance "sales1" on database "sales"
Starting instance "sales1"...
Database mounted.
Switchover succeeded, new primary is "sales"
Monitoring Scripts and informational views

To Test Log Transport On the primary server, check the latest archived redo log and force a log
switch.
SELECT sequence#, first_time, next_time

FROM v$archived_log
ORDER BY sequence# desc;
ALTER SYSTEM SWITCH LOGFILE;
Check the new archived redo log has arrived at the standby server and been applied.
SELECT sequence#, first_time, next_time, applied

FROM v$archived_log
ORDER BY sequence# desc;
Issue the following query to show information about the protection mode, the protection level,
the role of the database, and switchover status:
SELECT DATABASE_ROLE, DB_UNIQUE_NAME INSTANCE, OPEN_MODE, PROTECTION_MODE,

PROTECTION_LEVEL, SWITCHOVER_STATUS FROM V$DATABASE;
On the standby database, query the V$ARCHIVED_LOG view to identify existing files in the
archived redo log.
SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#

desc;
Or
SELECT THREAD#, MAX(SEQUENCE#) AS "LAST_APPLIED_LOG" FROM V$LOG_HISTORY GROUP
BY THREAD#;
On the standby database, query the V$ARCHIVED_LOG view to verify the archived redo log files
were applied.
SELECT SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE# desc;

17
Query the physical standby database to monitor Redo Apply and redo transport services activity
at the standby site.
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM

V$MANAGED_STANDBY;
To determine if real-time apply is enabled, query the RECOVERY_MODE column of the

V$ARCHIVE_DEST_STATUS view.
SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS;
The V$DATAGUARD_STATUS fixed view displays events that would typically be triggered by any
message to the alert log or server process trace files.
SELECT MESSAGE FROM V$DATAGUARD_STATUS;
Determining Which Log Files Were Not Received by the Standby Site last day.
select THREAD#, SEQUENCE# from V$ARCHIVED_LOG where STANDBY_DEST='NO' and

NEXT_TIME > sysdate - 1
minus
select THREAD#, SEQUENCE# from V$ARCHIVED_LOG where STANDBY_DEST='YES' and
NEXT_TIME > sysdate – 1;
If a delayed apply has been specified or an archive log is missing then switchover may take
longer than expected.
Check v$managed_standby
select process, status, sequence# from v$managed_standby;
OR alternatively:
select name, DEST_ID, THREAD#, SEQUENCE#, applied from v$archived_log order by

SEQUENCE# desc,DEST_ID ;
Redo Transport Performance Consideration

Redo transport controlled by “LOG_ARCHIVE_DEST_n Parameter Attributes”
AFFIRM and NOAFFIRM

The AFFIRM and NOAFFIRM attributes control whether a redo transport destination
acknowledges received redo data before or after writing it to the standby redo log:
 AFFIRM—specifies that a redo transport destination acknowledges received redo data

after writing it to the standby redo log.
 NOAFFIRM—specifies that a redo transport destination acknowledges received redo
data before writing it to the standby redo log.

18
SYNC and ASYNC
The SYNC and ASYNC attributes specify whether the synchronous (SYNC) or asynchronous
(ASYNC) redo transport mode is to be used.
 The redo data generated by a transaction must have been received by every enabled
destination that has the SYNC attribute before that transaction can commit.
 On primary databases and logical standbys, destinations 1 through 10 default to ASYNC
(real-time cascading).
 On physical standbys, snapshot standbys, and far sync instances, destinations 1 through
10 default to ARCH transport mode. (Note that the ARCH attribute is deprecated; the use
of ARCH in this situation simply indicates non-real-time cascading.)
 Note* Destinations 11 through 31 always default to ASYNC. (Only)
COMPRESSION
The COMPRESSION attribute is used to specify whether redo data is compressed before
transmission to a redo transport destination.
Usage Notes
The COMPRESSION attribute is optional. If it is not specified, the default compression behavior is
DISABLE.
*Note: For Oracle Data Guard SYNC connection strings that also use the Oracle Data Guard
COMPRESSION attribute, the SQLNET.COMPRESSION configuration parameter should be
disabled (set to off) in the sqlnet.ora file.
LOG_ARCHIVE_DEST_3='SERVICE=denver SYNC COMPRESSION=ENABLE'
DELAY
The DELAY attribute specifies a minimum time lag between when redo data from the primary
site is archived on a standby site and when the archived redo log file is applied to the standby
database or any standbys cascaded from it.
Usage Notes
The DELAY attribute is optional. By default, there is no delay.
The DELAY attribute indicates the archived redo log files at the standby destination are not
available for recovery until the specified time interval has expired. The time interval is expressed
in minutes, and it starts when the redo data is successfully transmitted to, and archived at, the
standby site.
The DELAY attribute may be used to protect a standby database from corrupted or erroneous
primary data. However, there is a tradeoff because during failover it takes more time to apply all
the redo up to the point of corruption.
The DELAY attribute does not affect the transmittal of redo data to a standby destination.
If you have real-time apply enabled, then any delay that you set is ignored.

19
Changes to the DELAY attribute take effect the next time redo data is archived (after a log
switch). In-progress archiving is not affected.
You can override the specified delay interval at the standby site, as follows:
For a physical standby database:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;
For a logical standby database:
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY;
The DELAY value that a cascaded standby use is the value that was set for the
LOG_ARCHIVE_DEST_n parameter on the primary that shipped the redo to the cascading
standby.
Examples:
You can use the DELAY attribute to set up a configuration where multiple standby databases are
maintained in varying degrees of synchronization with the primary database. However, this
protection incurs some overhead during failover, because it takes Redo Apply more time to
apply all the redo up to the corruption point.
For example, assume primary database A has standby databases B and C. Standby database B is
set up as the disaster recovery database and therefore has no time lag. Standby database C is
set up with a 2-hour delay, which is enough time to allow user errors to be discovered before
they are propagated to the standby database.
The following example shows how to specify the DELAY attribute for this configuration:
LOG_ARCHIVE_DEST_1='LOCATION=/arch/dest MANDATORY'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_2='SERVICE=stbyB SYNC AFFIRM'
LOG_ARCHIVE_DEST_3='SERVICE=stbyC DELAY=120'
Apply Process Tuning Elements

Option#1: Set Parallel Recovery to Twice the Number of CPUs on One Standby
Host
RECOVER STANDBY DATABASE PARALLEL #CPUs * 2;
Note: You should compare several serial and parallel recovery runs to determine optimal
recovery performance

20
Option#2: Set PARALLEL_EXECUTION_MESSAGE_SIZE = 4096 or more
When using parallel media recovery or parallel standby recovery, increasing the
PARALLEL_EXECUTION_MESSAGE_SIZE database parameter to 4K (4096) can improve parallel
recovery by as much as 20 percent. Set this parameter on both the primary and standby
databases in preparation for switchover operations. Increasing this parameter requires more
memory from the shared pool by each parallel execution slave process.
The PARALLEL_EXECUTION_MESSAGE_SIZE parameter is also used by parallel query

operations and should be tested with any parallel query operations to ensure there is sufficient
memory on the system. Many parallel query slaves on a 32-bit installation may reach memory
limits and prohibit increasing the PARALLEL_EXECUTION_MESSAGE_SIZE from the default 2K
(2048) to 4K.
Option#3: Set DB_BLOCK_CHECKING=FALSE for Faster Redo Apply Rates

Setting the DB_BLOCK_CHECKING=FALSE parameter during standby or media recovery can
provide as much as a twofold increase in the apply rate. The lack of block checking during
recovery must be an accepted risk. Block checking should be enabled on the primary database.
The DB_BLOCK_CHECKSUM=TRUE (the default) should be enabled for both production and
standby databases. Because the DB_BLOCK_CHECKING parameter is dynamic, it can be toggled
without shutting down the standby database.
Option#4: Tune Disk I/O

The biggest bottlenecks encountered during recovery are read and write I/O. To relieve the
bottleneck, use native asynchronous I/O and set the database parameter DISK_ASYNCH_IO to
TRUE (the default). The DISK_ASYNCH_IO parameter controls whether disk I/O to datafiles is
asynchronous. Asynchronous I/O should significantly reduce database file parallel reads and
should improve overall recovery time.
Basic Administration Tasks
Read-Only Standby and Active Data Guard

Once a standby database is configured, it can be opened in read-only mode to allow query
access. This is often used to offload reporting to the standby server, thereby freeing up
resources on the primary server. When open in read-only mode, archive log shipping continues,
but managed recovery is stopped, so the standby database becomes increasingly out of date
until managed recovery is resumed.
To switch the standby database into read-only mode, do the following.
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE OPEN READ ONLY;
To resume managed recovery, do the following.

21
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
In 11g, Oracle introduced the Active Data Guard feature. This allows the standby database to be
open in read-only mode, but still apply redo information. This means a standby can be available
for querying, yet still be up to date. There are licensing implications for this feature, but the
following commands show how active data guard can be enabled.
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE OPEN READ ONLY;
Since managed recovery continues with active data guard, there is no need to switch back to
managed recovery from read-only mode in this case.
Changing 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 no suitable standby location is available, the primary database
shuts down.
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
The mode can be switched using the following commands. Note the alterations in the redo
transport attributes.
> SHUTDOWN IMMEDIATE;

> STARTUP MOUNT;
-- Maximum Availability.

22
> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=db11g_stby AFFIRM SYNC
> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;
-- Maximum Performance.
> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=db11g_stby NOAFFIRM ASYNC
> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;
-- Maximum Protection.
> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=db11g_stby AFFIRM SYNC
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;
> ALTER DATABASE OPEN;
Database Switchover
A database can be in one of two mutually exclusive modes (primary or standby). These roles can
be altered at runtime without loss of data or resetting of redo logs. This process is known as a
Switchover and can be performed using the following statements.
-- Convert primary database to standby

CONNECT / AS SYSDBA
ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY;
-- Shutdown primary database

SHUTDOWN IMMEDIATE;
-- Mount old primary database as standby database

STARTUP NOMOUNT;
ALTER DATABASE MOUNT STANDBY DATABASE;
On the original standby database issue, the following commands.
-- Convert standby database to primary

CONNECT / AS SYSDBA
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
-- Shutdown standby database

SHUTDOWN IMMEDIATE;
-- Open old standby database as primary

STARTUP;
Once this is complete, test the log transport as before. If everything is working fine, switch the
primary database back to the original server by doing another switchover. This is known as a
switchback.

23
Failover
If the primary database is not available, the standby database can be activated as a primary
database using the following statements.
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

ALTER DATABASE ACTIVATE STANDBY DATABASE;
Since the standby database is now the primary database it should be backed up immediately.
The original primary database can now be configured as a standby. then, the whole setup
process must be followed, but this time using the original primary server as the standby before
switch back.
Flashback Database
It was already mentioned in the previous section, but it is worth drawing your attention to
Flashback Database once more. Although a switchover/switchback is safe for both the primary
and standby database, a failover renders the original primary database useless for converting to
a standby database. If flashback database is not enabled, the original primary must be scrapped
and recreated as a standby database.
An alternative is to enable flashback database on the primary (and the standby if desired) so in
the event of a failover, the primary can be flashed back to the time before the failover and
quickly converted to a standby database. That process is shown here.
Complete example for flash back option.
1. Pre-configuration steps
check flashback status, if not enabled or "ON" then
select flashback_on from v$database;
enable flashback via following actions
2. Enable flashback
set proper values for following parameters
 db_recovery_file_dest
 db_recovery_file_dest_size
 db_flashback_retention_target
if we are on standby DB system
do following steps:
alter database recover managed standby database cancel;

alter database flashback on;

24
alter database recover managed standby database using current logfile
disconnect from session;
if we are on primary DB system (optional step)
alter database flashback on;

3. Open standby temporally for read/write
on standby

create restore point connection_test guarantee flashback database;
select name,scn,time from v$restore_point;
on primary *this step is optionally of we don't plan for long period
alter system archive log current;

alter system set log_archive_dest_state_2=defer;
on standby
select controlfile_type from v$database; --standby

alter database activate standby database;
select controlfile_type from v$database; -- current
alter database set standby database to maximize performance;
alter database open;
select open_mode from v$database; -- read write
for testing (start required change!)
create table test as select * from dual;

select * from test;
…
4. Revert to restore point
on standby
startup mount force;

flashback database to restore point connection_test;
make sure of controle file type
select controlfile_type from v$database; -- backup

25
alter database convert to physical standby;
startup mount force;
alter database recover managed standby database disconnect;
make sure of controle file type -- standby controlfile
select controlfile_type from v$database; -- standby
on primary
alter systen set log_archive_dest_state_2=enable;

alter system archive log current;
on standby

alter database open read only;
5. removing the restore point
This step delayed to the end for safety
startup force mount;

alter database recover managed standby database disconnect;
drop restore point connection_test;
alter database open read only;
alter database recover managed standby database using current logfile
disconnect from session;
select * from test; --ora-942 should raise up!
Snapshot Standby (11g+) (Manual Approach)

Introduced in 11g, snapshot standby allows the standby database to be opened in read-write
mode. When switched back into standby mode, all changes made whilst in read-write mode are
lost. This is achieved using flashback database, but the standby database does not need to have
flashback database explicitly enabled to take advantage of this feature, thought it works just the
same if it is.
If you are using RAC, turn off all but one of the RAC instances. Make sure the instance is in
MOUNT mode.
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
Make sure managed recovery is disabled.
Convert the standby to a snapshot standby. The following example queries the V$DATABASE
view to show that flashback database is not enabled prior to the conversion operation.

26
SELECT flashback_on FROM v$database;
FLASHBACK_ON
------------------
NO
ALTER DATABASE CONVERT TO SNAPSHOT STANDBY;

ALTER DATABASE OPEN;
FLASHBACK_ON
------------------
RESTORE POINT ONLY
You can now do treat the standby like any read-write database.
To convert it back to the physical standby, losing all the changes made since the conversion to
snapshot standby, issue the following commands.
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
SHUTDOWN IMMEDIATE;
STARTUP NOMOUNT;
ALTER DATABASE MOUNT STANDBY DATABASE;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
FLASHBACK_ON
------------------
NO
The standby is once again in managed recovery and archivelog shipping is resumed. Notice that
flashback database is still not enabled.
Snapshot Standby (11g+) (Using Broker)

Introduced in 11g, snapshot standby allows the standby database to be opened in read-write
mode. When switched back into standby mode, all changes made whilst in read-write mode are
lost. This is achieved using flashback database, but the standby database does not need to have
flashback database explicitly enabled to take advantage of this feature, thought it works just the
same if it is.
Connect to the primary (cdb1) database and convert the standby database (cdb1_stby) to a
snapshot standby.
$ dgmgrl sys/Password1@cdb1
DGMGRL for Linux: Version 12.1.0.2.0 - 64bit Production
Copyright (c) 2000, 2013, Oracle. All rights reserved.
Welcome to DGMGRL, type "help" for information.

27
Connected as SYSDBA.
DGMGRL> CONVERT DATABASE cdb1_stby TO SNAPSHOT STANDBY;
Converting database "cdb1_stby" to a Snapshot Standby database, please wait...
Database "cdb1_stby" converted successfully
DGMGRL>
When you are finished with the snapshot standby, convert it back to a standby database.
$ dgmgrl sys/Password1@cdb1
DGMGRL for Linux: Version 12.1.0.2.0 - 64bit Production
Copyright (c) 2000, 2013, Oracle. All rights reserved.
Welcome to DGMGRL, type "help" for information.

Connected as SYSDBA.
DGMGRL> CONVERT DATABASE cdb1_stby TO PHYSICAL STANDBY;
Converting database "cdb1_stby" to a Physical Standby database, please wait...
Operation requires shut down of instance "cdb1" on database "cdb1_stby"
Shutting down instance "cdb1"...
Database closed.
Operation requires start up of instance "cdb1" on database "cdb1_stby"
Starting instance "cdb1"...
Database mounted.
Continuing to convert database "cdb1_stby" ...
Database "cdb1_stby" converted successfully
DGMGRL>
The standby is once again in managed recovery and archivelog shipping is resumed. Notice that
flashback database is still not enabled.
Now, let’s check out the configuration.
DGMGRL> SHOW CONFIGURATION;
Configuration - my_dg_config

Members:
cdb1 - Primary database
cdb1_stby - Physical standby database
Configuration Status:
SUCCESS (status updated 38 seconds ago)
DGMGRL>

28
Skip Unresolvable Gap for missing or corrupted archive log for physical standby
The steps in this section can used to resolve problems of missing or corrupted archive log file, an
unresolvable archive gap, or need to roll standby forward in time without applying many
archivelog files.
Note:
If you use 'DataGuard Broker', then it should be stopped before starting with step 1 and re-
started again when all steps finished.
disable configuration;
1. Stop the managed recovery process (MRP) on the STANDBY database

Startup force mount;
Note: For the remaining steps, the standby database must be in a MOUNT state.
2. Determine the SCN of the STANDBY database.
You need to use the 'lowest SCN' from the queries below:
SQL> SELECT CURRENT_SCN FROM V$DATABASE;
CURRENT_SCN
--------------
169363633809
SQL> select min(checkpoint_change#) from v$datafile_header

where file# not in (select file# from v$datafile where enabled = 'READ ONLY');
MIN(F.FHSCN)
----------------
169363632617
in this example is SCN: 3162298. Therefore, From the above you need to backup from SCN
3162298
3. Take an incremental backup of the PRIMARY database
Use RMAN, connect to the primary database and create an incremental backup from the SCN
derived in the previous step:
RMAN> run
{
ALLOCATE CHANNEL ch1 DEVICE TYPE DISK FORMAT '/u02/backup/ForStandby_%U';
BACKUP INCREMENTAL FROM SCN 169363632617 DATABASE FORMAT
'/u02/backup/ForStandby_%U' tag 'FORSTANDBY';

29
}
4. Transfer all backup sets to STANDBY server
All backups created by step #3 must be transferred from the primary to the standby system. If
the backup is written to NFS device, this step can be skipped.
scp /u02/backup/ForStandby_* standby:/u02/backup/
5. Catalog the backups in STANDBY controlfile.
RMAN> CATALOG START WITH ‘/u02/backup/ForStandby_%U';
using target database control file instead of recovery catalog

searching for all files that match the pattern /u02/backup/ForStandby
List of Files Unknown to the Database

=====================================
File Name: /u02/backup/ForStandby_2lkglss4_1_1
File Name: /u02/backup/ForStandby_2mkglst8_1_1
Do you really want to catalog the above files (enter YES or NO)? YES
cataloging files...
cataloging done
List of Cataloged Files

=======================
File Name: /u02/backup/ForStandby_2lkglss4_1_1
File Name: /u02/backup/ForStandby_2mkglst8_1_1
6. Recover the STANDBY database with the cataloged incremental backup:
RMAN> RECOVER DATABASE NOREDO;
starting recover at 03-JUN-09

allocated channel: ORA_DISK_1
complete, elapsed time: 00:00:02
Finished recover at 03-JUN-09
7. In RMAN, connect to the PRIMARY database and create a standby control file backup:
RMAN> run
{
ALLOCATE CHANNEL ch1 DEVICE TYPE DISK FORMAT '/u02/backup/ForStandby_%U';
BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT
'/u02/backup/ForStandbyCTRL.bck';
}
8. Copy the standby control file backup to the STANDBY system.
scp /u02/backup/ForStandbyCTRL.bck standby: /u02/backup/
9. Capture datafile information in STANDBY database.

30
Just if you know, there is a change in file level architecture, or when you use file management
auto, we will need to refresh the standby controlfile from primary controlfile (for standby)
backup. However, since the datafile names are likely different than primary, let's save the name
of datafiles on standby first, which we can refer after restoring controlfile from primary backup
to verify if there is any discrepancy. Run below query from Standby and save results for further
use, and for differences user rename data file command to match the architecture on standby
server, and don’t skip step 11.
spool datafile_names_step8.txt
set lines 200
col name format a60
select file#, name from v$datafile order by file#;
spool off
10. From RMAN, connect to STANDBY database and restore the standby control file:
RMAN> SHUTDOWN IMMEDIATE ;

EXIT and re LOGIN
RMAN> STARTUP NOMOUNT;
RMAN> RESTORE STANDBY CONTROLFILE FROM '/u02/backup/ForStandbyCTRL.bck';
Starting restore at 03-JUN-09

using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=36 devtype=DISK
channel ORA_DISK_1: restoring control file

channel ORA_DISK_1: restore complete, elapsed time: 00:00:07
output filename=+DATA/mystd/controlfile/current.257.688583989
Finished restore at 03-JUN-09
11. Shut down the STANDBY database and startup mount:
RMAN> SHUTDOWN;
RMAN> STARTUP MOUNT;
If step 9 show no issues with datafile paths or architecting skip to step 15

12. Catalog datafiles in STANDBY if location/name of datafiles is different
Since the controlfile is restored from PRIMARY the datafile locations in STANDBY controlfile will
be same as PRIMARY database, if the directory structure is different between the standby and
primary or you are using Oracle managed file names, catalog the datafiles in STANDBY will do
the necessary rename operations. If the primary and standby have identical structure and
datafile names, this step can be skipped.
Perform the below step in STANDBY for each diskgroup where the datafile directory structure
between primary and standby are different.
RMAN> CATALOG START WITH '+DATA/mystd/datafile/';

31
List of Files Unknown to the Database
=====================================
File Name: +data/mystd/DATAFILE/SYSTEM.309.685535773
File Name: +data/mystd/DATAFILE/SYSAUX.301.685535773
File Name: +data/mystd/DATAFILE/UNDOTBS1.302.685535775
Do you really want to catalog the above files (enter YES or NO)? YES
cataloging files...
cataloging done
List of Cataloged Files

=======================
If any datafiles have been added to Primary AFTER scn 3162298 they will also have to be
restored to the standby host (see Note 1531031.1 Steps to perform for Rolling forward a
standby database using RMAN incremental backup when datafile is added to primary) and
cataloged as shown above before doing the switch.
To determine if any files have been added to Primary since the standby current SCN:
SQL>SELECT FILE#, NAME FROM V$DATAFILE WHERE CREATION_CHANGE# > 3162298
If the above query returns with 0 zero rows, you can switch the datafiles. This will rename the
datafiles to its correct name at the standby site:
RMAN> SWITCH DATABASE TO COPY;
datafile 1 switched to datafile copy

"+DATA/mystd/datafile/system.297.688213333"
"+DATA/mystd/datafile/undotbs1.268.688213335"
"+DATA/mystd/datafile/sysaux.267.688213333"
Note:
a) At this point, you can compare the query output from step 9 for any discrepancy (other
than newly added datafiles) to ensure we have all the datafiles added in standby.
b) run the queries from step 2 again to confirm that the incremental apply has moved the
datafiles forward. The SCN should now be bigger than its initial values.
13. Configure the STANDBY database to use flashback (optional)
If the STANDBY database needs to be configured for FLASHBACK run the following commands:

32
SQL> ALTER DATABASE FLASHBACK OFF;
SQL> ALTER DATABASE FLASHBACK ON;
NOTE: This command may return the following:

ORA-38788 More standby database recovery is needed
Depending on situation, this is expected. Proceed with the remaining steps.
14. On STANDBY database, clear all standby redo log groups:
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 1;

....
15. On the STANDBY database, start the MRP
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
16. Now check and Configure Broker
Test configuration
enable configuration;
if you got the below error
ORA-16541: database is not enabled
Configuration details cannot be determined by DGMGRL
You need to recreate the broker configuration
On Primary
> DGMGRL
DGMGRL> remove configuration;
DGMGRL> CREATE CONFIGURATION TB02ADM_DG AS PRIMARY DATABASE IS TB02ADM CONNECT
IDENTIFIER IS TB02ADM;
DGMGRL> add database TB02ADM_SAH as connect identifier is TB02ADM_SAH;

33

Oracle Data Guard Operation Reference V1.0

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oracle Data Guard Operation Reference V1.0

Uploaded by

Copyright:

Available Formats

AHMED MOAWAD

Operation Reference for

Written by Ahmed S. Moawad

Ahmed S. Moawad <samy_ahmed@hotmail.com>

Ahmed S. Moawad <samy_ahmed@hotmail.com>

Ahmed S. Moawad <samy_ahmed@hotmail.com>

The content of this document applied to:

Oracle Database - Enterprise Edition - Version 10.2.x.x to 12.2.x.x

And Aimed to cover following subjects:

Primary Server Setup

> SELECT log_mode FROM v$database;

If it is noarchivelog mode, switch is to archivelog mode.

> SHUTDOWN IMMEDIATE;

Ahmed S. Moawad <samy_ahmed@hotmail.com>

Enabled forced logging by issuing the following command.

ALTER DATABASE FORCE LOGGING;

> show parameter db_name

NAME TYPE VALUE

> show parameter db_unique_name

NAME TYPE VALUE

> ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(DB11G,DB11G_STBY)';

> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=db11g_stby NOAFFIRM ASYNC

The LOG_ARCHIVE_FORMAT and LOG_ARCHIVE_MAX_PROCESSES parameters must be set to

ALTER SYSTEM SET LOG_ARCHIVE_FORMAT='%t_%s_%r.arc' SCOPE=SPFILE;

Ahmed S. Moawad <samy_ahmed@hotmail.com>

 Static Service Registration

1. Static Service Registration

Ahmed S. Moawad <samy_ahmed@hotmail.com>

Make sure the listener is started on the standby server.

Backup Primary Database

RMAN> BACKUP DATABASE PLUS ARCHIVELOG;

Create Standby Controlfile and PFILE

ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/db11g_stby.ctl';

Create a parameter file for the standby database.

Ahmed S. Moawad <samy_ahmed@hotmail.com>

Standby Server Setup (Manual)

Create the necessary directories on the standby server.

Copy the files from the primary to the standby server.

$ # Standby controlfile to all locations.

$ # Archivelogs and backups

$ # Remote login password file.

Ahmed S. Moawad <samy_ahmed@hotmail.com>

> oradim -new -sid DATAGUARD -startmode m

Status should show static service registration

$ export ORACLE_SID=DB11G (use “set” in case of windows)

SQL> CREATE SPFILE FROM PFILE='/tmp/initDB11G_stby.ora';

Restore the backup files.

$ export ORACLE_SID=DB11G (use “set” in case of windows)

RMAN> STARTUP MOUNT;

Create Redo Logs

ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL;

Ahmed S. Moawad <samy_ahmed@hotmail.com>

ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 10

Once this is complete, we can start the apply process.

Standby Server Setup (DUPLICATE)

Copy the files from the primary to the standby server.

$ # Standby controlfile to all locations.

$ # Remote login password file.

Ahmed S. Moawad <samy_ahmed@hotmail.com>

Make sure the listener is started on the standby server.

Status should show static service registration

Create Standby Redo Logs on Primary Server

ALTER DATABASE ADD STANDBY LOGFILE

Create Standby Using (DUPLICATE)