Learning About Data Guard - Expert Consolidation in Oracle Database 12c - page 318

While not a problem per se, the fact that changes are not being applied to the standby database when it is in
read-only mode can extend the time needed for role transitions. This is because additional archived redo logs have
to be applied first, unless you are willing to incur data loss. Without an Active Data Guard license the database has to
be in mount state for managed recovery to work.
The standby database can be configured to be absolutely identical with the production database at any point
in time. You could theoretically go so far as to instruct your production database to shut down in case it cannot
get an acknowledgement from the standby database that a transaction has been committed. This is a little drastic
though and could potentially impact the availability of your service! This is why you read “theoretical” earlier in the
paragraph: very few sites operate Data Guard in this particular mode favoring protection over availability.
Processes related to Data Guard manage and monitor the standby database. Examples include shipping redo to
the standby databases, the automatic request of missing redo information after a network glitch, the fully transparent
addition of data files to the standby database and many more things we take for granted. You should compare how
comfortable today's Data Guard is relative to its early days!
A comprehensive set of dictionary views allow the DBA and management frameworks such as Oracle Enterprise
Manager to query the status of the Data Guard configuration and alert the DBA on shift should the standby database
fall too far behind.
If the unthinkable happens, Data Guard allows you to perform a role transition. Effectively the roles of the
primary and one of your standby databases are reversed during the process. The role transition can either be graceful
or forced. If what you suffered was a transient failure such as a power-cut, then it is possible to recover from the
situation without having to fully recreate the old primary. Sometimes however that cannot be avoided.
In addition to its primary function—preventing or shortening unplanned outages in your data center—Data
Guard standby databases can be used for many other purposes. A commonly used feature is an RMAN backup using
the standby database as a source. You read about the Active Data Guard option previously, it is very popular for
users that have reporting requirements and want to offload them to a standby database. Other uses are less useful
in the scope of database consolidation and will not be covered in this chapter, refer to the Data Guard Concepts and
Administration Guide for more information.

■ Note You can read more about backing up Oracle from a standby database in Chapter 11.

Standby databases: A historical perspective
When the standby feature was introduced in Oracle 7.3, maintaining a standby database was a highly manual process:
the database administrator was in charge of transferring archived redo logs generated on the primary database to the
standby site using utilities such as rcp , ftp , or rsync . This does not sound too bad, but bear in mind that the scripts
written to that effect had to work out which archived online redo logs to fetch in the current invocation, compared to
the last one. They also had to deal with network failures, low network bandwidth, needed to perform their own gap
resolution involving archive log sequence numbers, and many other things. In short, they were prone to error; close
monitoring was required and DBA intervention commonplace.
Once the logs were on the standby site, the standby database had to be placed in recovery mode via SQL*Plus
(usually within a script). The only possible action the administrator could take was to activate the standby database
in order for it to assume the primary role. This process, where the DBA was in charge of copying and applying
archived redo logs, was referred to as manual recovery.
Beginning with Oracle 8 i , the standby database uses managed recovery to stay in sync with the primary database.
This was a great step forward in usability! Using Oracle SQL*Net communication, the primary database ships changes
to the standby database, which are subsequently applied to the data files to keep the systems in sync. The application
of changes can be delayed to protect the system from the aforementioned user errors. A standby database can also be
used for reporting or backing up data; this removes some of the load from the primary database.