Oracle Active Data Guard-Technical Overview

Historical – but still found with surprising frequency in IT shops even today.

Active-Passive model – impossible to scale-out, many systems underutilized.

HA components are not application aware. Difficult or impossible to provide optimal data protection and availability because third party components are not able to take advantage of native features of a given application.

The customer becomes the systems integrator – many third party components, more complicated and costly to deploy and support. At best they address unplanned downtime – they have limited functionality for addressing planned downtime – e.g. system upgrades, database upgrades, application upgrades.

Unable to minimize planned downtime

Oracle Database High Availability is fundamentally different from traditional third party solutions implemented external to Oracle.

The traditional approach is to monitor at a physical bits & bytes level. For example, storage remote-mirroring replicates all writes to every file. Cold cluster failover monitors against server failure – requiring idle servers and a cold restart at failover time. These are just two examples – the list goes on. They all share the same shortcoming – they have no internal knowledge of the Oracle database or the very transactions that they are attempting to protect.

Oracle High Availability capabilities are integrated within the Oracle Database, enabling intimate knowledge of the transactions and data being protected.

This enables:

• Superior protection against data corruptions
• Faster recovery from any outage
• Zero or minimal downtime for planned maintenance.
• And the ability to utilize your investment in systems and software for productive purposes at all times

Data Availability & Data Protection solution for Oracle

Automates the creation and maintenance of one or more synchronized copies (standby) of the production (or primary) database

Best Data Protection – Continuous Data Validation at the Standby Database

If the primary database becomes unavailable, a standby database can easily assume the primary role

Addresses both planned and unplanned downtime

Feature of Oracle Database Enterprise Edition (EE)
Basic capability included at no extra cost
Primary and standby databases need to be licensed EE
Active Data Guard is extra license option –available from Oracle Database 11g onward

Lets look a bit closer at Data Guard Architecture.

1. Make point that Data Guard ships recovery data (redo) directly from memory to the standby – either SYNC (zero data loss) or ASYNC.

2. Data Guard redo apply will validate all redo before applying to the Oracle Database. The Oracle Database at the standby is hot and up-to-date, ready to assume the production role if needed.

1+2 provide a high degree of isolation between primary and standby. Corruption does not propagate.

3. Oracle primary merrily goes about its way writing to its local data files. None of these writes, nor any other write that occurs at the primary database (control files, archive log files, undo, etc) is transmitted to the standby – resulting in very efficient network utilization and very low, if any, primary database overhead when running Data Guard in asynchronous mode.

4. And because the network or standby database may experience outages, Data Guard automatically resynchronizes the standby with the primary.

Data Guard Redo Apply (physical standby) is very efficient, and thus very fast. Data Guard is the DR solution built to keep pace with Exadata Storage and the Oracle Sun Database Machine. We have benchmarked standby apply performance up to 2 TB/hour uncompressed, and 5 TB/hour compressed.

Data Guard is foremost about Data Protection, but it is also about High Availability – making sure that data is available for applications regardless of events that can impact the primary database, the data center it is in, the building, campus, or geographic region where it is located.

Data Guard provides an extensive set of capabilities for HA/DR that have evolved and matured over many Oracle Database releases.

Oracle Database 11g changed the way we think about standby databases with the introduction of Active Data Guard.

This is the traditional way of thinking about a standby database, as a failover target should the primary database fail.
All processing happens at the primary.
If we want the physical standby database to always be up-to-date and ready for failover, you are not able to open the standby for user access.

Active Data Guard changes things dramatically. Active Data Guard enables the standby database to be open read-only while it continuously applies updates received from its primary database. Reporting, ad-hoc queries, any read-only transaction, can be offloaded from the primary database to the standby.

You can also offload fast incremental backups from the primary database to an active standby.

And new in Oracle Database 11.2, the active standby is used to automatically repair block corruptions detected at the primary database, transparent to the user and application (and vica versa)

Active Data Guard is a New Oracle Database 11g capability that builds upon Data Guard
Physical standby open read-only while changes applied from primary database
RMAN fast incremental backups on physical standby using Block Change Tracking – 20x faster than traditional incrementals
Auto-repair corrupted data blocks (11.2)
Query SLA on standby database (11.2)

Benefits
Improves primary database performance by offloading processing to standby
Makes productive use of existing physical standby databases

Licensing
Packaged as a separate database Option for Oracle Enterprise Edition
Requires licensing of the production database and all the physical standbys that are used for any of the above capabilities

The second reason to use Active Data Guard is because its easy to guarantee the desired quality of service for standby queries.

One of the largest concerns for using a standby to offload queries is the management effort required to make sure the standby database is up to date. This can be challenging because the standby database may be located at a remote location. Network problems or other issues impacting connectivity between the primary and standby database can cause the standby database to fall behind the primary. The standby database may also detect a corruption in the incoming redo stream and automatically stop apply – again causing the standby database to fall behind the primary. The usual expectation is that queries always return current results. But how do you guarantee this when you offload queries to a remote replica? And the definition of stale (or how far the standby can lag behind its primary database) can be different from one application to the next.

Active Data Guard 11g Release 2 has the ability to automatically enforce service level objectives for standby data lag.

You establish your service level for maximum data lag between primary and standby – anything from zero to n seconds – and Data Guard will enforce it.

Fast, Scalable, Easy

Details of 11g R2 feature:

STANDBY_MAX_DATA_DELAY
A session parameter
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 the active standby.
Queries return error message if the limit is exceeded
ORA-3172 STANDBY_MAX_DATA_DELAY has been exceeded
Guarantees that queries will not return a result that violates service level agreements
Ignored for the SYS user

STANDBY_MAX_DATA_DELAY can be set to ‘n’ seconds or zero

There are use cases having zero tolerance for any lag
e.g. financial transactions, inventory transactions
A query on the standby database must return the same result as if it was executed on the primary database

Enforce by setting STANDBY_MAX_DATA_DELAY to 0
A query does not execute until the ‘query scn’ on the standby database has advanced to a value equal to that of the ‘current scn’ on the primary database at the time the query was issued
If result is not be returned within 200ms, query will return an ORA-3172
Requires SYNC redo transport, real-time apply, and Maximum Availability or Maximum Protection modes

Shows the reductions in failover time as new technologies were introduced.

Pre-Data Guard
Clock is ticking while the problem is identified, notifications are sent, and DBAs respond
Resolution involved custom scripts and complex procedures

Data Guard Fast Start Failover
Observer identifies the problem (primary not available),
responds appropriately (failover or not depending upon conditions),
and resolves the outage in under two minutes (if failover will not result in data loss)
Major improvement in availability

Database failover is fast, at Amazon.com . . .
Database failover completes in 10 seconds
Total time to redirect clients to new primary database is less than 2 minutes

© 2010, www.oracledatabase12g.com. 版权所有.文章允许转载,但必须以链接方式注明源地址,否则追究法律责任.

相关文章 | Related posts:

1. Make Money with Active Data Guard
2. Best Practices for Automatic Failover Using Oracle Data Guard 10g Release 2
3. Script to Collect Data Guard Diagnostic Information
4. Oracle Database 11gr1/10gr2 Automatic Storage Management Overview and Technical Best Practices
5. Oracle Data Integrator 11g Product Overview and New Features
6. ACFS Technical Overview and Deployment Guide
7. Introduction to Oracle GoldenGate: An Introduction to High Availability Solutions & Real-Time Data Integration
8. Migrating to RAC using Data Guard
9. Oracle Database 11g: High Availability Student Guide
10. Active Session History (ASH) performed an emergency flush