Vous êtes sur la page 1sur 23

DATA GUARD OPERATIONS USING SQL*Plus INTERFACE

ROLE TRANSITIONS
In Data Guard configuration, an Oracle database can operate in one of two modes: Primary or Standby.
We can change the role of database using either a switchover or a failover operation. Oracle Data
Guard supports 2 types of role transitions. They are SWITCHOVER & FAILOVER.
SWITCHOVER: Allows reversible role transition between the primary database and its one of
standby databases. (The Primary database becomes Standby, the Standby database becomes Primary).
After switchover happened, each database continues to participate in Data Guard configuration
with its new role. No data loss during a switchover operation.
FAILOVER: Changes a Standby database to the primary role in response to a primary database
failure. During a failover operation one of the standby databases would become primary database
and the old primary database unable to participate in the Data Guard Configuration. If the
Primary database was not operating MAXIMUM PROTECTION or MAXIMUM AVAILABILITY mode before
failure, data loss may occur.
The Old Primary can be entered back into the configuration as a Standby database. If Flashback
database is enabled on the primary database, it can be reinstated as a standby for the new primary
database. Without flashback, Data Guard configuration needs to be built from scratch.
User Interfaces for administering Data Guard
SQL*Plus, DGMGRL, and Enterprise Manager
SQL*Plus provides all kinds of administration & monitoring for the DBAs. In Data Guard configuration
operations such as (switchover or failover), as a DBA you have to access each server and need to
execute SQL statements separately unlike DGMGRL.
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. DGMGRL configuration and operations explained here.
In this section, step by step we can discuss Data Guard operations using SQL*Plus interface.
SWITCHOVER OPERATION

# ON PRIMARY SITE WHICH WOULD BECOME TO THE NEW STANDBY


SYS> select switchover_status from v$database;
SYS> alter database commit to switchover to physical standby with session shutdown;
SYS> shutdown immediate;
SYS> startup nomount;
SYS> alter database mount standby database;
SYS> alter system set log_archive_dest_state_2=DEFER scope=both;
# ON STANDBY SITE - WHICH WOULD BECOME TO THE NEW PRIMARY
SYS> select switchover_status from v$database;
SYS> alter database commit to switchover to primary;
SYS> shut immediate;
SYS> startup;
SYS> recover managed standby database disconnect;

# ON THE OLD PRIMARY SITE

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

DATA GUARD OPERATIONS USING SQL*Plus INTERFACE

SWITCHOVER PROCESS STEP 1:

SYS> select name, db_unique_name, database_role from v$database;


NAME

DB_UNIQUE_NAME

--------- --------------CRMS

crms

DATABASE_ROLE
---------------PRIMARY

SYS> alter system switch logfile;


System altered.
SYS> select switchover_status from v$database;
SWITCHOVER_STATUS
-------------------TO STANDBY
SQL statement result only must be 'TO_STANDBY'.
SWITCHOVER_STATUS indicates whether switchover is allowed or not. Possible values are given below.
To get light, you can check SWITCHOVER_STATUS column of V$DATABASE view.
NOT ALLOWD

SESSIONS ACTIVE

SWITCHOVER PENDING SWITCHVER LATENT

TO PRIMARY

TO STANDBY

RECOVERY NEEDED

LOG SWITCH GAP

PROCESS STEP 2:
Verify that there are no redo transport errors or redo gaps at the standby database by querying
the view v$archive_dest_status view on the Primary database. Do not p

SYS> SELECT STATUS, GAP_STATUS FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;


STATUS

GAP_STATUS

--------- -----------------------VALID

NO GAP

The above query used to check the status of the standby database associated with LOG_ARCHIVE_DEST_2.
Do not start switchover process until the value of the STATUS is VALID and the value of the
GAP_STATUS is NOGAP. On the Primary database you can verify following parameter, those values are
corresponding to the standby database.

SYS> show parameter log_archive_dest_2;


...
SYS> show parameter log_archive_dest_state_2;
...
PROCESS STEP 3:
In order to perform switchover operation all sessions to the database need to be disconnected.
You have to use 'WITH SESSION SHUTDOWN' clause that should be added to alter database statement.

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

DATA GUARD OPERATIONS USING SQL*Plus INTERFACE

# CONVERT THE PRIMARY DATABASE TO THE NEW STANDBY


SYS> alter database commit to switchover to physical standby with session shutdown;
Database altered.

PROCESS STEP 4:

# SHUTDOWN THE FORMER PRIMARY AND MOUNT AS A STANDBY DATABASE.


SYS> shutdown immediate;
...
SYS> startup nomount;
...
SYS> alter database mount standby database;
...
# DEFER THE REMOTE ARCHIVE DESTINATION ON THE OLD PRIMARY
SYS> alter system set log_archive_dest_state_2=defer scope=both;
...
WHY SE SET DEFER ?
On the primary site, when you set log_archive_state_2=defer, then archives/redo shipping process
will be stopped to the standby site. This is part of switchover process.
PROCESS STEP 6
Switch Standby database to Primary. Check switchover status.
# VERIFY THAT THE PHYSICAL STANDBY CONVERTED TO THE NEW PRIMARY
SYS> select switchover_status from v$database;
SWITCHOVER_STATUS
-------------------TO PRIMARY
# CONVERT THE PHYSICAL STANDBY TO THE NEW PRIMARY
SYS> alter database commit to switchover to primary;
...
If the status returns SESSION ACTIVE, then you should append the with session shutdown clause.
# SHUTDOWN AND STARTUP THE NEW PRIMARY
SYS> shutdown immediate;
...
SYS> startup;
...

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

DATA GUARD OPERATIONS USING SQL*Plus INTERFACE

PROCESS STEP 7 (ON THE NEW PRIMARY)


By default LOG_ARCHIVE_DEST_STATE_2 value is ENABLE only.
If destination value is DEFER, Enable remote archiving on the new primary to the new standby.

# ENABLE REMOTE ARCHIVING


