Wednesday, June 12, 2013

Musings on Standby Database

It seem that every few months, there is a renewed discussion about whether you need to license your standby database, whether standby is Data Guard, whether Data Guard can be used in Oracle Data Server Standard Edition, whether we have to pay if we just apply redo at night, and similar.

Here is my response to that question:


Standby is standby.  It is a technique to support disaster recovery.  And it is still called Standby Database, not Data Guard, even now.

For a long time, in order to automate disaster recovery technique people have written scripts.  For Oracle Database Server, Laurence To and the Oracle SPG group assembled a number of the scripts back with Oracle7 and Oracle8 and released then as a feature of the Enterprise Edition called Data Guard that initially only consisted of the 'best practices' scripts.  The core feature was, and still is, available at no additional cost.

Data Guard has since progressed significantly and become more of a set of executables, rather than scripts.  But the primary purpose still is to automate the steps of syncronizing the standby and automating the switchover/failover.

Standby is standby.  With Oracle Database Server, it consists of two databases: the first or primary actively handling transactions and query requests; the 'standby' being available to take over the load if the primary fails.

Over the years, we in the industry have refined the term to distinguish between Cold and Hot standby, the difference being in how much effort is involved, and how quickly the standby environment is available for use.

A Cold Standby environment may have the software installed, but the environment does not use any CPU cycles to keeping the data in sync.  In general, that will require some sort of restore from backups.  Since the Cold Standby does not use CPU cycles, Oracle has not traditionally charged for it.

A Hot Standby environment keeps the data in sync fairly closely to the primary.  The more similar the standby environment needs to be to the primary at the data and configuration level, the more it will cost to do that, and the more complicated the sync method needs to be.  The Hot Standby does use CPU cycles, and therefore must be licensed the same way as the primary unless you have an exception within YOUR Oracle license contract.

Oracle database server - whether Express Edition, Standard Edition or Enterprise Edition - has the ability to perform crash and media recovery from intact redo log files.  Oracle's hot standby capability is simply continuous media recovery.  However that requires the redo information from the primary to be sent to the standby, when it is available and it requires the standby to apply the redo once it has arrived.

The Enterprise Edition feature called Data Guard is simply a 'guardian application' that detects when the redo information is available, extracts it, transmits it, and controls the application at the standby system(s).  What it does can also be done manually, or through your own scripts.  Indeed, in Standard Edition, DbVisit ( has created their own commercially available executable that does the same thing and more.

Data Guard has been enhanced to allow several 'levels' of similarity, from "minimum data loss" through "absolutely no loss permitted".  What used to be scripts is now compiled executables with many test points and with the ability to control the database server.

And the database kernel has been modified to allow the standby server to be opened in read-only while applying the redo information which may happen under the control of the Data Guard application.  This is called Active Data Guard, and it DOES require additional licenses.

Also check out the Software Investment Guide at

And remember: the final authority is Oracle, not me.  "I read it on the Internet" is a shoddy defense in a contract dispute and will likely NOT be accepted by the Judge in a Court of Law.

No comments: