曝光台 注意防骗
网曝天猫店富美金盛家居专营店坑蒙拐骗欺诈消费者
• Database instance failure (or last instance failure in a RAC configuration)
• Shutdown abort (or shutdown abort of the last instance in a RAC
configuration)
• Datafiles taken offline due to I/O errors
The following network conditions will trigger a fast-start failover:
• When both the Observer and the standby database lose their network
connection to the primary database, and when the standby database
confirms that it is in a “synchronized” state.
The detailed behavior of a fast-start failover and accompanying automatic
reinstatement of the original primary database as a new standby database is
described below.
Fast-Start Failover Following Primary Database Failures
A fast-start failover may also be initiated in the following cases of primary database
failure:
Fast-Start Failover – Oracle Data Guard 10g Release 2 Page 8
• Instance failures: If a single-instance primary database fails, or if all
instances of a RAC primary database fail, the Observer attempts a faststart
failover.
• SHUTDOWN ABORT: If a single-instance primary database or if all
instances of a RAC primary database are shut down with the ABORT
option, the Observer attempts a fast-start failover. Fast-start failover is
not attempted for the other types of database shutdown (NORMAL,
IMMEDIATE, TRANSACTIONAL).
• Offline datafiles: If the Observer determines that one or more datafiles in
the primary database have been taken offline by the database because of
I/O errors, it attempts a fast-start failover. Note that in this instance the
FastStartFailoverThreshold is ignored and a failover attempt is
immediately triggered.
In all cases, a fast-start failover is not executed unless the Observer and the
standby database can agree on the synchronized state of the standby. This insures
that a fast-start failover will result in zero data loss.
Fast-Start Failover and Network Disconnects
Fast-start failover may also occur in the event the network links between the
primary and standby database, as well as between the primary database and the
Observer, get disconnected, and while the connection between the Observer and
standby database remains intact. The exact behavior of fast-start failover in this
case depends on the order in which the network links around the primary database
get disrupted, and whether the Observer and standby database agree that there was
complete synchronization with the primary database at the time of failure.
Specifically:
• Suppose {primary -> standby} network link fails first. The primary
database being in a Maximum Availability configuration, upon this
network disconnect, will attempt to move to a RESYNCHRONIZATION
protection-level, as reflected in the PROTECTION_LEVEL column in
v$database. The {primary -> Observer} link is still intact, so the
Observer agrees to and acknowledges this transition, and the primary
database completes the transition to this protection level. The overall faststart
failover state becomes UNSYNCHRONIZED, as reflected in the
fs_failover_status column in v$database of both the
primary and standby database (the Observer advises the standby database
to move to this state). The primary database continues committing user
transactions; redo gets generated and accumulates locally. The Observer
does not initiate a fast-start failover in this case because it knows that the
fast-start failover state is UNSYNCHRONIZED. If the {primary ->
Observer} link fails now, fast-start failover will not occur, and application
transactions continue at the primary database.
Fast-Start Failover – Oracle Data Guard 10g Release 2 Page 9
• Suppose {primary -> Observer} network link fails first. In this case, the
fs_failover_status and fs_failover_observer
_present columns in v$database will be as follows:
Site fs_failover_status fs_failover_observer_present
Primary Synchronized No
Standy Synchronized Yes
Fast-start failover does not occur in this scenario. Primary database
continues applying transactions and generating redo as well as
transmitting redo to the standby database. Now, at this stage, if the
{primary -> standby} link fails, the primary database tries to transition
protection level from MAXIMUM AVAILABILITY to
RESYNCHRONIZATION – however it cannot communicate with either
the Observer or standby database, so this transition does not succeed and
the primary database stalls, preventing new transactions from committing.
Meanwhile, assuming the {Observer -> standby} link is still intact, the
Observer has been asking the standby database if it is ready to failover to
中国航空网 www.aero.cn
航空翻译 www.aviation.cn
本文链接地址：
航空资料22(55)
