You are on page 1of 49

Oracle Data Guard

Causes of Data Loss
Hardware & system errors Human errors 36% 49%

Computer viruses
Software corruption Natural disasters

7%
4% 3%

Source: Disaster Recovery Journal

System Failures Site Failures Human Error

Real Application Clusters
Continuous Availability for all Applications

Data Guard
Guaranteed Zero Data Loss

Unplanned Downtime

Flashback
Guaranteed Zero Data Loss

Storage/Net Failures
System Maintenance Planned Downtime Database Maintenance

ASM Mirroring
Storage Failure Protection

Dynamic Reconfiguration
Capacity on Demand without Interruption

Online Redefinition
Adapt to Change Online

What is a Standby Database ?
A copy of a production database that you can use for disaster protection. You can update the standby database with redo logs from the production database in order to keep it current. If a disaster destroys the production database, you can activate the standby database and make it the new production database. You can maintain the standby data in one of the following modes:
For physical standby databases Redo Apply For logical standby databases SQL Apply A Standby Database is NOT Data Guard

Why Data Guard? Data Guard helps you protect your Data. Takes your data and automatically puts it elsewhere Makes it available for Failover in case of failure. The apply process also revalidates the log records to prevent application of any log corruptions Geographically dispersed sites Useful for logical data corruptions if lag behind used Flexible configuration options for protection level Reporting and backups can be diverted to standby Automatic resync for failed primary Switchover for Maintenance .

Traditional Physical Standby Databases Investment in Disaster Recovery .

Active Data Guard 11g Investment in Improved Quality of Service .

For example. and the standby database may be on Linux. O. the primary database may be on Windows. binaries and Oracle database binaries.S.1 for latest capabilities and restrictions . See MetaLink Note 413484. on primary and standby systems.Requirements Data Guard 11g has several options for deploying different CPU architectures.

