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

Role transitions are slightly different, depending on the type of standby database (logical or physical) to assume
the primary role, and each database administrator should be familiar with the steps necessary to carry out the
different role transitions. Regular disaster recovery tests should be performed to ensure that the standby database(s)
and the entire dependent infrastructure, such as load balancers and application servers, can execute the workload in
the disaster recovery center. Easily accessible documentation is important, helping the more junior team members
perform this task and keep a cool head during a crisis.

An in-depth view on Data Guard terminology
You just read that Oracle Data Guard relies on redo to be shipped to the standby databases to keep the databases
in sync. Certain operations on the primary database can be executed with the nologging clause, which has
consequences for the standby database. Any nologging operation on the source does not generate sufficient redo to
update the destination. If you were to switch over and there had been nologging operations on the primary you would
end up with a corrupt database. If the database is in force-logging mode then it will ignore nologging statements,
making redo generation and transport a lot more reliable. Note that it requires elevated privileges to change the force
logging mode.
Standby redo logs (SRL) have briefly been discussed earlier. They are very important components of every
database in the Data Guard configuration. In order to be prepared for role transitions you should not only create
standby redo logs on the standby databases, but also on the primary. Data Guard Broker will complain if there are no
standby redo logs! Additionally higher protection modes also require the existence of SRLs.
If SRLs are present they are used by Real Time Apply. In this apply mode, redo is applied from the standby redo
logs as they are filled. Without Real Time Apply standby redo logs work exactly as Online Redo Logs do in the primary
database. They are being written to in the circular fashion, and when full will be archived. The archived redo log is
then applied to the standby database.

Not ■ It is strongly suggested that you use Standby Redo Logs in all Data Guard scenarios for primary and standby databases.

Data Guard allows you to have multiple copies of the same database in your configuration. This poses a
challenge: if the databases are all identical, how can Data Guard work out who is who and what role is a database in?
The solution to that problem is with the database unique name. Consider Figure 9-2 .

Figure 9-2. A Data Guard configuration with multiple standby databases using different database unique names (in italics)