There are a number of new features in Oracle 11g related to standby database such as lost-write detection, compression of archived redo logs, real-time query capabilities on physical standby databases, and snapshot databases.
Lost-writes occur when the IO subsystem actually does not write the data to the physical medium. This is possible because in most cases Oracle will make a write request to the IO subsystem and the IO subsystem will write the data and report that the write was successful. In fact, the IO subsystem may actually report that the write was complete when in fact the write is only queued to be written. Since the write is only queued and not actually written to disk (yet) there is a potential for data loss since power loss can be experienced before the write actually happens. This is rare, but possible.
A physical standby database in Oracle 11g can detect such corruption. When the physical standby database detects the lost write, it will generate an error in the alert log of the standby database and managed recovery will be halted. Having done so, you can switch over to the physical standby database, making it the primary database. You can then re-create the primary database. Before you failed over to your standby you should consider the alternative options including RMAN block-level recoveries which can be done online with a minimum of fuss.
Oracle will now compress archived redo logs when they are sent to a standby database site for gap resolution. This can significantly reduce the bandwidth required to get standby databases "caught up" in the case of gap resolution. This will also reduce disk storage requirements for archived redo logs.
You can now query a physical standby database at the same time that the standby database is applying redo. This makes the physical standby database much more cost-effective and useful than before. You do not need to do anything special to enable this feature. Simply start redo apply as you normally would, then open the standby database in read-only mode.
The new snapshot database feature in Oracle 11g provides the ability to open a physical standby database, and change data and structures in that database, all while continuing to collect (but not apply) redo. The command ALTER DATABASE CONVERT TO SNAPSHOT STANDBY is used to convert the physical standby to a snapshot standby database. This command will cause Oracle to create a guaranteed restore point. Later when the ALTER DATABASE CONVERT TO PHYSICAL STANDBY command is issued, the database will be flashed back to the guaranteed restore point. After this operation is complete, you can initiate redo application on the standby database just as nothing ever happened.
Once the standby database has been converted to a snapshot database, you open the database for normal read/write operations. For all practical purposes, that database is a different database than the primary database. While the database is open, you can do pretty much whatever you like. Once you are done, simply revert back and wait for it to catch up on redo application.
Be aware of the use of Flashback Database when returning the snapshot database to a standby database. If, while the snapshot database is open, you perform any operation that could prevent flashback operations from rolling back the database, then you will not be able to return the snapshot database to a standby database.
The power of a snapshot database can be far reaching. It can be used to replay workload with Real Application Testing features, you can use it with flashback database to research data quality issues, you can create duplicate databases with it using RMAN, the possibilities are endless. Once you are done, then you simply revert back to your standby configuration. Flashback Standby Database can more than justify the additional cost of such an environment.