Role Transitions and Configur Ing Protection Modes Using Sqlplus Interface PDF

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> 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

SWITCHOVER PROCESS STEP 1:
SYS> select name, db_unique_name, database_role from v$database;
NAME DB_UNIQUE_NAME DATABASE_ROLE

--------- --------------- ----------------
CRMS crms PRIMARY
SYS> alter system switch logfile;

System altered.
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.

# 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> 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
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> startup;
...

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 RECOVERY_MODE

---------- ------------------------ --------- --------- --- -------------------------
1 LOG_ARCHIVE_DEST_1 VALID LOCAL NO 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.

# 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. It’s possible to move the old
Primary database back in time to point just before where the failure occurred.
The only consideration is you must have enabled Flashback Database on the Primary database before
the failover. It’s always good idea and recommended to enable flashback in Standby database also.
ENVIRONMENT DETAILS
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
Let’s 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

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.

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.
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 /u01/app/oracle/oradata/REDOLOG/stbycrms/redo3a.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.

SYS> archive log list;
Database log mode Archive Mode

Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 1
Next log sequence to archive 1
Current log sequence 1
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> 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 it’s 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.

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.
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.
..
...
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;
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


ORA-01507: database not mounted
SYS> startup mount;

ORACLE instance started.
..
...
Database mounted.
STEP 7: START REDO APPLY
# STARTING REAL TIME APPLY
Database altered.
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 it’s a
good idea to check if MRP is working on the current standby.

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

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

--------- ------------ ----------
ARCH CONNECTED 0
ARCH CONNECTED 0
ARCH CONNECTED 0
ARCH CONNECTED 0
RFS IDLE 0
5 rows selected.
# RESTART REDO APPLY ONCE AGAIN.
Database altered.
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 8
Next log sequence to archive 10
Current log sequence 10
SYS> select process, status, sequence# from v$managed_standby;
PROCESS STATUS SEQUENCE#

--------- ------------ ----------
ARCH CONNECTED 0
ARCH CONNECTED 0
ARCH CONNECTED 0
ARCH CLOSING 9
RFS IDLE 0
RFS IDLE 0
RFS IDLE 0
RFS IDLE 0
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.

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.

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 won’t 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'

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'

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

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 don’t 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.

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)
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 RECOVERY_MODE

---------- ---------------------- --------- -------------- --- -----------------------
1 LOG_ARCHIVE_DEST_1 VALID LOCAL NO MANAGED REAL TIME APPLY

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
4 /u03/app/oracle/oradata/REDOLOG/stbycrms/stby_redo4.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 0 52428800 512 UNASSIGNED
5 0 52428800 512 UNASSIGNED
6 0 52428800 512 UNASSIGNED
7 0 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 it’s 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
2 50
3 50

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
5 50
6 50
7 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;
...
...
...
...
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.

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
4 /u03/app/oracle/oradata/REDOLOG/crms/stby_redo4.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)
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
...
...
...
...
# START MRP ON THE STANDBY
SYS> alter database recover managed standby database disconnect using current logfile;
Database altered.
$ ps –ef | grep mrp

...

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
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.
NAME TYPE VALUE

--------------------- --------- --------------------------------------------------------
log_archive_dest_2 string service=crmsdb LGWR SYNC VALID_FOR=(ONLINE_LOGFILES,
PRIMARY_ROLE) DB_UNIQUE_NAME=crms

Database closed.
Database dismounted.
SYS> startup mount;

...
Database mounted.
SYS> alter database set standby database to maximize availability;

Database altered.

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

------------------------------ ---------------- -------------------- --------------------
crms PHYSICAL STANDBY MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY

2 - MAX AVAILABILITY – TO - MAX PROTECTION
# ON PRIMARY DATABASE

------------------------------ ---------------- -------------------- ----------------------
stbycrms PRIMARY MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY
SYS> alter database set standby database to maximize protection;

Database altered.

------------------------------ ---------------- -------------------- --------------------
stbycrms PRIMARY MAXIMUM PROTECTION MAXIMUM PROTECTION
# ON STANDBY DATABASE

------------------------------ ---------------- -------------------- --------------------
crms PHYSICAL STANDBY MAXIMUM PROTECTION MAXIMUM PROTECTION
Now I am going to crash Standby database instance 'crms', once I kill 'crms' instance let’s see
oracle reaction in MAXIMUM PROTECTION mode.
# FIND PMON OS ID & KILL IT
$ ps -ef | grep pmon
oracle 28213 1 0 11:31 ? 00:00:00 ora_pmon_crms

oracle 28406 19160 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

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.

Database altered.
SYS> select protection_mode, protection_level from v$database;
PROTECTION_MODE PROTECTION_LEVEL
-------------------- --------------------
MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE

Role Transitions and Configur Ing Protection Modes Using Sqlplus Interface PDF

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Role Transitions and Configur Ing Protection Modes Using Sqlplus Interface PDF

Caricato da

Copyright:

Formati disponibili

DATA GUARD OPERATIONS USING SQL*Plus INTERFACE

User Interfaces for administering Data Guard

SQL*Plus, DGMGRL, and Enterprise Manager

# ON PRIMARY SITE – WHICH WOULD BECOME TO THE NEW STANDBY

SYS> select switchover_status from v$database;

# ON STANDBY SITE - WHICH WOULD BECOME TO THE NEW PRIMARY

SYS> select switchover_status from v$database;

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

SWITCHOVER PROCESS STEP 1:

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

NAME DB_UNIQUE_NAME DATABASE_ROLE

SYS> alter system switch logfile;

SYS> select switchover_status from v$database;

SQL statement result only must be 'TO_STANDBY'.

NOT ALLOWD SESSIONS ACTIVE SWITCHOVER PENDING SWITCHVER LATENT

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

SYS> show parameter log_archive_dest_2;

SYS> show parameter log_archive_dest_state_2;

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

# CONVERT THE PRIMARY DATABASE TO THE NEW STANDBY

# 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 ?

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;

# CONVERT THE PHYSICAL STANDBY TO THE NEW PRIMARY

SYS> alter database commit to switchover to primary;

# SHUTDOWN AND STARTUP THE NEW PRIMARY

SYS> shutdown immediate;

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

PROCESS STEP 7 (ON THE NEW PRIMARY)

By default LOG_ARCHIVE_DEST_STATE_2 value is ENABLE only.

# 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

# START MANAGED REOVER ON THE NEW STANDBY

SYS> alter database recover managed standby database disconnect; or

# START REAL-TIME-RECOVERY PROCESS (REAL-TIME-APPLY)

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

SYS> select DEST_ID, DEST_NAME, STATUS, TYPE, SRL, RECOVERY_MODE from

DEST_ID DEST_NAME STATUS TYPE SRL RECOVERY_MODE

# 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

# MAKE LOG SWITCH ON THE NEW PRIMARY DATABSE

SYS> alter system switch logfile;

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

# ON THE NEW PRIMARY

SYS> select thread#, max(sequence#) from v$archived_log group by thread#;

# ON THE NEW STANDBY

PERFORM FAILOVER TEST

Database Name : crms

# PRIMARY DATABASE SERVER

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

NAME DB_UNIQUE_NAME DATABASE_ROLE PROTECTION_MODE