Fighting corruption

Oracle Database 11g puts just as much effort into monitoring and recovering from corruption as it puts into query performance. Automatic health monitoring is a really big feature in this category because it runs reactive checks or manual checks. Reactive checks get run when a critical error occurs. These checks can examine database structure, data block integrity, redo integrity, and other conditions. When Oracle runs these checks, it creates a report and quite often suggests fixes.

Automatic quarantine of corrupt undo segments is just plain cool. When Oracle discovers a corrupt undo tablespace, it will quarantine the segment and not allow future transactions to use it. This allows Oracle to contain the damage and keep it from spreading.

The Fast Analyze feature will cure a big headache for DBAs of very large databases. Fast Analyze allows you to scan for table-index corruption much faster than before. This is really important because much of this type of maintenance is done during scheduled maintenance windows, and if the analysis operation can't even complete during the window, then neither can the fix.

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.

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, 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.