000 .7)8)/1.Bandwidth Requirements Depends on Redo generation Find peak redo in AWR report Load Profile ~~~~~~~~~~~~ Redo size: Per Second --------------51.000.09 Bandwidth in MBPS = (redo bytes per sec /0.177.944.64 Per Transaction --------------5.

Physical Standby Protection Modes Physical Standby Architecture Standby Redo Logs Real Time Apply Automatic Resynchronization .

mandatory/optional Minimal performance impact . affirm Primary db shutdown when unable to access stdby Maximum Availability Arch_dest: mandatory. lgwr. sync. sync/async.Database Protection Modes Maximum Protection No Data Loss and No data divergence Arch_dest: mandatory. lgwr. sync. affirm Protection auto lowered when stdby is unavailable Maximum Performance Arch_dest: lgwr/arch.

synchronization with the primary is automatic ALTER DATABASE SET STANDBY TO MAXIMIZE AVAILABILITY.Maximum Availability Mode Protection Mode Maximum Availability Zero Data Loss Failure Protection Protects Against Primary Failure Redo Shipping LGWR using SYNC Zero Data Loss as long as the network stays up! Enforces protection of every transaction Configuration: LGWR SYNC If last standby is unavailable. processing continues at primary When the standby becomes available again. .

Architecture Primary database transactions LGWR MRP or LSP (MRP only) RFS Standby database Online redo logs Oracle net Standby redo logs ARC0 Backup Reports FAL ARC0 Archived redo logs Archived redo logs .

Standby Redo Logs Standby redo logs Archived redo logs Redo from primary database RFS MRP/LSP ARC0 Standby database .

RECOVERY_MODE column in V$ARCHIVE_DEST_STATUS displays “MANAGED REAL TIME APPLY” .Real Time Apply Redo data is applied to the standby database as soon as it is received from the primary database In Oracle9i Data Guard this apply has to wait till an archivelog is created on the standby database For Redo Apply: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE When real time apply is enabled.

PRIMARY_ROLE) 4> DB_UNIQUE_NAME=tmstby'.tmstby)' SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY. SQL> SELECT PROTECTION_MODE.SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=tmstby 2> OPTIONAL LGWR SYNC AFFIRM 3> VALID_FOR=(ONLINE_LOGFILES. SQL> ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(tmtst. PROTECTION_LEVEL FROM V$DATABASE. PROTECTION_MODE PROTECTION_LEVEL ----------------------------------------MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY .

Real-Time Apply Architecture Oracle Transactions Net Physical Logical Standby Database MRP/ LSP LGWR RFS Primary Database ARCH Online Redo Logs Standby Redo Logs ARCH Real Time Apply Archived Redo Logs Archived Redo Logs .

real-time reporting Faster switchover and failover times Reduces planned and unplanned downtime Better Recovery Time Objective (RTO) for DR .Real Time Apply Benefits Standby databases now more closely synchronized with the primary More up-to-date.

Standby Statspack in 11G Big performance boost in Oracle 11G Up to 100% increase in redo apply performance New standby statspack in Oracle 11G See MetaLinkNote 454848. OEM.Real Time Apply -Tuning Media Recovery Monitor via Data Dictionary.1 Includes information specific to a standby Output from V$RECOVERY_PROGRESS Output from V$MANAGED_STANDBY .

Data Dictionary V$DATABASE DATABASE_ROLE: LOGICAL STANDBY. FS_FAILOVER_STATUS: synchronization status V$DATAGUARD_STATS V$DATAGUARD_STATUS V$LOG & V$STANDBY_LOG: Redo log changed. V$MANAGED_STANDBY : Recovery progress . PHYSICAL STANDBY or PRIMARY PROTECTION_LEVEL: current protection mode setting.

time_computed from v$dataguard_stats where name='apply lag'. Query . If you do not wish to connect to the Primary -determine the value for APPLY LAG for a “best estimate” Use Enterprise Manager monitoring V$DATAGUARD_STATS select value.Determining Query Latency From Primary (requires database link) select scn_to_timestamp( (select current_scn from v$database) )-scn_to_timestamp( (select current_scn from v$database@dg) ) from dual.unit.

and it sends missing redo data . primary notified.Automatic Resynchronization Network connectivity problems may occur Data Guard automatically resynchronizes standbys after network connectivity restored Implicit ARCH process idling away on the primary ‘pings’ all standbys on a regular basis to see if they are missing any redo data If so it sends them the missing redo data Explicit Gap discovered during apply process in physical standby Based on FAL_SERVER and FAL_CLIENT settings.

Data Guard Role Transitions Switchover Planned role reversal Used for OS or hardware maintenance Failover Unplanned role reversal Use in emergency Zero or minimal data loss depending on choice of data protection mode Different steps for Physical and Logical Standby Switchover using Enterprise Manager is literally two mouse clicks We’ll do a Physical Standby Failover via the command line using the Broker .

Data Guard Broker Fast-Start Failover Fast-Start Failover Demo Client Failover Oracle 11G Active Data Guard .

Observer automatically executes database failover once threshold has been exceeded. Enables automatic failover with no data loss. Observer detects failure. Observer process continuously monitors primary and standby databases.Fast-Start failover Makes Data Guard more than a Standby Database. A feature of Oracle Database Enterprise Edition. . If the listener is not running on port 1521. Requires 3rd server. Only supports up to Maximum Availability Mode. Install DGMGRL client part of Oracle client administrator software. This trigger can be customized to restart JDBC mid-tier clients and calls any other OCI enabled application. local_listener must be set in the spfile. DB_ROLE_CHANGE trigger fires: enables primary service.

Observer monitoring state of the configuration .Fast-Start Failover 1. Data Guard in steady state – transmitting redo 2.

Disaster strikes the primary – connections lost .Fast-Start Failover 3.

Observer validates connection with target standby 6.Fast-Start Failover 4. Observer begins Fast-Start Failover . Observer times out 5.

Target standby automatically becomes new primary (DB_ROLE_CHANGE trigger fires) .Fast-Start Failover 7.

Observer automatically reinstates old primary to be a new standby 10. After old primary is repaired.Fast-Start Failover 8. Observer re-establishes connection 9. Redo transmission starts from new primary to new standby .

Events that trigger Fast-Start Failover Database conditions: Server crash or shutdown (without db shutdown) Database instance failure (or last instance failure in a RAC configuration) Shutdown abort (or shutdown abort of the last instance in a RAC configuration) Datafiles taken offline due to I/O errors Network conditions: When both the Observer and the standby database lose their network connection to the primary database. and when the standby database confirms that it is in a “synchronized” state. .

not minutes Failover is automatic.Fast-Start Failover Conclusion Fast Site failover time measured in seconds. no manual intervention Reliable Eliminates human error Zero data loss failover Simple Automatically determines if failover criteria is met Original primary database is automatically reinstated as a new standby database following failover .

special Maximum Availability Mode) No automatic failover to a second standby database possible .Fast-Start Failover Conclusion Prevention of "Split Brain" due to accidental startup of former primary database Reduced downtime through automatic activation of the standby database A failover solution without a shared disk system with additional advantages (enhanced data availibity) and even reduced failover time compared to HA cluster Many technical prerequisites (Flashback database.

Fast-Start failover Requirements Fast-Start Failover is a feature of Oracle Data Guard. and can't run without a Data Guard Broker configuration! Observer machine and configuration Special entry in Data Guard Broker configuration Maximum Availability Mode (mandatory) but: special startup behaviour but: primary stalls in certain situations Flashback database must be activated .

Wait until Fast_Start occurs on TMSTBY 5. Configure Observer 3. Verify that observer reinstates database TMTST . Restart the old primary TMTST 6. Shutdown abort on the primary database TMTST 4.Demo: Switchover 1. Configure Broker and Fast_Start Failover 2.

SQL> ALTER DATABASE FLASHBACK ON. . SQL> ALTER SYSTEM SET DG_BROKER_CONFIG_FILE2 ='+TVBSDG1/dr2tmstby. SQL> ALTER SYSTEM SET DG_BROKER_START=TRUE. SQL> show parameter flash NAME TYPE db_flashback_retention_target integer VALUE /tst/dump/oracle/fra 2G VALUE 1440 (1 day) Broker Parameters: SQL> ALTER SYSTEM SET DG_BROKER_CONFIG_FILE1 ='+TVBSDG1/dr1tmstby.dat‘. SQL> STARTUP MOUNT. FLASHBACK_ON NO SQL> SHUTDOWN IMMEDIATE. SQL> ALTER DATABASE OPEN.dat‘.Demo: Configure Fast_Start Failover Flash-Recovery areas are setup on both sides SQL> show parameter DB_RECOVERY_FILE_DEST NAME TYPE db_recovery_file_dest string db_recovery_file_dest_size big integer Setup Flashback Database (on both): SQL> select FLASHBACK_ON from v$database.

2.za) (ORACLE_HOME = /tst/opt/apps/oracle/database/10.co.za) (ORACLE_HOME = /tst/opt/apps/oracle/database/10.co.ora on Primary SID_LIST_LSNR_DGTEST = (SID_LIST= (SID_DESC = (GLOBAL_DBNAME = tmtst.4) (SID_NAME = tmtst) ) (SID_DESC = (GLOBAL_DBNAME = tmtst_DGMGRL.vodacom.4) (SID_NAME = tmtst) ) ) .2.Demo: Configure Fast_Start Failover Listener.0.vodacom.0.

Demo: Configure Fast_Start Failover Tnsnames on both: TMTST.za) ) ) TMSTBY.za)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = tmstby_DGMGRL.CO.co.co.co.VODACOM.ZA = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = tvbs01.za)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = tmtst_DGMGRL.vodacom.vodacom.ZA = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = prab03.za) ) ) .CO.VODACOM.vodacom.co.vodacom.

Database "tmstby" added DGMGRL> ENABLE CONFIGURATION. DGMGRL> EDIT DATABASE tmtst SET PROPERTY 'LogXptMode'='SYNC'. DGMGRL> START OBSERVER. -> tns entry Configuration "tmdrtest" created with primary database "tmtst" DGMGRL> ADD DATABASE tmstby AS > CONNECT IDENTIFIER IS tmstby > MAINTAINED AS PHYSICAL. DGMGRL> SHOW CONFIGURATION. DGMGRL> SHOW DATABASE VERBOSE tmtst. DGMGRL> CREATE CONFIGURATION TMDRTEST AS > PRIMARY DATABASE IS tmtst -> SHOW PARAMETER DB_UNIQUE_NAME > CONNECT IDENTIFIER IS tmtst. DGMGRL> EDIT DATABASE tmtst SET PROPERTY FastStartFailoverTarget='tmstby'. --> warning. DGMGRL> ENABLE FAST_START FAILOVER. prompt will not be returned! . DGMGRL> EDIT DATABASE tmstby SET PROPERTY FastStartFailoverTarget='tmtst'.Demo: Configure Observer #> dgmgrl DGMGRL> connect sys/xxx@tmtst Connected.

new primary is "tmstby" . ORA-01109: database not open Database dismounted. ------ duration 90 seconds! Performing switchover NOW.Demo: Switchover DGMGRL> SWITCHOVER TO tmstby. please wait... Operation requires shutdown of instance "tmtst" on database "tmtst" Shutting down instance "tmtst".. Database mounted. ORACLE instance started.. Operation requires shutdown of instance "tmstby" on database "tmstby" Shutting down instance "tmstby".. Database mounted. ORACLE instance shut down. Operation requires startup of instance "tmstby" on database "tmstby" Starting instance "tmstby". Operation requires startup of instance "tmtst" on database "tmtst" Starting instance "tmtst".. Switchover succeeded. ORA-01109: database not open Database dismounted. ORACLE instance started... ORACLE instance shut down...

current_scn .DB_UNIQUE_NAME. FS_FAILOVER_STATUS.Verify on both SELECT DATABASE_ROLE. PROTECTION_LEVEL. PROTECTION_MODE. FS_FAILOVER_THRESHOLD. FS_FAILOVER_OBSERVER_PRESENT. checkpoint_change#. SWITCHOVER_STATUS.STANDBY_BECAME_PRIMARY_SCN. FS_FAILOVER_OBSERVER_HOST FROM V$DATABASE / .STATUS. FS_FAILOVER_CURRENT_TARGET.

tmOCI.START_SERVICE('tmOCI. VALUE -----------------------------------------------tmtst_DGMGRL.za'. failover_type => 'SELECT'. failover_delay => 1).co.Client Failover Best Practices SQL> exec DBMS_SERVICE.vodacom.co.vodacom. SQL> exec DBMS_SERVICE.za . SQL> select value from v$parameter where name = 'service_names'.za '. network_name => 'tmOCI. aq_ha_notifications => true.vodacom.vodacom.za.za').CREATE_SERVICE ( service_name => 'tmOCI. failover_method => 'BASIC'.co. failover_retries => 180.co.co.vodacom.

za'). BEGIN SELECT DATABASE_ROLE INTO role FROM V$DATABASE.vodacom.co. ELSE DBMS_SERVICE.za'). END.STOP_SERVICE('tmOCI.vodacom. . END IF. IF role = 'PRIMARY' THEN DBMS_SERVICE.START_SERVICE('tmOCI.Client Failover Best Practices Configure startup trigger for service SQL> CREATE OR REPLACE TRIGGER manage_OCIservice after startup on database DECLARE role VARCHAR(30).co.

co.vodacom.Client Failover Best Practices Client tns entry Configuration TMOCI=(DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = prab03.co.za) (PORT = 1521)) (LOAD_BALANCE = yes)) (CONNECT_DATA= SERVICE_NAME=tmOCI)) ) .za) (PORT = 1521)) (ADDRESS = (PROTOCOL = TCP) (HOST = tvbs01.vodacom.

Active Data Guard 11g Investment in Improved Quality of Service .

Active Data Guard Begin with a Data Guard 11g physical standby database If redo apply is running. stop redo apply Open the standby database read-only Start redo apply .

Data Guard Broker & Enterprise Manager Data Guard Broker CLI Stop redo apply with the following command EDIT DATABASE ‘TMSTBY' SET STATE=‘APPLY-OFF’ Open standby read-only via SQL*Plus SQL> alter database open read only. Restart redo apply via broker CLI EDIT DATABASE ‘TMSTBY' SET STATE=‘APPLY-ON’ Oracle Enterprise Manager 10g Stop redo apply within Data Guard GUI Open standby in read-only mode in Advanced Startup Options Restart redo apply within Data Guard GUI .

g. grouping set queries and with clause queries .Supported Operations for Read Only When connected to an Active Data Guard standby database. read-only applications can perform/use: Selects Alter session / system Set role Lock table Call stored procedures DBlinks to write to remote databases Stored procedures to call remote procedures via DBlinks SET TRANSACTION READ ONLY for transaction level read consistency Complex queries e.

Meyer@vodacom.com .za http://martinmeyer.THANK YOU Thinus.co.blogspot.