Active Data Guard not only allows you to make the standby readable, but you can do so with minimal configuration changes on your client. You can point reporting applications at the standby directly, or you can create what is essentially a read service on the primary server that will act as a broker that routes workload based on the type of activity. When the application connects to one service, it writes to the local OLTP database, and when it connects to the other service, the queries get routed to the standby to fulfill the reporting requests. This is powerful functionality that makes it easy for shops to report from their OLTP data.

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

The downside is that you can't make any permanent changes to the standby, so you're stuck with the indexing and other configurations of the OLTP database. As anyone who has ever put a reporting database together knows, OLTP index requirements are rarely the same as reporting index requirements.

Plus, configuring Active Data Guard, at least on Windows, is no picnic. I spent weeks in e-mail, on the phone, and in online conference with Oracle reps trying to get Active Data Guard up and running. The directions given online are incomplete, and there's no guidance on troubleshooting at all. Had I been alone trying to set this up, it never would have happened.

That said, there's nothing in the Active Data Guard setup that couldn't be done by a wizard, and in fact a wizard will be coming in Grid Control 11g, according to Oracle. Built-in monitoring and alerts would also be an improvement. As it stands, you have to set up your own scripts and alerts to monitor whether your logs are being shipped and applied.

Caveats aside, Active Data Guard is a huge leap forward, and DBAs will love what it can do. After I got the standby up and running, it seemed to perform very well and did exactly what it's supposed to do. I could hit it with queries, write to it, and it would resync with the primary when I switched back. It's also easy to use. It takes just a single statement at the command line to switch between modes.

Real Application Testing
Real Application Testing, an option comprising Database Replay and SQL Performance Analyzer, is a new feature in Oracle Database 11g that allows you to capture a workload, replay it on the same system or a different one, and then compare the results. Database Replay will replay your workload exactly as it happened complete with concurrency and timing, allowing you to fully test system changes against your actual production workload. Thus, you can see the true impact of changes to the database (index changes, percentage free, table partitioning, and so on) before introducing those changes into production.

In my tests, Database Replay was easy to configure, and it performed exactly as expected. You have to learn just a couple simple concepts related to setting it up -- such as how to create the directory object in the database to capture the workload and how to start the replay from the command line -- but once you get past them, it's smooth sailing.

My test was a 50-user read/write mixed workload. In between tests, I deleted indexes from my tables so that I could see changes in the report numbers. As expected, dropping the indexes did increase the performance of the writes, while decreasing the performance of the reads. I was able to verify that the replay mechanism re-created all my threads and ran them flawlessly.