Oracle Active Data Guard Best Practices
Oracle Active Data Guard Best Practices
Larry M. Carpenter Distinguished Product Manager, Oracle USA Vinay Srihari Senior Manager, Oracle USA Active Data Guard Development Nagesh Konduru Senior DBA Manager Internet Services, Apple
Agenda
What is Active Data Guard? How do applications use it? A Real Life Experience. Whats New in 11.2?
Data Guard
Primary Database Physical Standby Database Open Read-Only Or in Snapshot Mode
Data availability and data protection for the Oracle Database Up to thirty standby databases in a single configuration Physical standby used for queries, reports, test, or backups
Production Database
Offload read-only queries to an up-to-date physical standby Perform fast incremental backups on a physical standby
Production Database
Some Examples
Using a Reader Farm for Read Only applications. Really ramping up. Using OBIEE with Active Data Guard Some Configuration required Developing for Active Data Guard with TopLink Getting a handle on your application Using Siebel with Active Data Guard A work in progress!
Readers
Readers
Production Database
Standby Databases
DR included *
Oracle BI EE Server must be configured to route all database modifications to the primary database Configure Oracle BI EE to:
Disable Oracle BI EE from creating temporary tables in the database. This prevents Oracle BI EE from issuing DML statements while connecting to the standby database. All scripts that modify database content must specify a primary database connection pool explicitly.
Running Oracle BI EE with Active Data Guard provides a highly scalable solution for off loading query work from the Production database See Key Best Practices at end for link to paper
TopLink Application Development and Active Data Guard New or existing applications built using Oracle TopLink can be configured to use Active Data Guard
Increase database capacity and reduce the load on the primary database server Improve performance for all transactions, both read/write and read-only workloads Increase the utilization of existing standby databases
Uses Read Only Service Requires an Additional Connection Pool See Key Best Practices at end for link to paper
Currently working on making Siebel CRM work transparently with Active Data Guard Like TopLink applications, the solution uses Services and Connection Pools for Read-Only and Read-Write. Writes are always directed to the Primary database Reads are directed to the Active Data Guard standby. Uses the new Service Level Agreement for Query Lag to route reads back to the Primary if the standby falls too far behind the Primary.
More on that capability later in the talk.
Read-Write
RW RO
User
Create/Update/Delete
Query
Read-Only
Active Standby
High Scalability
High Availability
Reader Farm
Apple
Our Requirements
Migrate from Data Guard Logical Standby to Active Data Guard (ADG) Reader Farm Easily scale out Reader Farm to handle peak load High Availability (zero outage) Real-time data changes to Reader Farm Offload reporting from online database Support all index and data types Ease of maintenance
App 1
ADG 2
ADG 3
L o a d B a l a n c e r
App 2
ASYNC
App 3
ADG 8
SYNC
ADG 9
App n
Standby DB
(Max Av ailability Mode)
Experience to share
No impact on Read-only queries on ADGs with simultaneous redo apply, and vice versa Real-time Apply now keeps pace with our load Guarantee of data consistency between Primary and ADG Standbys Large dataset changes on Primary doesnt impact Real-time data changes to Reader farm No restrictions on the types of indexes we can use
Best Practices
Balance out App Connections across multiple ADG Standbys Easy to add / remove Standbys from Load Balancer
Rigorously test Query performance on ADG reader farm in parallel with massive data changes on Primary Database Consistent execution plan of SQLs on Standbys generating object statistics on Primary Database by
Key Learning
Additional indexes cant be created on the ADG Standby exclusively for reader farm queries
Use Primary Database for all indexes Ensure no negative impact of these indexes to SQLs running on Primary Database
Apply data guard bundle patch (# 7676737) on 11g R1 AWR tool is not supported on ADG Standbys
Refer to Note 454848.1 for installing and using standby statspack Use statspack report (required patch #8801078)
SQL*Plus.
SQL> alter database recover managed standby database cancel; SQL> alter database open read only; SQL> alter database recover managed standby database using current logfile disconnect;
Thats it!
The Broker will jump in and automatically stop Redo Apply and the restart it after the open has completed.
And at switchover
If Active Data Guard in use at the target standby The original primary will be opened when it becomes a standby after the switchover!
Now you can let Active Data Guard check for you!
New session setting called STANDBY_MAX_DATA_DELAY NONE = queries will be executed regardless of the apply lag on that database. (Default) Non-zero = queries will be executed only if the apply lag is less than or equal to STANDBY_MAX_DATA_DELAY. If delay setting exceeded an error is returned
ORA-03172: STANDBY_MAX_DATA_DELAY of 2 seconds exceeded
Application then decides what to do. Zero = queries guaranteed to return the exact same result as if the query were issued on the primary database otherwise the ORA-03172 is returned Requires Maximum Availability and Real-Time Apply
Use a logon trigger to set the maximum delay whenever a user logs into the standby
SQL> connect sys/oracle@prod as sysdba Connected. SQL> CREATE OR REPLACE TRIGGER hr_logon_set_SLA_trigger 2 AFTER LOGON ON hr.schema 3 BEGIN 4 IF (SYS_CONTEXT('USERENV','DATABASE_ROLE') 5 IN ('PHYSICAL STANDBY')) 6 THEN 7 execute immediate ALTER SESSION SET STANDBY_MAX_DATA_DELAY=2; 8 END IF; 9 END; 10 / Trigger created.
To Sync or Not to Sync That is the question! What if you do not want to allow queries to occur until the standby is in sync with the Primary?
Another logon trigger with a new command
SQL> connect sys/oracle@prod as sysdba Connected. SQL> CREATE OR REPLACE TRIGGER hr_logon_sync_trigger 2 AFTER LOGON ON hr.schema 3 BEGIN 4 IF (SYS_CONTEXT('USERENV','DATABASE_ROLE') 5 IN ('PHYSICAL STANDBY')) 6 THEN 7 execute immediate ALTER SESSION SYNC WITH PRIMARY; 8 END IF; 9 END; 10 / Trigger created.
Which arrives via Redo Apply and can be used for DML
SQL> insert into REGIONS@write_ADG values (99, Active Data Guard'); 1 row created. SQL> commit;
Synonyms can help but can be a performance impact if you get it wrong
Commit complete.
Connect as the real user and assign the new user the required privileges and create the synonyms
SQL> connect hr/oracle@prod Connected. SQL> grant all on regions to hr_syn; Grant succeeded. SQL> create synonym r_regions for hr.regions; Synonym created. SQL> create synonym w_regions for hr.regions; Synonym created.
Failing to create the synonyms as the real user will cause problems later if the application connects to the Primary database.
More on that in a minute
As the New user, reading from R_REGIONS will go local but writing to W_REGIONS will go over the database link back to the Primary database. Yes, this is where you need to change your application to use the new synonym names.
I said it required some work.
Applications still log in as the Real user no matter what database they attach to. Applications always use the synonym names. A trigger determines what user they will be using.
SQL> CREATE OR REPLACE TRIGGER hr_logon_switch_schema_trigger 2 AFTER LOGON ON hr.schema 3 BEGIN 4 IF (SYS_CONTEXT('USERENV','DATABASE_ROLE') 5 IN ('PHYSICAL STANDBY')) 6 THEN 7 execute immediate 8 'alter session set current_schema = hr_syn'; 9 END IF; 10 END; 11 / Trigger created.
SQL> select * from r_regions where region_name='OpenWorld'; REGION_ID REGION_NAME ---------- ------------------------10 OpenWorld SQL> update w_regions set region_id=88 where region_name='OpenWorld'; 1 row updated. SQL> commit; Commit complete. SQL> select * from r_regions where region_name='OpenWorld'; REGION_ID REGION_NAME ---------- ------------------------88 OpenWorld
If the tables the application needs to write are writeonly like an auditing or report table.
You might be able to get away without any application changes to make it work. Also works if there are just a few reads
Nothing is more annoying or frightening to DBAs than when an application gets this error:
ORA-01578: ORACLE data block corrupted (file # 5, block # 140)
Bells ring, people shout, users get upset, DBAs take aspirin and try to fix the problem. No one really knows how long it will take to fix. Be nice if these kinds of errors fixed themselves. Wouldnt it be even nicer if the error was never seen?
Life isnt perfect But its getting better! Stuff happens to disks. If you have Active Data Guard, the app that would have gotten that error would never even see the error. What do you have to do to make this work?
Absolutely N O T H I N G ! Its automatic.
Consider - Were using Active Data Guard We corrupted a data block (#140) in the REGIONS table in the Examples data file (#5)
I am not going to show you how, sorry.
The application tries to read the REGIONS table. What do you think happens?
Absolutely N O T H I N G !
No ORA-01578!
SQL> select * from regions; REGION_ID ---------1 2 3 4 88 99 REGION_NAME ------------------------Europe Americas Asia Middle East and Africa OpenWorld Active Data Guard
Pretty cool huh? The same thing will happen if the block was corrupted on the Active Data Guard standby.
The corrupted block will be repaired from the Primary
High Availability Disaster Recovery Data Protection High Performance No Restrictions Return On Investment No Holds Barred!
Thank You!
Configuring Oracle Business Intelligence Enterprise Edition Server with Oracle Active Data Guard
http://www.oracle.com/technology/deploy/availability/pdf/maa_wp_11g_biee_activedataguard.pdf
search.oracle.com
Active Data Guard
or oracle.com
The preceding is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracles products remains at the sole discretion of Oracle.