Database Reference
In-Depth Information
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
If you were using block change tracking on the primary before the switchover to facilitate faster level 1 backups
of the database then please ensure you enable BCT again once the switchover completed, if you need it. By default
the block change tracking file will not be created and enabled on the new primary. Be careful enabling BCT on the
standby database because you need a license for Active Data Guard to do so. If your switchover operation is not part
of a scheduled test then please test the connectivity with your backup solution and the database, the archive log
deletion policy and other infrastructure tasks that you might regularly perform to be compliant with your standards
and outside regulators. Also verify that the log file name and data file name conversion parameters are set on the new
standby, and that it has standby redo logs. It always pays off to configure databases in a Data Guard environment for
all roles. If you rely on Oracle Clusterware to start and stop databases, review the configuration to ensure that the
standby database starts into the appropriate mode. Remember the license implications of having a standby database
open read only while applying logs. You want the primary database to be open in read write mode.
Performing a failover operation
A failover operation is not usually something users are happy to test in a non-crisis situation. A decision for a failover
has to be made by senior management for an application, and should have been practiced and documented to avoid
mistakes when it happens. Coordination for a failover will be even more difficult in a DBaaS environment where all
of the application owners have to agree. As with the switchover, the failover target should be selected in such way
that data loss is minimized. The transport lag plays an important role, especially in protection mode Maximum
Performance. Remember that the redo is sent directly to standby redo logs from where it is applied to the standby
database with Real Time Apply. In the default settings for the maximum availability mode transactions commit on the
primary only after the standby database confirmed that redo has been received and indeed written into the SRLs. The
transport lag therefore is probably very small.
You could use the Broker command line interface to check the transport lag before a failover operation. Consider
the following example, where database CDBFSDCB is the standby database for CDBFSDCA:
DGMGRL> show database "CDBFSDCB"
Database - CDBFSDCB
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds (computed 0 seconds ago)
Apply Lag: 0 seconds (computed 0 seconds ago)
Apply Rate: 115.00 KByte/s
Real Time Query: OFF
Instance(s):
CDBFSDCB
Database Status:
SUCCESS
Search WWH ::
Custom Search