Oracle Standby Database Concept – Quick Look

Standby database was introduced to deploy strong disaster recovery concept using Dataguard. Dataguard is a most advanced version of Oracle standby database. First, we need to quickly look at what is Oracle standby database.

A standby database, as the name implies, is a copy of a functioning database, kept ready to be used in lieu of the latter for availability during disasters and system/database failures when the functioning primary database has crashed and is unavailable. Generally, only the production database is cloned; it is referred to as secondary or the target database. The mechanics for implementing a standby database have been officially available from Oracle 7. However, with every release of Oracle, the standby database feature has been made more robust and automatic. Irrespective of the version, every standby database implementation follows certain well-defined steps.

I have referred to this standby database implementation and development provided within Oracle as the regular and conventional standby deployment as opposed to a custom approach outlined subsequently. Based on the version, the actual method for performing certain steps may differ. However, the overall objective remains the same. Refer to your version-specific Oracle documentation set for complete details on configuring standby databases, how they work, how they enhance availability, and what pertinent issues you need to be aware of prior to deciding to implement standby databases. Also, I have elaborated on some new standby database features available in Oracle version like Dataguard.

Oracle Standby feature has been introduced within Oracle 7.3, therefore the prior version of Oracle doesn’t contain standby database feature. Oracle standby feature is absolutely depending on redo changes and archive log. Standby database feature requires inherent integrity checks for archive log shipping and redo log with control file changes.

The transactions occurring in the primary database are applied to the standby database via archive log. Archive logs are a copy of redo logs. As transactions get written to the online redo logs after commit proceeding, the redo logs get full, switch, and are archived (copied) by arch background process to respective destination. Thus, both the primary and standby databases need to be in archive log mode. The archived logs are copied across the network to the remote standby server (either manually or automatic). The standby database is continuously in a state of recovery mode. All archived logs copied over are applied to the standby database to allow it to catch up with the primary database content. The standby database is always behind the primary database for few seconds. Even if all the archived logs generated thus far have been already applied, it still lags behind because transactions are currently being written to the primary’s online redo-logs and these can be applied only after they are archived and copied over. There are some new features introduced to prevent this kind of scenario from Oracle 11g and 12c.