SYS> alter system set log_archive_dest_state_2='ENABLE';
...
PROCESS STEP 8 (ON THE NEW STANDBY SITE)

SYS> select name, db_unique_name, open_mode from v$database;


NAME

DB_UNIQUE_NAME

OPEN_MODE

DATABASE_ROLE

--------- ------------------ ----------- -------------------CRMS

crms

MOUNTED

PHYSICAL STANDBY

# START MANAGED REOVER ON THE NEW STANDBY


SYS> alter database recover managed standby database disconnect;

or

...
# START REAL-TIME-RECOVERY PROCESS (REAL-TIME-APPLY)
SYS> alter database recover managed standby database using current logfile disconnect;
...

# ON THE OLD PRIMARY SITE - [THE NEW STANDBY]


SYS> select DEST_ID, DEST_NAME, STATUS, TYPE, SRL, RECOVERY_MODE from
V$archive_dest_status where dest_id=1;
DEST_ID

DEST_NAME

STATUS

TYPE

SRL

---------- ------------------------ --------- --------- --1

LOG_ARCHIVE_DEST_1

VALID

LOCAL

NO

RECOVERY_MODE
------------------------MANAGED REAL TIME APPLY

NOTE: In my case, real time apply enabled so that RECOVERY_MODE is MANAGED REAL TIME APPLY.

# ON THE NEW PRIMARY [THE OLD STANDBY]


SYS> select name, db_unique_name, open_mode, database_role from v$database;
NAME

DB_UNIQUE_NAME

OPEN_MODE

DATABASE_ROLE

--------- ------------------------------ -------------------- ---------------CRMS

stbycrms

READ WRITE

PRIMARY

# MAKE LOG SWITCH ON THE NEW PRIMARY DATABSE


SYS> alter system switch logfile;
System altered.

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

DATA GUARD OPERATIONS USING SQL*Plus INTERFACE

# ON THE NEW PRIMARY


SYS> select sequence#, first_time, next_time, applied from v$archived_log order by sequence#;
...
SYS> select thread#, max(sequence#) from v$archived_log group by thread#;
...
# ON THE NEW STANDBY
SYS> select thread#, max(sequence#) from v$archived_log where applied='YES' group by thread#;
...

Our switchover process is successfully completed. There is no data divergence between the original
and new primary databases after successful completion of the switchover.
PERFORM FAILOVER TEST

As we know very well Failover is basically unplanned Role Transition. Failover operations can be
done by using SQL*Plus, Data Guard broker, or automatically using the Fast Start failover with an
observer. Once the failover is complete, the new primary would be started in MAXIMUM PERFORMANCE
mode even if it were previously running in MAXIMUM AVAILABILITY or MAXIMUM PROTECTION mode.
If the flashback database is NOT enabled on the primary database, after a failover operation it is
impossible to include the old (failed) primary database into the data guard configuration again.
Suppose Flashback enabled on the Primary database before the failover operation, you can bring
the old Primary back into the configuration as a Standby database. Its 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. Its always good idea and recommended to enable flashback in Standby database also.
ENVIRONMENT DETAILS
Database Name

: crms

Primary db_unique_name : crms


Standby db_unique_name : stbycrms
Primary Site

: SERVER1 192.168.1.130

Standby Site

: SERVER2 192.168.1.131

Standby Database type

: Physical Standby

Data Protection Mode

: MAXIMUM PERFORMANCE

Lets see how to perform a failover to a Physical Standby database using SQL*Plus.
PROCESS STEP 1:
# PRIMARY DATABASE SERVER
SYS> select name, db_unique_name, database_role, protection_mode from v$database;
NAME

DB_UNIQUE_NAME

DATABASE_ROLE

PROTECTION_MODE

--------- ------------------------------ ---------------- -------------------CRMS


crms
PRIMARY
MAXIMUM PERFORMANCE

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

DATA GUARD OPERATIONS USING SQL*Plus INTERFACE

SYS> select switchover_status, flashback_on from v$database;


SWITCHOVER_STATUS

FLASHBACK_ON

-------------------- -----------------TO STANDBY


YES
SYS> shut immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
$ ps ef | grep ora_
Assume that the Primary database cannot be started again so that the standby has to be activated.
# STANDBY DATABASE SERVER
SYS> select name, db_unique_name, database_role, open_mode, protection_mode from v$database;
NAME
DB_UNIQUE_NAME
DATABASE_ROLE
OPEN_MODE
PROTECTION_MODE
--------- ---------------- ----------------- ------------ -----------------CRMS

stbycrms

PHYSICAL STANDBY

MOUNTED

MAXIMUM PERFORMACE

SYS> select flashback_on from v$database;


FLASHBACK_ON
-----------------YES
STEP 2: CANCEL THE MANAGED RECOVERY PROCESS

SYS> alter database recover managed standby database cancel;


Database altered.
$ tail f crms_alert.log
..
...
Recovered data files to a consistent state at change 70591961
ORA-16037: user requested cancel of managed recovery operation
MRP0: Background Media Recovery process shutdown (stbycrms)
Waiting for MRP0 pid 11448 to terminate
Managed Standby Recovery Canceled (stbycrms)
Completed: alter database recover managed standby database cancel
The CANCEL clause cancels Redo apply on a Physical Standby database after applying the current
archived redo log file.

STEP 3: INITIATE A FAILOVER ON THE PHYSICAL STANDBY RECOVERY PROCESS

SYS> alter database recover managed standby database finish force;


Database altered.

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

DATA GUARD OPERATIONS USING SQL*Plus INTERFACE

$ tail f crms_alert.log
Identified End-Of-Redo for thread 1 sequence 510
Incomplete Recovery applied until change 70591962 time 11/28/2015 01:42:22
Media Recovery Complete (stbycrms)
Terminal Recovery: successful completion
ORA-16014: log 4 sequence# 510 not archived, no available destinations
Completed: alter database recover managed standby database finish force
The FINISH clause initiates failover on the Physical Standby database and recovers the current
standby redo log files. The FORCE keyword terminates active RFS processes on the Physical Standby,
so that failover can proceed immediately without waiting for network connections to time out.

STEP 3: CONVERT THE PHYSICAL STANDBY TO THE PRIMARY ROLE


SYS> alter database commit to switchover to primary with session shutdown;
Database altered.
$ tail f crms_alert.log
alter database commit to switchover to primary with session shutdown
ALTER DATABASE SWITCHOVER TO PRIMARY (stbycrms)
Maximum wait for role transition is 15 minutes.
Backup controlfile written to trace file
/u01/app/oracle/diag/rdbms/stbycrms/stbycrms/trace/stbycrms_ora_11383.trc
Standby terminal recovery start SCN: 70591961
RESETLOGS after incomplete recovery UNTIL CHANGE 70591962
Online log /u01/app/oracle/oradata/REDOLOG/stbycrms/redo1a.log:
Thread 1 Group 1 was previously cleared
Online log /u03/app/oracle/oradata/REDOLOG/stbycrms/redo1b.log: Thread 1 Group 1...
Online log /u01/app/oracle/oradata/REDOLOG/stbycrms/redo2a.log: Thread 1 Group 2...
Online log /u03/app/oracle/oradata/REDOLOG/stbycrms/redo2b.log: Thread 1 Group 2...
Online log /u01/app/oracle/oradata/REDOLOG/stbycrms/redo3a.log: Thread 1 Group 3...
Online log /u03/app/oracle/oradata/REDOLOG/stbycrms/redo3b.log: Thread 1 Group 3...
Standby became primary SCN: 70591960
Setting recovery target incarnation to 10
Switchover: Complete - Database mounted as primary
Completed: alter database commit to switchover to primary with session shutdown
COMMIT TO SWITCHOVER TO PRIMARY clause changes the Standby database to the Primary database role.
If SWITCHOVER_STATUS column shows SESSIONS ACTIVE, terminate the active user using WITH SESSION
SHUTDOWN clause to the alter database commit statement.

SYS> select status, db_unique_name from v$instance, v$database;


STATUS

DB_UNIQUE_NAME

DATABASE_ROLE

------------ ---------------- -------------MOUNTED

stbycrms

PRIMARY

As a result, you can no longer use this database as a standby database and any subsequent redo
received from the original primary database cannot be applied.

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

DATA GUARD OPERATIONS USING SQL*Plus INTERFACE

SYS> archive log list;


Database log mode

Archive Mode

Automatic archival

Enabled

Archive destination

USE_DB_RECOVERY_FILE_DEST

Oldest online log sequence

Next log sequence to archive

Current log sequence

FLASHBACK DATABASE WAS NOT ENABLED ON OLD PRIMARY


If you do not enable flashback database on the primary database before failover process, the new
Primary still at MOUNT state. Shut down and start up the new primary database. Now failover
operation is over. You need to rebuild the old primary from the scratch.
SYS> shutdown immediate;
...
SYS> startup;
...
IF FLASHBACK WAS ENABLED ON THE FORMER PRIMARY

SYS> alter database open;


Database altered.
SYS> select open_mode from v$database;
OPEN_MODE
-------------------READ WRITE
If the Physical Standby database has been opened in read-only mode since the last time it was
started, you must shut down the target standby database and restart it:

STEP 4: DETERMINE THE SCN ON THE NEW PRIMARY


We need to determine the failover SCN from the new primary.
We can identify the SCN from alert log also, please check step 3.

SYS> select STANDBY_BECAME_PRIMARY_SCN from v$database;


STANDBY_BECAME_PRIMARY_SCN
-------------------------70591960
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 its easy to determine at which the old standby database became the new primary database.
Flashback was enabled on the failed primary and also we found the SCN (which would really help us
to get back the former Primary database to support as standby database for stbycrms instance.

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

DATA GUARD OPERATIONS USING SQL*Plus INTERFACE

STEP 5 : FLASHBACK THE FAILED PRIMARY DATABASE

SYS> startup mount;


ORACLE instance started.
..
...
Database mounted.
SYS> select flashback_on from v$database;
FLASHBACK_ON
-----------------YES
SYS> flashback database to scn 70591960;
Flashback complete.
$ tail f crms_alert.log
flashback database to scn 70591960
Flashback Restore Start
..
...
Incomplete Recovery applied until change 70591961 time 11/28/2015 01:42:22
Flashback Media Recovery Complete
Completed: flashback database to scn 70591960
STEP 6: CONVERT THE DATABASE TO A PHYSICAL STANDBY

SYS> alter database convert to physical standby;


Database altered.
$ tail f crms_alert.log
..
...
Use the following SQL commands on the standby database to create
standby redo logfiles that match the primary database:
ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800;
Completed: alter database convert to physical standby
ALTER DATABASE CONVERT SQL STATEMENT dismounts the database after successfully converting the
control file to a standby control file.
SYS> select status from v$instance;
STATUS
-----------STARTED

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

DATA GUARD OPERATIONS USING SQL*Plus INTERFACE

SYS> shutdown immediate;


ORA-01507: database not mounted
ORACLE instance shut down.
SYS> startup mount;
ORACLE instance started.
..
...
Database mounted.
STEP 7: START REDO APPLY

# STARTING REAL TIME APPLY


SYS> alter database recover managed standby database using current logfile disconnect;
Database altered.
$ tail f crms_alert.log
MRP0 started with pid=34, OS id=28004
MRP0: Background Managed Standby Recovery process started (crms)
Serial Media Recovery started
Managed Standby Recovery starting Real Time Apply
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived...
..
...
Media Recovery Waiting for thread 1 sequence 510
Media Recovery Log
/u01/app/oracle/flash_recovery_area/CRMS/archivelog/2015_11_28/o1_mf_1_510_c5kjp8rn_.arc
Identified End-Of-Redo for thread 1 sequence 510
Incomplete Recovery applied until change 70591962
MRP0: Media Recovery Complete: End-Of-REDO (crms)
Media Recovery archivelogs detected beyond End-Of-REDO
Block change tracking service stopping.
MRP0: Background Media Recovery process shutdown (crms)
The new Physical Standby database reads EOR marker, the MRP stops. What it clearly states there is
more redo beyond the current archived redo log containing the EOR marker. At this point its a
good idea to check if MRP is working on the current standby.

SYS> alter database recover managed standby database cancel;


alter database recover managed standby database cancel
*
ERROR at line 1:
ORA-16136: Managed Standby Recovery not active
$ ps ef| grep mrp
oracle

28001 25261

0 05:22 pts/6

00:00:00 grep mrp

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

DATA GUARD OPERATIONS USING SQL*Plus INTERFACE

SYS> select process, status,sequence# from v$managed_standby;


PROCESS

STATUS

SEQUENCE#

--------- ------------ ---------ARCH

CONNECTED

ARCH

CONNECTED

ARCH

CONNECTED

ARCH

CONNECTED

RFS

IDLE

5 rows selected.

# RESTART REDO APPLY ONCE AGAIN.


SYS> alter database recover managed standby database using current logfile disconnect;
Database altered.
$ tail f crms_alert.log
alter database recover managed standby database using current logfile disconnect
Attempt to start background Managed Standby Recovery process (crms)
MRP0 started with pid=42, OS id=28045
MRP0: Background Managed Standby Recovery process started (crms)
Serial Media Recovery started
Managed Standby Recovery starting Real Time Apply
..

SYS> archive log list;


Database log mode

Archive Mode

Automatic archival

Enabled

Archive destination

USE_DB_RECOVERY_FILE_DEST

Oldest online log sequence

Next log sequence to archive

10

Current log sequence

10

SYS> select process, status, sequence# from v$managed_standby;


PROCESS

STATUS

SEQUENCE#

--------- ------------ ---------ARCH

CONNECTED

ARCH

CONNECTED

ARCH

CONNECTED

ARCH

CLOSING

RFS

IDLE

RFS

IDLE

RFS

IDLE

RFS

IDLE

MRP0

APPLYING_LOG

10

When you use flashback database the failover operation will reset the log sequence number back to
#1. Make some log switches on the new primary (stbycrms) to the new standby (crms) site.

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

DATA GUARD OPERATIONS USING SQL*Plus INTERFACE

If you want to switch over operation, (to convert the Standby as Primary) issue the following query
to check current state of the archive destination on the new standby site.

SYS> select dest_id, dest_name, status, protection_mode, destination, error, srl


from

v$archive_dest_status where dest_id=2;

...
SYS> show parameter log_archive_dest_state_2;
...
If output is defer, set to enable execute following query
SYS> alter system set log_archive_dest_state_2=ENABLE scope=both;
...
REFERRED LINKS

FLASHING BACK A FAILED PRIMARY DATABASE INTO A PHYSICAL STANDBY.


SQL STATEMENT RELEVANT TO DATA GUARD.

CIRCUMSTANCES FOR ROLE TRANSITIONS

# Situations to perform switchover operation.


Planned Role transition
Hardware maintenance or Operating System patching
# Situations to perform failover operation.
Unplanned Role Transition.
Primary Database unfortunately goes down.

DATA GUARD PROTECTION MODES

Data Guard provides three types of data protection modes. They are MAXIMUM PROTECTION, MAXIMUM
AVAILABILITY & MAXIMUM PERFORMANCE. Understanding Data Guard Protection modes will help you which
serve different business needs in terms of data protection & performance. Data protection mode
controls what happens if the Primary database loses its connection to the standby database.
MAXIMUM PROTECTION MODE

Highest level of Data Protection.


Ensures ZERO DATA LOSS, even if the Primary database fails.
Redo records are synchronously transported to the Standby database.
At-least one Standby database must have Standby redo log files.
On the Primary database do not complete a commit operation until the redo data needed to recover
the transaction must be written to both (the primary online redo log & the Standby redo log).
If the redo data cannot be written to at least one standby, the primary will shut down. Because
this protection mode always priorities data protection over Primary database availability.

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

DATA GUARD OPERATIONS USING SQL*Plus INTERFACE

Oracle recommends to configure more than one Standby, to prevent a single standby database
failure from causing primary database to shut down.
Attributes to use parameter LOG_ARCHIVR_DEST_n: LGWR SYNC, and AFFIRM.
EX: log_archive_sest_2='STBY_CRMSDB LGWR SYNC AFFRIM'

MAXIMUM AVAILABILITY

Ensures ZERO DATA LOSS but NOT guaranteed.


Protection mode is similar to Maximum Protection mode.
Standby Redo log files are required at one standby database.
Redo records are synchronously transported to the Standby database.
This mode is combination of MAXIMUM PROTECTION and MAXIMUM PERFORMANCE.
Where a transactions on the primary do not commit until the redo data needed to recover that
transaction must be written to both (the Primary online redo log & at least 1 standby redo log)
If redo stream cannot be written to at least one standby, the primary database does NOT shut
down instead the primary database operates in Maximum Performance mode.
Once the fault is corrected and all gaps are resolved, the Primary database automatically
resumes operation in Maximum Availability mode.
Even this mode ensures no data loss (suppose the primary database fails). The Standby database
must have to resynchronize before the failover otherwise data loss will occur.
Attributes to use parameter LOG_ARCHIVR_DEST_n: LGWR SYNC, and AFFIRM
EX: log_archive_dest_2='STBY_CRMSDB LGWR SYNC AFFRIM'

You need High Bandwith and Low Latency between primary and standby databases.
The network bandwidth & latency are very important for MAX PROTECTION & MAX AVAILABILITY modes.

MAXIMUM PERFORMANCE

This is default Protection mode.


This mode offers slightly less data protection than MAX AVAILABILITY.
Log Transport services can be set to use either LGWR ASYNC or ARCH.
When a transaction is committed as soon as the redo data needed to recover is written to the
local online redo log. Then Redo data is written to the one or more standby databases, but this
is done asynchronously with respect to transaction commitment.
The Primary database continues its transaction processing without checking data availability
of any standby databases. So the performance and availability of the Primary wont affect.
Attributes to use parameter LOG_ARCHIVR_DEST_n: LGWR SYNC, and AFFIRM
EX: log_archive_dest_2='STBY_CRMSDB ARCH NOAFFRIM'
EX: log_archive_dest_2='STBY_CRMSDB LGWR ASYNC NOAFFRIM'

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

DATA GUARD OPERATIONS USING SQL*Plus INTERFACE

CONSIDERATION FOR DATA PROTECTION

REDO TRANSPORT

MAXIMUM PROTECTION

MAXIMUM AVAILABILITY

MAXIMUM PERFORMANCE

REDO ARCHIVAL PROCESS

LGWR

LGWR

LGWR or ARCH

NETWORK TRANSMISSION

SYNC

SYNC

ASYNC

DISK WRITE OPTION

AFFIRM

AFFIRM

AFFIRM or NO AFFIRM

STANDBY REDO LOG REQUIRED ?

YES

YES

NO. BUT IT IS RECOMMENDED

First we need to understand Redo Transport services. It performs the automated transfer of redo
data between the Primary database and Standby databases.
REDO TRANSPORT SERVICES AND MODES

As we know Redo Transport services can transmit redo data to local and remote destination. Remote
destination can include Physical Standby and Logical Standby databases. Data Guard supports 2 types
of redo transport methods using the LNS process: SYNCHRONOUS & ASYNCHRONOUS.
SYNC Vs ASYNC

Specifies whether the synchronous (SYNC) or asynchronous (ASYNC) redo transport mode is to be used.
Synchronous transport mode (SYNC) is required for MAXIMUM AVAILABILITY & MAXIMUM PROTECTION modes.
Asynchronous transfer mode (ASYNC) is required for the MAXIMUM PERFORMANCE mode.

# LGWR SYNC SYNC


You can verify TRANSMIT_MODE column of the v$ARCHIVE_DEST view.
SRL - Standby redo log files are required in SYNC transport mode.
Generally Synchronous redo transport affects the performance of the Primary database.
In order to complete the commit process, acknowledgement needed from the Standby database, any
delay in writing the redo data in Standby will impact performance of the Primary database.
Any failure in writing redo data to the standby database causing shutdown of the Primary
database in MAXIMUM PROTECTION mode.
The LOG_ARCHIVE_DEST_11 through LOG_ARCHIVE_DEST_31 parameter do not Support the SYNC attribute.
EX: log_archive_dest_2='service=STBY_CRMSDB LGWR SYNC'

# LGWR ASYNC ASYNC


You can verify TRANSMIT_MODE column of the v$ARCHIVE_DEST view.
It is recommended to use Standby redo log(SRL) files in ASYNC transport mode.
Asynchronous redo transport does NOT affect the performance of the Primary. The Primary database
never waits for any acknowledgement from the standby database in order to complete the commit.
I.e. LGWR does NOT wait for any confirmation that redo data is written on the Standby database.
Delay in transfer redo data to the Standby database or Failure in writing redo data on the
Standby database do NOT impact availability of the Primary database.
EX: log_archive_dest_2='service=STBY_CRMSDB LGWR ASYNC'

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

DATA GUARD OPERATIONS USING SQL*Plus INTERFACE

AFFIRM Vs NOAFFIRM

Controls a whether a redo transport destination acknowledges received redo data before or after
writing it to the standby redo log. (You can verify affirm column of the v$archive_dest v$view).

# AFFIRM ATTRIBUTE
The AFFIRM attribute ensures that a redo transport destination acknowledges received redo data
after writing it to the standby redolog files.
# NO AFFRIM ATTRIBUTE
The NOAFFIRM attribute ensures that a redo transport destination acknowledges received redo
data before writing it to the Standby redolog.
If AFFIRM or NOAFFIRM are NOT specified, default is AFFIRM when the SYNC attribute is specified
and NOAFFIRM when the ASYNC attribute is specified.

EX: log_archive_dest_2='service=STBY_CRMSDB SYNC'


EX: log_archive_dest_2='service=STBY_CRMSDB SYNC AFFRIM'
EX: log_archive_dest_2='service=STBY_CRMSDB ASYNC NOAFFRIM'

NET_TIMEOUT

The NET_TIMEOUT attribute is optional. Specifies the number of seconds that the Primary database
LGWR background process will wait for a response (acknowledgment) from a redo transport destination
before to terminate the connection and marking the standby destination as failed.
If you do not specify any value to net_timeout attribute then the default value is 30 seconds.
Before setting any value to this attribute you need good network bandwidth. Suppose when you
specify lower value (5 seconds) and also having poor network bandwidth leads to the Primary database
may often disconnect from the Standby database.

You can verify net_timeout column of the v$archive_dest v$view.


EX: log_archive_dest_2='service=STBY_CRMSDB SYNC AFFRIM NET_TIMEOUT=20'
EX: log_archive_dest_2=ENABLE;

REOPEN

The REOPEN attribute is optional. Specifies the time in seconds that the log writer should wait
before attempting to access a failed Standby destination. Redo transport services attempt to reopen
failed destination at log switch time. The default value is 300 seconds. Manually you can specify

You can verify reopen_secs column of the v$archive_dest v$view.


EX: log_archive_dest_2='service=STBY_CRMSDB REOPEN=60'

VALID_FOR ROLE BASED DESTINATION

The VALID_FOR attribute is optional. But Oracle recommends that you have to define the VALID_FOR
attribute for each redo transport destination in Data Guard configuration so that redo transport

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

DATA GUARD OPERATIONS USING SQL*Plus INTERFACE

can continue after a role transition (switchover) to any standby database.


This attribute works with two pair of key words => VALID_FOR=(redo_log_type, database_role)

REDO_LOG_TYPE can be set to the following values.

ONLINE_LOGFILE

- This is valid when archiving online redolog files.

STANDBY_LOGFILE This is valid when archiving Standby redolog files.


ALL_LOGFILES - This is valid when archiving either Online Redolog files/Standby Redolog files
DATABASE_ROLE can be set to the following values.
PRIMARY_ROLE This is valid when the database runs only in the Primary role.
STANDBY_ROLE This is valid when the database runs only in Standby role
ALL_ROLES

- This is valid when the runs in either Primary/Standby role.

You have to specify VALID_FOR attribute when setting LOG_ARCHIVE_DEST_n parameter. If VALID_FOR
attribute is NOT specified, online redo log files and standby redo log files will be archived
depending on role of the database.

EX: LOG_ARCHIVE_DEST_1='location=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES, ALL_ROLES)


EX: LOG_ARCHIVE_DEST_2='service=STBY_CRMSDB LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES, PRIMARY_ROLE)

DB_UNIQUE_NAME

This parameter specifies a unique name for the database.


DB_UNIQUE_NAME parameter is used in the LOG_ARCHIVE_CONFIG parameter.
If you dont set this parameter explicitly its value will be same as the DB_NAME parameter.
The parameter LOG_ARCHIVE_CONFIG lists valid db_unique_name separated by comma in DR configuration.
You can verify DB_UNIQUE_NAME column of V$DATABASE and V$ARCHIVE_DEST v$views
SQL> show parameter db_unique_name;
EX: LOG_ARCHIVE_CONFIG='DG_CONFIG=(crms, stbycrms1, stbycrms2)'

CHANGE PROTECTION MODES

# ENVIRONMENT DETAILS
Database Name

: crms

Primary db_unique_name : stbycrms


Standby db_unique_name : crms
Primary Site

: SERVER1 192.168.1.131

Standby Site

: SERVER2 192.168.1.130

Standby Database type

: Physical Standby

Data Protection Mode

: MAXIMUM PERFORMANCE

Prior to changing the protection there are a few preliminary steps that should be taken.
In order to change data protection mode to Max Availability or Max Protection from Max Performance,
we need Standby Redo log files on the Standby database server and also Redo records synchronously
SYNC transmitted from the Primary database to Standby database using LGWR Processes.

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

DATA GUARD OPERATIONS USING SQL*Plus INTERFACE

MAX PERFORMANCE -TO - MAX AVAILABILITY

# ON PRIMARY DATABASE SERVER


SYS> select name, db_unique_name, open_mode, switchover_status from v$database;
NAME

DB_UNIQUE_NAME

OPEN_MODE

SWITCHOVER_STATUS

--------- ------------------------------ -------------------- -------------------CRMS

stbycrms

READ WRITE

TO STANDBY

SYS> select protection_mode, protection_level, database_role from v$database;


PROTECTION_MODE

PROTECTION_LEVEL

DATABASE_ROLE

-------------------- -------------------- ---------------MAXIMUM PERFORMANCE

MAXIMUM PERFORMANCE

PRIMARY

SYS> show parameter log_archive_config;


NAME

TYPE

VALUE

------------------------------------ ----------- -----------------------------log_archive_config

string

dg_config=(stbycrms,crms)

SYS> show parameter log_archive_dest_2;


NAME

TYPE

VALUE

------------------------------------ ----------- -----------------------------log_archive_dest_2

string

service=crmsdb LGWR ASYNC


VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=crms

# ON STANDBY DATABASE SERVER


SYS> select protection_mode, protection_level, database_role from v$database;
PROTECTION_MODE

PROTECTION_LEVEL

DATABASE_ROLE

--------------------

-------------------- ----------------

MAXIMUM PERFORMANCE

MAXIMUM PERFORMANCE

PHYSICAL STANDBY

SYS> select name, db_unique_name, open_mode, switchover_status from v$database;


NAME

DB_UNIQUE_NAME

OPEN_MODE

SWITCHOVER_STATUS

--------- --------------- -------------------CRMS

crms

--------------------

READ ONLY WITH APPLY

NOT ALLOWED

SYS> select dest_id, dest_name, status, type, srl, recovery_mode


from v$archive_dest_status where dest_id=1;
DEST_ID DEST_NAME

STATUS

TYPE

SRL

---------- ---------------------- --------- -------------- --1

LOG_ARCHIVE_DEST_1

VALID

LOCAL

NO

RECOVERY_MODE
----------------------MANAGED REAL TIME APPLY

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

DATA GUARD OPERATIONS USING SQL*Plus INTERFACE

In order to change Protection mode to MAX AVAILABILITY/MAX PROTECTION we must have Standby redo
log files. In my case, already I have Standby Redo Log groups at both (Primary and Standby).

# ORL GROUPS AND SRL GROUPS AT PRIMARY


SYS> select group#, member, type from v$logfile order by group#;
GROUP# MEMBER

TYPE

---------- ------------------------------------------------------

----------

1 /u03/app/oracle/oradata/REDOLOG/stbycrms/redo1b.log

ONLINE

1 /u01/app/oracle/oradata/REDOLOG/stbycrms/redo1a.log

ONLINE

2 /u01/app/oracle/oradata/REDOLOG/stbycrms/redo2a.log

ONLINE

2 /u03/app/oracle/oradata/REDOLOG/stbycrms/redo2b.log

ONLINE

3 /u01/app/oracle/oradata/REDOLOG/stbycrms/redo3a.log

ONLINE

3 /u03/app/oracle/oradata/REDOLOG/stbycrms/redo3b.log

ONLINE

4 /u03/app/oracle/oradata/REDOLOG/stbycrms/stby_redo4.log

STANDBY

5 /u03/app/oracle/oradata/REDOLOG/stbycrms/stby_redo5.log

STANDBY

6 /u03/app/oracle/oradata/REDOLOG/stbycrms/stby_redo6.log

STANDBY

7 /u03/app/oracle/oradata/REDOLOG/stbycrms/stby_redo7.log

STANDBY

ANY STANDBY REDO LOG FILES ACTIVE ON PRIMARY?

SYS> select group#, sequence#, bytes, used, status from v$standby_log;


GROUP#

SEQUENCE#

BYTES

USED STATUS

---------- ---------- ---------- ---------- ---------4

52428800

512 UNASSIGNED

52428800

512 UNASSIGNED

52428800

512 UNASSIGNED

52428800

512 UNASSIGNED

Standby Redo log files on the Primary database will be used only when you perform Switchover.
WHY STANDBY REDO LOG FILES?
It is always better to create SRL on both sides (Primary and Standby), Oracle recommends that you
create a standby redo log files at primary database also. SRL is NOT mandatory for Primary database
but its good and useful in Role conversion from Primary to Standby database so that the Primary
database can switch over quickly to the Standby role without any extra step. It is important to
configure the Standby Redo Logs (SRL) with the same size as the online redo logs.

# CHECK SIZE OF THE ORL FILES ON PRIMARY


SYS> select group#, bytes/1024/1024 from v$log;
GROUP# BYTES/1024/1024
---------- --------------1

50

50

50

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

DATA GUARD OPERATIONS USING SQL*Plus INTERFACE

On the Primary database I have 3 Online Redo LOG Groups and each file size is 50M. It is better to
create additionally an extra group for Standby redo log. In my case, I have 4 SRL Groups on the
Primary with the same size of the Online Redo log groups.
SYS> select group#, bytes/1024/1024 from v$standby_log;
GROUP# BYTES/1024/1024
---------- --------------4

50

50

50

50

HOW TO CREATE SRL GROUP ON PRIMARY ?


Suppose Standby redo log groups yet not configured on the Primary database. You can use following
SQL statement to create Standby redo log groups on the Primary database.

# CREATE SRL ON THE PRIMARY DATABSE


SYS> alter database add standby logfile group 4

'/location path/.../sredo04.log' size 50m;

...
SYS> alter database add standby logfile group 5

'/location path/.../sredo05.log' size 50m;

...
SYS> alter database add standby logfile group 6

'/location path/.../sredo06.log' size 50m;

...
SYS> alter database add standby logfile group 7

'/location path/.../sredo07.log' size 50m;

...
Once you create SRL groups on the Primary database, using following query you can verify it.
# VERIFY STANDBY REDOLOG GROUPS ON PRIMARY DATABASE
SYS> select b.group#, b.member, a.bytes from v$logfile b, v$standby_log a
where a.group# = b.group#;
...
WHY WE NEED SRL GROUPS ON STANDBY?
As I said, suppose you want to change the protection mode to either MAX AVAILABILITY/MAX PROTECTION
you must have the standby redo logs configured on the standby database.
If we want to use of REAL TIME APPLY, first you need to configure SRL files on the Standby side.
Once you configure Standby Redo Logs on the Standby database, LNS ships redo to RFS then RFS writes
redo on Standby Redo log files. Redo is applied directly through the SRL (Real Time Apply) and
does NOT have to wait for the SRL's to be archived. Finally ARCn process archives the standby redo
logs to archive destination.

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

DATA GUARD OPERATIONS USING SQL*Plus INTERFACE

In my case already I have SRL group on the Standby database; because I am using Real-Time-Apply.

# ORL FILES AND SRL FILES AT STANDBY DATABASE


SYS> select group#, member, type from v$logfile order by group#;
GROUP# MEMBER

TYPE

---------- ---------------------------------------------------- ------1 /u03/app/oracle/oradata/REDOLOG/crms/redo1b.log

ONLINE

1 /u01/app/oracle/oradata/REDOLOG/crms/redo1a.log

ONLINE

2 /u01/app/oracle/oradata/REDOLOG/crms/redo2a.log

ONLINE

2 /u03/app/oracle/oradata/REDOLOG/crms/redo2b.log

ONLINE

3 /u01/app/oracle/oradata/REDOLOG/crms/redo3a.log

ONLINE

3 /u03/app/oracle/oradata/REDOLOG/crms/redo3b.log

ONLINE

4 /u03/app/oracle/oradata/REDOLOG/crms/stby_redo4.log

STANDBY

5 /u03/app/oracle/oradata/REDOLOG/crms/stby_redo5.log

STANDBY

6 /u03/app/oracle/oradata/REDOLOG/crms/stby_redo6.log

STANDBY

7 /u03/app/oracle/oradata/REDOLOG/crms/stby_redo7.log

STANDBY

Before you create SRL groups on the Standby database first cancel the MRP (If MRP is running).
Once you create required SRL groups then enable MRP on the Standby database.

# CANCEL MRP (If IT IS RUNNING)


SYS> alter database recover managed standby database cancel;
Database altered.
We need to create 4 Standby Redo Log (SRL) groups of size same as online redo log groups (50M) on
the standby database.
# CREATE SRL ON THE STANDBY DATABASE
SYS> alter database add standby logfile group 4

'/location path/.../sredo04.log' size 50m;

...
SYS> alter database add standby logfile group 5

'/location path/.../sredo05.log' size 50m;

...
SYS> alter database add standby logfile group 6

'/location path/.../sredo06.log' size 50m;

...
SYS> alter database add standby logfile group 7

'/location path/.../sredo07.log' size 50m;

...

# START MRP ON THE STANDBY


SYS> alter database recover managed standby database disconnect using current logfile;
Database altered.
$ ps ef | grep mrp
...

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

DATA GUARD OPERATIONS USING SQL*Plus INTERFACE

Next you need to set LOG_ARCHIVE_DEST_n parameter to reflect redo transport for the new Protection
mode. As we discussed earlier redo shipping parameter LOG_ARCHIVE_DEST_2 attributes should be
related to synchronous (SYNC) mode.

# ON PRIMARY DATABASE
SYS> show parameter log_archive_dest_2;
NAME

TYPE

VALUE

--------------------- --------- -------------------------------------------------------log_archive_dest_2

string

service=crmsdb LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,


PRIMARY_ROLE) DB_UNIQUE_NAME=crms

SYS> alter system set log_archive_dest_2='service=crmsdb LGWR SYNC AFFIRM


VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=crms' scope=both;
System altered.
SYS> show parameter log_archive_dest_2;
NAME

TYPE

VALUE

--------------------- --------- -------------------------------------------------------log_archive_dest_2

string

service=crmsdb LGWR SYNC VALID_FOR=(ONLINE_LOGFILES,


PRIMARY_ROLE) DB_UNIQUE_NAME=crms

SYS> shutdown immediate;


Database closed.
Database dismounted.
ORACLE instance shut down.
SYS> startup mount;
...
Database mounted.
SYS> alter database set standby database to maximize availability;
Database altered.
SYS> alter database open;
Database opened.
SYS> select db_unique_name, database_role, protection_mode, protection_level from v$database;
DB_UNIQUE_NAME
DATABASE_ROLE
PROTECTION_MODE
PROTECTION_LEVEL
------------------------------ ---------------- -------------------- -------------------stbycrms

PRIMARY

MAXIMUM AVAILABILITY

MAXIMUM AVAILABILITY

# ON STANBY DATABASE
SYS> select db_unique_name, database_role, protection_mode, protection_level from v$database;
DB_UNIQUE_NAME

DATABASE_ROLE

PROTECTION_MODE

