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

Maximum Availability mode
This is a hybrid mode that strikes a balance between the other two modes. For transactions to commit on the primary
database, at least one synchronized standby database must have received the redo in its standby redo logs. If it's
not possible to write the redo stream to at least one synchronized database, the primary will perform as if it were
configured in maximum performance mode.
In this respect this protection mode seems most desirable. When using the Data Guard Broker as shown in the
following example, you are well protected from rolling disasters. A rolling disaster not only affects your primary, but
also your secondary site. In the default settings the Broker will configure Data Guard in a way that a transaction on the
primary can only commit if the write is confirmed on the standby site.
Since Oracle 12.1 it is possible to configure the Maximum Availability mode so that it only acknowledges that
redo has been received in memory with the log write initiated but not completed. It does not confirm that the redo
has actually been written to a standby redo log. The slight performance benefit you get (not having to wait for the redo
to be written to disk) comes at the cost of higher exposure to the rolling disaster: if both sides went down at the same
time, you could have incurred data loss, since redo in the buffers may not have been written to disk yet.

Role transitions
Data Guard supports two types of role transitions: a graceful switchover and a failover . During a switchover operation,
the primary database ensures that no data loss occurs by performing a log switch and waiting for the redo to be
applied on all databases that form part the Data Guard configuration. Only then will it transform into a standby
database itself. At this stage, all the databases forming part of the Data Guard configuration are physical standby
databases. The administrator then chooses one of the other standby databases to assume the primary role.
A switchover is an elegant solution that helps to minimize time required for performing the following
maintenance operations:
Scheduled replacement of hardware •

• Migration to another storage technology such as ASM

• Storage array migration when using traditional file systems for storage

• Data center migration

• Upgrading the version of Grid Infrastructure without upgrading the database at the same time

• Major operating system upgrades

•
A switchover operation is not entirely free of downtime, but it provides a proven procedure and technology for
such tasks.
A failover indicates a more severe situation in which the primary database is no longer available for a switchover,
possibly because of a site failure or the loss of the storage backend. In such a situation, the administrator should
try salvaging as many outstanding archived logs as possible. Since 11.2 it is even possible to flush unsent redo from
the primary to the standby, potentially allowing a no-data-loss failover! The DBA should also minimize or, if at all
possible, eliminate the gap to be resolved on the standby database before activating one of the standby databases for
read-write access. Data loss may occur, depending on the protection mode the Data Guard configuration is using.
Prior to the introduction of the Flashback Database feature, activating a standby database always implied that
the previous primary database had to be completely rebuilt by restoring it from a backup. Today, however, if the
failed primary database has flashback database enabled, then the time and effort required for a reinstantiation of the
database can be greatly reduced, assuming that it can be started up without problems. For example, once the failed
database has been restarted after a complete data center power outage, it is possible to flash it back to the system
change number that existed prior to the activation of the new primary. From there, the database can be converted to a
physical standby with only a few commands. When the situation clears, the former primary database can then be the
target of a graceful switchover to restore service to before the failover.

Changing the word size from 32 bit to 64 bit (although that is less common these days)