Database Reference
In-Depth Information
The conditions for a failover seem favorable. As with the graceful switchover operation you can check the
destination database's role change readiness (the primary database has by now crashed):
DGMGRL> validate database "CDBFSDCB"
Database Role: Physical standby database
Primary Database: CDBFSDCA
Warning: primary database was not reachable
Ready for Switchover: No
Ready for Failover: Yes (Primary Not Running)
Temporary Tablespace File Information:
CDBFSDCA TEMP Files: Unknown
CDBFSDCB TEMP Files: 3
Flashback Database Status:
CDBFSDCA: Unknown
CDBFSDCB: On
Data file Online Move in Progress:
CDBFSDCA: Unknown
CDBFSDCB: No
Transport-Related Information:
Transport On: No
Gap Status: Unknown
Transport Lag: 0 seconds
Transport Status: Success
Log Files Cleared:
CDBFSDCA Standby Redo Log Files: Unknown
CDBFSDCB Online Redo Log Files: Cleared
DGMGRL>
The database is indeed ready for a failover, and you are informed that the primary database is not running. Unlike
with a switchover, there are two possible ways to perform the failover: the preferred and strongly recommended
complete failover and the emergency-not-to-be-used-if-at-all-possible immediate failover.
Performing an immediate failover
The immediate failover is the panic button. It is not recommended unless there is really no other way to fail over. You
will almost certainly incur data loss! No additional redo is applied to the standby; if there is a transport lag, you will
incur data loss which is proportional to the transport lag.
For the reasons shown in this section the immediate failover will not be discussed further. The only
application one can think of is to allow a standby which is lagging behind by design to take over the primary role
after a release went wrong or similar logical corruption occurred on the primary. Your monitoring tools should
have picked that up.
Search WWH ::
Custom Search