PROTECTION_LEVEL

------------------------------ ---------------- -------------------- -------------------crms

PHYSICAL STANDBY MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

DATA GUARD OPERATIONS USING SQL*Plus INTERFACE

2 - MAX AVAILABILITY TO - MAX PROTECTION

# ON PRIMARY DATABASE
SYS> select db_unique_name, database_role, protection_mode, protection_level from v$database;
DB_UNIQUE_NAME

DATABASE_ROLE

PROTECTION_MODE

PROTECTION_LEVEL

------------------------------ ---------------- -------------------- ---------------------stbycrms

PRIMARY

MAXIMUM AVAILABILITY

MAXIMUM AVAILABILITY

SYS> alter database set standby database to maximize protection;


Database altered.
SYS> select db_unique_name, database_role, protection_mode, protection_level from v$database;
DB_UNIQUE_NAME

DATABASE_ROLE

PROTECTION_MODE

PROTECTION_LEVEL

------------------------------ ---------------- -------------------- -------------------stbycrms

PRIMARY

MAXIMUM PROTECTION

MAXIMUM PROTECTION

# ON STANDBY DATABASE
SYS> select db_unique_name, database_role, protection_mode, protection_level from v$database;
DB_UNIQUE_NAME

DATABASE_ROLE

PROTECTION_MODE

