Make Money with Active Data Guard

Active Data Guard with Oracle Database 11g creates entirely new opportunities for I.T organizations that extend far beyond disaster recovery.

This presentation discusses how Active Data Guard, a new database option available with Oracle Database 11g will help I.T. organizations meet the challenge of enhancing the Quality of Service offered to their customers while at the same time reducing complexity and cost.

Forrester Research, “Six Years After 9/11, Most Firms Are Not Ready For Another Disaster”, Sep 11, 2007

“… IT operations professionals are crossing their fingers and hoping a disaster won’t hit, while business executives have no idea how vulnerable they really are to significant losses . . .” (survey of 189 enterprises)

Taneja Group – “New Database Technologies Usher in New Approaches to Data Protection and Disaster Recovery”, Sep 2007
“A new class of intelligent data protection and disaster recovery approaches has emerged that understand the underlying data structures … they significantly speed recovery of data and ensure better efficiency than simply protecting data at the bits and bytes level.”

Enterprise Strategy Group – “Double Up with Database Data Protection and Disaster Recovery with Oracle Data Guard”, Nov 2006
“We utilize EMC Symmetrix and we’ve got bandwidth, we could use SRDF, but for this critical database we went with Data Guard”
– David Willen, CTO, BarnesandNoble.com

Illustrates the importance of having a second engine that is “hot” and ready to assume the production role.

The notion of hot is very important – because you have very little time for the second engine to start before there is significant negative impact to the business.

Building an HA solution is not hard. You put together a bunch of redundant components – and there you have your HA solution. Traditionally, to build an HA solution around their mission critical database, customers had to integrate such solutions from various 3rd party providers. But as their business grew, customers realized that this approach has a lot of problems. Firstly – it is hard to scale this model. Secondly – the redundant components may be there, but they don’t do any useful work, so overall resource utilization suffers. Finally – it is also hard to build smart, intelligent solutions on top of such architecture – e.g. to easily detect and recover from human errors, to minimize downtime during planned maintenance activities, etc.

Challenges
Array Based Remote-mirroring

• Zero knowledge of the application or data
• Must mirror everything (all writes to all files)
• SYNC mode makes every DB write a synchronous write
• Mirrors problems just as effectively as it mirrors data
• The application (target Oracle DB) is off while mirroring is on
• Target volumes can not be used while mirroring is active
• Difficult to test – not sure if it will work when needed
• Vendor lock-in to costly storage subsystems
• Distance constraints

Limited Protection, Expensive, Low Return on Investment

This slide makes it clear why all Data Guard need to replicate to the standby site is the recovery information. It is because Oracle executes the apply process on the standby database. The standby is in a continuous state of recovery, Oracle is mounted, Oracle validation prevents corruptions from being applied to the standby. We don’t need to mirror all writes because Oracle is smart enough to keep the databases synchronized using only redo data.

So – lets take a look at an actual disaster – what I call your average joe disaster. We aren’t talking about fires, floods, hurricanes, or earthquakes. A simple hardware failure somewhere in the I/O path caused the database to become corrupt. Oracle thinks everything is fine – until it tries to access the corrupt data. When such corruptions impact key information or become widespread – they can bring down the entire database – as was the situation with this customer, reported in an actual service request (TAR) to Oracle support.

So with traditional use of a physical standby, the production database is fully protected, but its also doing all the heavy production lifting.

We have seen customers use Oracle Streams, or Oracle Data Guard SQL Apply, also known as logical standby, or even 3rd party replication products – to offload primary databases of ad-hoc queries and reporting in an attempt to solve a dilemma long understood by I.T. The unpredictable nature of these long-running operations and the system resources they consume make it very hard to guarantee consistent high levels of service for users executing business transactions. We have also observed that frequently, all that is required to offload queries and reporting to achieve Quality of Service objectives is an up-to-date, read-only replica of the OLTP system.

