曝光臺 注意防騙 網曝天貓店富美金盛家居專營店坑蒙拐騙欺詐消費者

which it has responded 'no' up to this point. However, now that the
{primary -> standby} link has failed, the standby database will answer 'yes'
after FastStartFailoverThreashold seconds have passed and
Fast-Start Failover will ensue.
• If the {primary -> standby} and {primary -> Observer} network links fail
simultaneously, then a fast-start failover will ensue. Following is the
sequence of state transitions that occur in this case.
o Upon losing connection to the primary database, the Observer
attempts to reconnect for the number of seconds specified by the
Broker property FastStartFailoverThreshold. If unsuccessful, it
will ask the target standby database if it is ready to failover.
o If the standby database also has not seen the primary database
for FastStartFailoverThreshold seconds, then it accepts the
Observer’s invitation to fail over, transitioning to the primary
database role. The fs_failover_status column of v$database of the
standby database will indicate the value REINSTATE
REQUIRED.
o Meanwhile the primary database, if still up, stalls because it
attempts to transition to an UNSYNCHRONIZED fast-start
failover state and RESYNCHRONIZATION protection-level,
but does not get any acknowledgement from the Observer or the
standby database in that regard. This old primary database is no
longer allowed to commit any transactions and the value
STALLED is reflected in the fs_failover_status column of its
Fast-Start Failover – Oracle Data Guard 10g Release 2 Page 10
v$database. This prevents the primary database and the standby
database from becoming transactionally-divergent.
o Once the standby database has transitioned to the primary
database role, it broadcasts a “database down” event on behalf of
the old primary database. Oracle 10g Release 2 TAF-enabled
OCI applications will respond to this event by immediately
disconnecting from the old primary database and reconnecting to
the new primary database where they can continue their work.
Other middle tier applications can be automatically restarted as
part of a role change trigger that occurs as the new primary is
opened. For further details on role transition-events, please refer
to the section “Automatic Client Failover”, in the section below.
As can be seen from the above discussions, by ensuring that at least two fast-start
failover partners agree to major state transitions, conditions such as split-brain
scenarios (i.e. a configuration in which there are two divergent “primary
databases”) are avoided in a fast-start failover configuration.
ORACLE TEST RESULTS
Oracle tested a Fast-Start Failover configuration comprised of a primary database,
standby database, and observer, all running Redhat Linux 3.0. The results of the
test are provided in figure 2 below.
The test databases were each 100GB in size. Each host was connected to the next
over a Gigabit Network. The workload on the primary database generated 3
MB/second of redo. Both single instance and RAC configurations were tested.
Tested configurations included failover to a physical standby database (Redo
Apply), and a logical standby database (SQL Apply). In all cases, the failover
threshold (or time to detect the failure) was not included in the failover timing
0
5
10
15
20
25
Failover
time
(seconds)
Phsical Standby Logical Standby
Single Instance RAC
Figure 2 – Fast Start Failover Test Results
Fast-Start Failover – Oracle Data Guard 10g Release 2 Page 11
calculation, the test measured only the time required to complete the actual
database failover. Total time to complete failover ranged between 10 and 25
seconds, depending upon the configuration.
REINSTATEMENT AFTER A FAST-START FAILOVER
In one of the scenarios described above, the primary database will be stalled if a
fast-start failover occurs. If the network connection between the primary database
and the Observer is restored, the Observer will automatically reinstate this primary
database as a new standby database in the configuration. However, prior to that,
the administrator may forcibly shut down the primary database instance and
attempt to restart it. In other potentially common cases, the primary database
server might have crashed, leading to a fast-start failover. In this case, the
administrator may simply attempt to restart the primary database instance. In
either case, the administrator may restart the primary database instance using
“STARTUP” or “STARTUP MOUNT” through SQL*Plus or DGMGRL.
If the administrator tries to open the old primary database with the STARTUP
　
中國航空網 www.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：航空資料22(56)