PROTECTION_LEVEL

------------------------------ ---------------- -------------------- -------------------crms

PHYSICAL STANDBY MAXIMUM PROTECTION

MAXIMUM PROTECTION

Now I am going to crash Standby database instance 'crms', once I kill 'crms' instance lets see
oracle reaction in MAXIMUM PROTECTION mode.

# FIND PMON OS ID & KILL IT


$ ps -ef | grep pmon
oracle

28213

oracle

28406 19160

0 11:31 ?

00:00:00 ora_pmon_crms

0 11:51 pts/1

00:00:00 grep pmon

$ kill -9 28213
# CHECK WHETHER crms INSTANCE CRASHED OR NOT
$ ps ef | grep pmon
oracle

28408 19160

0 11:51 pts/1

00:00:00 grep pmon

# ALERT LOG OF STBYCRMS PRIMARY DATABASE SERVER


$ tail f alert_stbycrms.log
LGWR: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3113)
LGWR: Error 1041 disconnecting from destination LOG_ARCHIVE_DEST_2 standby host 'crmsdb'
Error 1034 received logging on to the standby

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

DATA GUARD OPERATIONS USING SQL*Plus INTERFACE

LGWR: Error 1034 attaching to RFS for reconnect


ARC1: Error 1034 attaching to RFS for reconnect
PING[ARC1]: Error 3113 when pinging standby crmsdb.
Error 1034 received logging on to the standby
LGWR: Error 1034 attaching to RFS for reconnect
..
...
Errors in file /u01/app/oracle/diag/rdbms/stbycrms/stbycrms/trace/stbycrms_lgwr_26650.trc:
ORA-03113: end-of-file on communication channel
Error 3113 for archive log file 3 to 'crmsdb'
Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED
LGWR: All standby destinations have failed
******************************************************
WARNING: All standby database destinations have failed
WARNING: Instance shutdown required to protect primary
******************************************************
LGWR (ospid: 26650): terminating the instance due to error 16098
Thu Dec 03 11:56:43 2015
ORA-1092 : opitsk aborting process
Instance terminated by LGWR, pid = 26650

3 SET DATA PROTECTECTION MODE TO - MAX PERFORMANCE

# ON THE PRIMARY DATABASE


SYS> startup mount;
...
Database mounted.
SYS> select protection_mode, protection_level from v$database;
PROTECTION_MODE

PROTECTION_LEVEL

-------------------- -------------------MAXIMUM PROTECTION

UNPROTECTED

SYS> alter system set log_archive_dest_2=service='crmsdb LGWR ASYNC


VALID_FOR=(all_logfiles, primary_role) db_unique_name=crms' scope=both;
System altered.
SYS> alter database set standby database to maximize performance;
Database altered.
SYS> alter database open;
Database altered.
SYS> select protection_mode, protection_level from v$database;
PROTECTION_MODE

PROTECTION_LEVEL

-------------------- -------------------MAXIMUM PERFORMANCE

MAXIMUM PERFORMANCE

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu