11g Active Data Guard More than just DR.Gavin Soorma Senior Oracle DBA,Bankwest

DR Sites of today Lots of $$$ spent on disaster recovery (DR) systems that sit idle waiting for a disaster to occur Investment on hardware, state of the art data centres, software licenses, maintenance costs DR sites very often have identical capacity as the production site idle and unused capacity in most casesTraditionally resource intensive activities like reporting and backups were not offloaded to the standby siteStandby databases using Data Guard are synchronized replicas of production databases so why not use them?Oracle 11g Active Data Guard changes that enabling us to optimize Return On Investment from the DR or Standby sites

Life before 11g Active Data GuardPrior to Oracle 11g, read access to standby database required Redo Apply to be stopped.Queries on read only standby databases could potentially return stale results as changes occurring on the primary database are not applied.This backlog of unapplied redo data could potentially increase failover timesTraditional reporting sites based on MV'sMV's need administrative overhead for setup and maintenance.MV refresh times can be lengthy for complex queries - while complete refresh happens no rows returned for queries

Data Guard OverviewMRPRFSStandbyRedo LogsARCHArchived Redo LogsPrimaryDatabaseTransactionsLGWROnline Redo LogsARCHOracle NetData Guard BrokerArchived Redo LogsStandby Database

What is Active Data Guard?Introduced in 11g Release 1 Available in the database server Enterprise Edition as an additional license optionReal time replica of a production database which is open in read only mode while changes transmitted from the primary database are being simultaneously applied to it.Applies to physical and not logical standby databaseCan offload reporting, queries and fast incremental backups from the primary site to the standby site improving the performance and adding to the scalability of the primary sitePerforms its primary Data Guard objective of preventing data loss and downtime due to data corruptions, database and site failures, human error, or natural disaster.

Active Data Guard UsageRedirect read only portions of application to Standby site - online order and shipping application will have a read only component where the catalogue is searched by customer before the shopping cart activity commencesRead mostly applications can use redirection to Active DG siteRedirect complex adhoc queries like year end or month end reports to DR site Redirect Business Intelligence tools like Discoverer to the standby siteUse optimized incremental backups with RMAN block change tracking in 11g now on standby sites to make backups up to 20 times fasterExtends basic Data guard functionality switchovers/failoversData Guard is free - Active Data Guard is a licensed option

Active Data Guard Not just for protection

Offload fast incremental backups to an Active Data Guard StandbyBlock change tracking eliminates full scansIncremental backups complete 20x faster (8.3 min vs 2.8 hrs)In 11g, block change tracking file can be created on physical standbyMinimal overhead on standby database less than 3%

11g Active Data GuardAuto block ProtectionPrimary DatabaseActive Standby DatabaseRead/Write UsersRead Only Users/Reporting ApplicationsFast IncrementalBackups

Increasing Read-Only ScalabilityActive Data GuardReader Farm

Primary Database(Two Node RAC Cluster)

Active Data Guard Operations PermittedWhat can we do?

Issue SELECT statements Issue complex queries such as grouping SET queries and WITH clause queriesCall stored proceduresUse database links to write to remote databasesUse stored procedures to call remote procedures via dblinks

Active Data Guard Operations DisallowedWhat we cannot do .

Any DML excluding SELECT Any DDL So no additional indexes allowed AWR tool not supported for Active DG standbyRead note 454848.1 for installing and using Standby statspack

What operations can be performed?

SQL> select getsal('KING') from dual;

GETSAL('KING')-------------- 5000

SQL> select getsal_remote ('KING') from dual; -- getsal_remote is synonym for getsal@dblink

GETSAL_REMOTE('KING')--------------------- 5000

SQL> create table mytab 2 (col_a number);create table mytab*ERROR at line 1:ORA-00604: error occurred at recursive SQL level 1ORA-16000: database open for read-only access

SQL> delete scott.emp;delete scott.emp *ERROR at line 1:ORA-16000: database open for read-only access

What operations can be performed?SQL> select database_role from v$database;

DATABASE_ROLE----------------PHYSICAL STANDBY

SQL> select open_mode from v$database;

OPEN_MODE--------------------READ ONLY WITH APPLY

SQL> INSERT INTO dept@mylink --remote database 2 VALUES 3 (50,'I.T','HOUSTON');

1 row created.

SQL> commit;

Commit complete.

SQL> UPDATE dept@mylink -- remote database 2 SET LOC='DALLAS' 3 WHERE LOC='HOUSTON';

1 row updated.

Enabling Active Data GuardVia SQL*PLUS ..If the standby database is not running (note in 11g, STARTUP command will start standby in read-only mode)

SQL> STARTUP

SQL> RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

If standby database is running and managed recovery in operation

SQL> RECOVER MANAGED STANDBY DATABASE CANCEL;

SQL> ALTER DATABASE OPEN READ ONLY;

SQL> RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

Enabling Active Data Guard Via the Data Guard Broker

DGMGRL> startupDGMGRL> edit database STDBY set state=APPLY_ON

In case standby database is already in managed recovery mode

Stop redo apply

DGMGRL> edit database STDBY set state=APPLY-OFF

Using SQL*PLUS open the database in read only

SQL> ALTER DATABASE OPEN READ ONLY;

Restart redo apply

DGMGRL> edit database STDBY set state=APPLY-ON

Dont do this at home (or in the office)

SQL> select dbms_rowid.ROWID_BLOCK_NUMBER(rowid) from emp;

DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID)------------------------------------ 188

dd if=/dev/null of=/u02/oradata/apex/monitor_data01.dbf bs=8192 conv=notrunc seek=188 ./corrupt.sh0+0 records in0+0 records out

SQL> alter system flush buffer_cache;

System altered.

SQL> select * from monitor.emp;select * from monitor.emp *ERROR at line 1:ORA-01578: ORACLE data block corrupted (file # 5, block # 188)ORA-01110: data file 5: '/u02/oradata/apex/monitor_data01.dbf'

Active Data Guard Block RecoveryAutomatically repair block corruptions online

Primary repaired from standby and vice-versa

Corrupt block relative dba: 0x018005da (file 5, block 188)Fractured block found during user buffer readData in bad block: type: 6 format: 2 rdba: 0x018005da last change scn: 0x0000.001b3ebf seq: 0x2 flg: 0x04 spare1: 0x0 spare2: 0x0 spare3: 0x0 consistency value in tail: 0x00000000 check value in block header: 0x1b14 computed block checksum: 0xb2a8Reading datafile '/u01/oracle/testdr01.dbf' for corruption at rdba: 0x018005da (file 5, block 188)Reread (file 5, block 188) found same corrupt dataRequesting Auto BMR for (file# 5, block# 188)Waiting Auto BMR response for (file# 5, block# 188)Auto BMR successful

Guaranteed SLAs for read-only usersActive Data Guard service level agreements (SLA) can be implemented using the session parameter, STANDBY_MAX_DATA_DELAYNew with Data Guard 11g Release 2 Specifies a limit for the amount of time (in seconds) allowed to elapse between when changes are committed on the primary and when they can be queried on an active standby database The active standby will return an ORA-3172 error code if the limit is exceeded. Applications can handle this error and redirect queries to the primary database

Guaranteed SLAs for read-only usersSQL> ALTER SESSION SET STANDBY_MAX_DATA_DELAY=0;ERROR:ORA-03174: STANDBY_MAX_DATA_DELAY does not apply to SYS users

SQL> conn sh/shConnected.

SQL> ALTER SESSION SET STANDBY_MAX_DATA_DELAY=0;

Session altered.

ON PRIMARY

SQL> update mysales set prod_id=2;

ON STANDBY

SQL> select distinct prod_id from mysales;

ERROR at line 1:ORA-03172: STANDBY_MAX_DATA_DELAY of 0 seconds exceeded

SQL> /

PROD_ID---------- 1 >>>> QUERY REDIRECTED TO PRIMARY

Testing Active Data GuardSQL> select database_role from v$database;

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

SQL> update mysales set prod_id=1;

918843 rows updated.

SQL> commit;

Commit complete.

SQL> select to_char(sysdate,'DD-MON-YYYY HH24:MI:SS') from dual;

TO_CHAR(SYSDATE,'DD---------------------04-NOV-2009 10:26:12

SQL> select distinct prod_id from mysales;

PROD_ID---------- 1

Testing Active Data GuardSQL> select database_role from v$database;

DATABASE_ROLE----------------PHYSICAL STANDBY

SQL> conn sh/shConnected.

SQL> select to_char(sysdate,'DD-MON-YYYY HH24:MI:SS') from dual;

TO_CHAR(SYSDATE,'DD---------------------04-NOV-2009 10:26:31

SQL> select distinct prod_id from mysales;

PROD_ID---------- 1

Monitoring Active Data GuardGoal - How far behind does data lag on Standby relative to the primary database?Focus areasDetermine Transport lagDetermine Apply lagDetermine Query SCN or time compare CURRENT_SCN on Primary and Standby databases

Guarantees a transactionally consistent view of data Query SCN on Standby is equivalent to CURRENT SCN on primaryRedo Transport considerations synchronous vs. asynchronousView V$DATAGUARD_STATS to monitor apply lag as well as transport lag

Monitoring Active Data GuardSQL> select value from v$dataguard_stats where name='apply lag';

VALUE----------------------------------------------------------------+00 00:00:01

SQL> select value from v$dataguard_stats where name='transport lag';

VALUE----------------------------------------------------------------+00 00:00:00

Query V$DATAGUARD_STATS view to determine both transport lag aswell as apply lag

Query V$DATABASE on both primary as well as standby database to obtain CURRENT_SCN

11g Snapshot StandbyActive Dataguard

Read Only - redo from primary received and applied

Snapshot Standby

Read Write - redo from primary received but not applied

Redo applied when snapshot standby database is converted back to physical standby

Note: Both Active Data Guard and Snapshot standby require a physical standby database in place as opposed to a logical standby database

Snapshot Standby for Test environmentsTwo steps vs. 15 in 10g Release 2Convert Physical Standby to Snapshot Standby and open for read/writes by testing applicationsALTER DATABASE CONVERT TO SNAPSHOT STANDBY;Discard testing writes and resync with primary by applying logs ALTER DATABASE CONVERT TO PHYSICAL STANDBY;Preserves zero data loss as wellBut no real time query (Active Data Guard) or fast failover

Physical Standby Apply LogsSnapshot Standby Perform TestingOpen DatabaseBack out ChangesContinuous Redo Shippingwhile operating in Snapshot Standby mode

Snapshot Standby and Change Control

Combined with Real Application Testing to provide a simple way to test and maintain protection at the same timeEliminate guesswork as performance test results are realistic and reliable since using a replica of production dataUnderstand the impact as well as extent of system resource consumption on production data during performance testing Change assurance - Introduce changes with confidenceSnapshot standby provides simultaneous disaster recovery capabilities as well as QUALITY ASSURANCE capabilities

Combining with Real Application TestingWorkloadCapture

WorkloadPre-process

Analysis& ReportingWorkloadReplay

Primary DatabaseSnapshot StandbyPhysical StandbyArchive Logs

Snapshot Standby some considerationsCan only be used with a physical standby database and not logical standby databaseNeeds flashback logging to be enabled - creates a implicit guaranteed restore point internally to which the snapshot standby is flashed back to convert back to physical standbyThe name of this guaranteed restore points begins with SNAPSHOT_STANDBY_REQUIRED_* Need to consider how long the standby database operates in snapshot standby modeFirst have to rewind the database to the guaranteed restore point using flashback logs - then changes generated on the primary when standby was in snapshot standby mode have to be applied by rolling forward and applying archive logs Note switchover or failover cannot be performed to a snapshot standby database

Final Thoughts .Organisations are not fully utilising the investment in hardware and resources on disaster recovery sitesNow in Oracle 11g, it is possible to increase the return on such investment by employing new features like Active Data Guard and Snapshot Standby databaseStandby databases are not just for disaster recoveryOffload resource intensive operations like reporting and backups to standby sitesUse the standby database to perform testing and QA via the Snapshot Database technologyNeed to weigh benefits vs. perceived additional licensing costs

Thanks for attending!!

Ahttp://gavinsoorma.wordpress.com

Tel: 0417713124

gavin.soorma@bankwest.com.au