ROLE TRANSITIONS AND CONFIGUR ING PROTECTION MODES USING SQLPLUS INTERFACE.pdf
Short Description
Download ROLE TRANSITIONS AND CONFIGUR ING PROTECTION MODES USING SQLPLUS INTERFACE.pdf...
Description
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. 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
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
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> 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 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.
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 it’s 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
0
ARCH
CONNECTED
0
ARCH
CONNECTED
0
ARCH
CONNECTED
0
RFS
IDLE
0
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
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.
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 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'
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 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.
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
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
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
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;
... 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 let’s see oracle reaction in MAXIMUM PROTECTION mode.
# FIND PMON OS ID & KILL IT $ ps -ef | grep pmon oracle
28213
1
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
View more...
Comments