While these traditional approaches may work – they have other limitations (unsupported data types, DDL restrictions, performance . . .) and are overkill if the only requirement is read-only access to an up-to-date replica.

Our philosophy is to address customer requirements as simply as possible to make operation easy and reliable. Customers have been asking for a simple solution to offloading read-only queries and reporting. The Oracle Active Data Guard Option using a physical standby database in Oracle Database 11g does just that.

Active Data Guard is an evolution of Data Guard technology. It includes innovative technology to enable customers to use a synchronized replica of their production database to off-load ad-hoc queries, reporting, and other long-running operations from the production instance, and thereby achieve predictable, consistent performance for their critical business transactions.

Active Data Guard enables a physical standby database – either RAC or single-instance – to simultaneously be open read-only while redo apply is active. All queries and reports reading from the standby database return up-to-date results. The documentation describes this feature as “Real-time Query”, with real-time being defined as being able to query data on the standby within single-digit seconds of the transaction having committed on the production database. Any operation that requires read-only access can now be redirected to the replica, protecting the performance of the production database.

Compared to traditional methods for offloading ad-hoc queries and reports, an Active Data Guard replica:

Is Simple and Reliable
Very little management complexity, fewer moving parts – less to break, less to tune
Completely transparent – no data type restrictions – no production database changes required to implement
Easy to use with a simple management interface

Has Very High Performance
You completely avoid the performance penalty on the primary and the reporting replica that accompanies traditional replication solutions

Eliminates Compromise
Reporting replica is up-to-date at all times – something that is not always possible for demanding applications using traditional replication technologies.

Reduces Cost
An Active Data Guard reporting replica can also serve disaster recovery purposes to eliminate the need for additional storage and servers

Active Data Guard includes a second feature to help offload work from production databases – support for RMAN block-change tracking on a physical standby database.

A Data Guard standby database has always been able to offload backups from the production database. But new with Active Data Guard is the ability to support RMAN block change tracking on the standby database. This enables very fast incremental backups by only being concerned with changed blocks and eliminating full table scans. Tests have shown that compared to traditional incremental backups, using block-change tracking, even on a moderately active database, can result in incremental backups that complete as much as 20x faster.

We think this will provide customers the motivation to move backups off their production database – or even to use their Data Guard standby database for this purpose instead of purchasing additional storage required using snap-mirror technologies.

If there is anything we can do to offload work from the production database – we want to do it.

This makes a Snapshot Standby an ideal way of assessing the impact of application or database changes before they are placed into production. The replica is completely up-to-date with production as of the time in was converted to a Snapshot Standby. If you go to the additional length to have the replica hardware be the same as production – you have your ideal test system – one that is an identical copy of the primary database. When testing is complete – a single command will discard the changes made to the standby while open read-write and then apply all transactions that have been received from the production database to return it to a synchronized state.

Now if you step back for a second – you can start to see how all of these capabilities build upon each other – and because they all use the same common infrastructure, they generate significant dividends for Oracle customers.

The same replica maintained by Active Data Guard to improve the quality of service of the production database, can be used during non-peak hours as a test system using Snapshot Standby, and at all times can also serve as a disaster recovery solution. So rather than maintain multiple replicas using different technologies to address different requirements – use a common infrastructure and single replica with one management interface to achieve the same objectives.

Easier, less expensive, more functional – its hard to beat.

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

相关文章 | Related posts:

1. Script to Collect Data Guard Diagnostic Information
2. Migrating to RAC using Data Guard
3. How to Make Use of Oracle's Data Compression with Materialized Views.
4. Active Session History (ASH) performed an emergency flush
5. How to make BBED(Oracle Block Brower and EDitor Tool) on Unix/Linux/Windows
6. How we created a clone database from the datafiles image copies of a physical standby database
7. Oracle Database 11g: High Availability Student Guide
8. RMAN 11G : Data Recovery Advisor – RMAN command line example