ORACLE 10g DATAGUARD Ritesh Chhajer Sr. Oracle DBA

 Physical vs. Logical Standby  Standby Protection Modes  Log Transport Attributes  Standby Redo Logs  Setup Physical Standby step-by-step  Managing and Monitoring standby  Role Transition: Switchover/Failover Agenda

Purpose To provide an efficient disaster recovery solution by maintaining transactionally consistent copies of the production database at a remote site. Physical Standby  Kept in sync with the primary by using media recovery to apply redo generated on primary  Used for BCP  Can be opened in read-only mode but redo won’t be applied for that time Logical Standby  Kept in sync with the primary by transforming redo data received from primary into logical SQL statements and then executing those SQLs against the standby database.  Used to offload reporting from the primary database  Can be opened in read-only mode while the changes are being applied. Overview

Decide on Standby Protection Mode before setting it up: 1.MAXIMUM PROTECTION Pre-requisites  Using LGWR SYNC AFFIRM, transport of redo logs to be done in a synchronous fashion.  Standby redo logs (SRLs) need to be created on standby site.  At least one standby must be available for the primary database to function.  Need high speed network. Pros  Zero data loss Cons  Primary shuts down if in case of network issues unable to commit on standby at the same time. Protection Modes

2. MAXIMUM AVAILABILITY Pre-requisites  Using LGWR SYNC AFFIRM, transport of redo logs to be done in a synchronous fashion.  Standby redo logs (SRLs) need to be created on standby site. Features  If network issues, switches to maximum performance and when the fault corrects switches back to maximum availability.  Data loss only if primary loses it’s redo logs. SQL> alter database set standby to maximize availability; 3. MAXIMUM PERFORMANCE  Asynchronous redo shipping using ARC or LGWR ASYNC.  No impact on primary’s performance even if network issues.  No need to create SRLs unless real-time apply is needed on the standby site. Protection Modes

Log Transport Service Attributes are defined on primary in log_archive_dest_2 ARC(default)  ARC will first archive the online redo log to local destination on primary. Then second ARC process spawns and writes the archive to remote standby.  By default, log_archive_local_first=true in init.ora on primary. DO NOT CHANGE IT. LGWR  In contrast to ARC, which transmits redo to standby only at log switch time, LGWR attribute instructs LGWR process to transmit redo to standby at the same time while the redo is writing to the online redo logs.  Transmission of redo can be done synchronously (SYNC) or asynchronously (ASYNC) AFFIRM All Disk I/O at standby to be performed synchronously Log Transport Services

SYNC  By default, LGWR archives synchronously. Once I/O is initiated, archiving must wait for I/O to complete. This means transaction is not committed on primary database until redo data necessary to recover that transaction is received by the destination. ASYNC  LGWR does not wait for the I/O to complete. LGWR network server process(LNS) performs actual network I/O.  User-configurable buffer used to accept outbound redo data from LGWR. ASYNC=20480 indicates a 10MB buffer. Maximum can be upto 50MB. MAX_FAILURE  Defines number of times to retry a destination that has been closed due to a failure NET_TIMEOUT  Used with LGWR ASYNC.  Defines how many seconds to wait before giving up on a network connection. REOPEN  Determines how long the primary waits before retrying a connection Log Transport Services

Creating a physical standby Both primary and standby systems must be identical in configuration with regards to operating system, platform architecture and database version. H/W config may differ. 1. Enable archiving on primary log_archive_dest_1=‘LOCATION= ’ log_archive_format=%t_%s_%r.dbf log_archive_start=true( As of 10g release, its deprecated ) SQL> shutdown immediate; SQL> startup mount; SQL> alter database archivelog; SQL> alter database open; Setup

2. Enable force logging on primary SQL> alter database force logging; This is required as any nologging operations would not be logged within redo stream. In this mode, nologging operations are permitted to run, but changes are placed into redo. 3. Creating password file on primary and standby Create a password file( if not created yet ) orapwd file=orapw password= remote_login_passwordfile=exclusive SYS password must be identical on both primary and standby for log transport services to function. 4. Creating standby controlfile on primary SQL> alter database create standby controlfile as ‘ ’; 5. Take hotbackup of primary and copy datafiles,archivelogs and standby controlfile to standby 6. Create tnsnames.ora aliases for primary and standby on both primary and standby NOTE: DO NOT COPY REDO LOGS SINCE STANDYB WILL CREATE IT’S OWN Setup contd.

