Snapshot Standby
Data Guard is Oracle's technology for providing a transactionally complete standby database in case of disaster. Data Guard protects against all kinds of system and network failures, and it isn't constrained by location. The standby database can be in the same room or thousands of miles away. But like other fail-over solutions, including remote mirroring and local clustering, the standby is completely idle and unavailable while the primary is online.

The Bottom Line Oracle Database 11g Oracle, oracle.com Very Good  8.6 criteria score weight Manageability 9 25% Performance 8 25% Availability 9 20% Scalability 8 20% Value 9 10% Cost: Editions: Standard Edition One, $149 per user license (minimum of five users) and $4,995 per processor (maximum two sockets per server); Standard Edition, $300 per user license (minimum of five users) and $15,000 per CPU (maximum four sockets per server); Enterprise Edition, $800 per user license (minimum of 25 users) and $40,000 per CPU. Enterprise Edition options: Oracle Real Application Testing, $10,000 per processor or $200 per named user; Oracle Advanced Compression, $10,000 per processor or $200 per named user; Oracle Total Recall, $5,000 per processor or $100 per named user; Oracle Active Data Guard, $5,000 per processor or $100 per named user. Platforms: Linux x86, Linux Itanium, Sun Solaris, IBM AIX5L, HP-UX, Windows NT 4 or later Bottom Line: Oracle Database 11g will be welcome relief to DBAs responsible for testing changes against a production workload. The way that Data Guard and Real Application Testing work together is sheer poetry, and no doubt most shops will quickly come to rely on the combination. The automatic health checks will help DBAs sleep better, though they may initially be leery of the SQL tuning feature. Result Cache will be a big hit with advanced users, and Advanced Compression (data de-duplication) will reward the smart DBA who manages it carefully. About our Reviews and Scoring Methodology

A terrific new Data Guard feature, called Snapshot Standby, lets you put the standby database into a temporary read/write mode, allowing you to test database changes while still providing the original HA/DR protection. This feature alone could change the way companies manage best practices around database development, change control, benchmarking, application upgrades, and related tasks.

For example, say you need to make a change to a major stored procedure on your production database. The problem is that, without testing it against your production workload, you have no idea how much, if at all, the change will improve your system performance. Combining Snapshot Standby with Database Replay (see below), you can test limitless scenarios. All you have to do is record your production workload on the primary database, put your standby database into read/write mode, and implement the code changes on the standby. Then you can replay your workload on the standby and compare the performance counters from the replay with those from your initial capture.

When you put your standby into Snapshot Standby mode, it stops applying logs from the primary. (The logs are still sent across, they're just not applied.) When you've finished testing, you can put the standby back in read mode. The standby will then automatically discard all of your changes, return to the state it was in before you tested the new code, and apply the logs that are waiting to be applied. Your standby is never physically out of sync with the primary, only logically.

There are many other scenarios where a Snapshot Standby can come in handy, from troubleshooting production issues to index tuning to disk placement and partitioning. You can use Snapshot Standby to test backups and index reorgs while under heavy user loads as well. The possibilities are practically endless.

There's another practical purpose. One of the biggest problems for DBAs is keeping analysts, developers, and others out of the production system. They all have legitimate reasons for reading data out of the system, but for performance and compliance reasons, you'll typically want to limit their access as much as possible. Typically you'd put together another server for their use and keep it as in sync with the production database as you can, generally through backup/restore or replication. With Snapshot Standby, you can do it all in one system.

Active Data Guard
Like Snapshot Standby, Active Data Guard lets you have your standby and use it to. A new option introduced in Database 11g, Active Data Guard allows you to throw a standby instance into read mode to support real-time queries, solving one of the biggest issues businesses have with their OLTP databases: namely, how to separate OLTP and read activity while providing near-real-time reporting.