Chapter 5. Data Guard and Flashback

There are three types of standby database available in the Enterprise edition of 11g Oracle: Logical, Snapshot, and Physical. This chapter will cover the differences between the standby types, implementation details, and testing/recovery scenarios using both Data Guard and Flashback technologies in tandem for stress testing, hot fixes, and data recovery. Oracle has made further improvements to Data Guard to facilitate the use of standbys for testing purposes—one of these is called Database States. It is a simplified method of turning off the data flow from one standby to another, giving the DBA total control over the process.

Note

Oracle Standard Edition, which doesn't include the automatically managed recovery capabilities found in Data Guard, can be used for some of the steps outlined in this chapter. The basic concepts are the same, all commands will be carried out with SQL*Plus and shell scripting to transport the archivelogs used for recovery. See...

Physical, snapshot, and logical standbys

A physical standby is a block-for-block copy of the primary using Redo Apply with different levels of protection against data loss, depending on desired performance and resource restrictions. A snapshot standby is almost identical to a standard physical standby except that it is a snapshot of the data at a point in time. This type of database was designed for performing various testing scenarios without affecting the production database.

A logical standby is a read-only copy of the primary (production database) where redo data from the primary is applied while the database is open, via a process called SQL Apply. Additional read/write schemas can be added to the logical standby while still protecting the primary information in read-only mode. Certain data types are not supported and some DDL is skipped during the SQL Apply process. Logical standbys can also be used for Rolling Upgrades, which is purported to be the smallest amount of downtime achievable...

Summary

As a DBA that has been investigating time and effort in the standby technology since Oracle Database version 8i, it has been interesting to see the improvements along the way. Physical standbys have proven standard from the very first version, but the older implementation required the DBA to create their own script to manually transfer the archived redo logs from the primary database to the standby. Since 10gR2, all standby technology has improved dramatically from the early versions. Redo Apply is now fully automated, resilient, and SSL-encrypted. SQL Apply has matured enough that a logical standby can be depended on if a DBA takes the time to follow the Oracle-recommended tuning steps.

In 10gR2, most of the scenarios that were previously highly detailed manual steps have been shortened to a single command using the Data Guard command-line utility in 11g. Oracle has extended the functionality of using Data Guard for other reasons than just disaster recovery with several optional...