7. Prepare init.ora on primary db_name=‘TEST’ db_unique_name=‘PRI’ service_names=‘PRI_SERVICE’ log_archive_config=‘DG_CONFIG=(PRI,STDBY )’ log_archive_dest_1=‘LOCATION= ’ log_archive_dest_state_1=enable log_archive_dest_2=‘SERVICE= ARCH ASYNC reopen=300 max_failure=0 net_timeout=60 VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=STDBY’ log_archive_dest_state_2=enable log_archive_min_succeed_dest=1 log_archive_max_processes=2 standby_file_management=auto fal_server= fal_client= Setup contd.

8. Prepare init.ora on standby db_name=‘TEST’ db_unique_name=‘STDBY’ service_names=‘STDBY_SERVICE’ log_archive_config=‘DG_CONFIG=(PRI,STDBY )’ log_archive_dest_1=‘LOCATION= ’ log_archive_dest_state_1=enable log_archive_dest_2=‘SERVICE= ARCH ASYNC reopen=300 max_failure=0 net_timeout=60 VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=PRI’ log_archive_dest_state_2=enable log_archive_min_succeed_dest=1 log_archive_max_processes=2 standby_file_management=auto fal_server= fal_client= Setup contd.

9. Mount the standby and start applying the changes SQL> startup mount; SQL> alter database recover managed standby database disconnect; To put standby in read-write mode SQL> alter database activate standby database; To stop the apply: SQL> alter database recover managed standby database cancel immediate; To start real time apply: SQL> alter database recover managed standby database using current logfile disconnect; This needs creation on SRLs (standby redo logs) To put standby in read-only mode SQL> alter database recover managed standby database using current logfile disconnect; SQL> alter database open read only; Note: Once the standby is made primary (read-write), verify redo logs and tempfiles. Setup contd.

 On primary check if archive logs are getting copied to standby: SQL> select status from v$archive_dest where dest_id=2;  On Standby monitor MRP process: SQL> select status from v$managed_standby where process like ‘%MRP%’; Status must be “APPLYING_LOG” or “WAIT_FOR_LOG” ps –ef|grep mrp  On standby detect archive gap SQL> select * from v$archive_gap; This will return records if MRP status is “WAIT_FOR_GAP”  With 10gR2, v$dataguard_stats is introduced to monitor redo transport/apply progress; SQL> select value from v$dataguard_stats where name=‘apply lag’; SQL> select value from v$dataguard_stats where name=‘transport lag’;  Note: In case Dataguard is RAC, MRP process would be applying on one of the node. If this node crashes, MRP must be started on that surviving node to which VIP of the crashed node has failed over. Monitoring

Guidelines when creating standby redo logs:  Number of standby redo logs should be the same number as online redo logs plus one.  Standby redo logs should be exactly the same size as the online redo logs.  SRLs should be created on both primary and standby to facilitate seamless role changes.  In a RAC environment, all SRLs should be on a shared disk and may be thread specific.  Used with maximum protection modes and when real-time apply is used. How SRLs work? 1.LGWR process on primary initiates a connection with standby. 2.Standby listener responds by spawning a process called RFS(remote file server) 3.RFS process creates n/w conn with processes on primary and waits for data to arrive. 4.Once data comes, RFS places it into standby redo logs. 5.When log switch occurs on primary, standby redo logs are switched and RFS will go to next available standby redo log. Standby Redo Logs

 Switchover allows a primary and standby to reverse roles without any data loss.  No need to re-create the old primary. Performed for planned maintenance. Steps: 1. Verify if primary can be switched over to standby SQL> select switchover_status from v$database; If value returns “TO_STANDBY”, its alright to switch the primary to standby role. 2. Convert primary to standby SQL> alter database commit to switchover to physical standby; If value is “SESSIONS ACTIVE” from step 1, then SQL> alter database commit to switchover to physical standby with session shutdown; 3. Shutdown the restart the old primary as standby SQL> shutdown immediate; SQL> startup mount; At this point, we now have both databases as standby. 4. On target standby database, verify switchover status. If value is “TO_PRIMARY” then SQL> alter database commit to switchover to primary; If value is “SESSIONS ACTIVE”, then append “WITH SESSION SHUTDOWN” to above command. 5. Shutdown and restart the new primary database SQL> shutdown immediate;startup; SWITCHOVER

 Failover implies data loss and can result in the need to re-create old primary. Steps: 1. Identify and resolve any gaps that may exist on standby. SQL> select * from v$archive_gap; Copy missing archives from primary to standby and register them to standby controlfile. SQL> alter database register physical logfile ‘ ’; 2. If standby redo logs are configured and active, SQL> alter database recover managed standby database finish; If NO SRLs or they are not active, SQL> alter database recover managed standby database skip standby logfile; 3. Convert standby to primary; SQL> alter database commit to switchover to primary; 4. Restart new primary SQL> shutdown immediate;startup; Note: Once the standby is made primary (read-write), verify redo logs and tempfiles. FAILOVER

THANK YOU Get in Touch