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

command, Data Guard Broker will not allow it to proceed from the mount state to
the open state until at least one other fast-start failover member agrees to that state
transition. Because fast-start failover has already occurred and there is a new
primary database in the configuration, the primary database will not get
confirmation from either the Observer or target standby database, thus -
preventing another potential split-brain scenario. An ORA-16649 error message
(“database must be opened by Data Guard broker when Fast-Start Failover is enabled”) will
be generated. However, because the Observer regains network access to the
primary database instance, it will automatically initiate reinstatement of the old
primary database into a new standby database in the Data Guard configuration,
restoring disaster protection of the new primary database.
If the administrator tries to start the old primary database with the STARTUP
MOUNT command, no error message will be generated, and the Observer will
automatically reinstate the old primary database as a new standby database in the
Data Guard configuration.
If the administrator tries to start the old primary database with the STARTUP
NOMOUNT command, the old primary database will not be mounted and the
Broker will not pursue reinstatement until further administrative action is taken
(e.g. mounting the old primary database).
ORACLE BEST PRACTICES FOR FAST-START FAILOVER
Primary Configuration
The Data Guard configuration must be set at Maximum Availability protection
mode using LGWR SYNC AFFIRM as the redo transport mode. This means that
redo generated on the primary is synchronously shipped and written to disk on the
Fast-Start Failover – Oracle Data Guard 10g Release 2 Page 12
standby server. The primary database does not acknowledge the commit to the
database client until it receives an acknowledgement that the redo has been written
to disk on both primary and standby servers. Maximum Availability insulates the
primary database from the impact of network or standby server failures (such
failures are automatically detected and the primary database continues processing).
However, due to the synchronous nature of redo shipping, there is potential for
the performance of the primary database to be impacted by network resources and
disk writes on the standby database. For this reason it is very important to follow
Oracle best practices for network transport and insure that networks have suitable
bandwith and latency to support synchronous redo shipping.
Standby Configuration
To minimize failover time it is strongly recommended that the standby database be
configured with Data Guard Standby Redo Logs and Real Time Apply. This
enables the Managed Recovery Process on a physical standby, or the SQL Apply
Process on a logical standby, to apply redo to the standby database as it is received,
without waiting for a log switch on the primary database. This means the standby
database will be completely up-to-date with the primary database. There will be no
delay in failover time resulting from the standby database needing to complete the
application of redo received from the primary database.
In Data Guard configurations where significant Redo volume is generated at times
of peak usage, it may be that default settings are insufficient, and it becomes
necessary to further tune the Data Guard processes that apply redo the standby
database. In all HA configurations, Oracle recommends users read the
comprehensive review of Oracle best practices contained in Oracle Database 10g,
High Availability Architecture and Best Practices [3]. For further drill down into
best practices for tuning the Redo Apply process for physical standby reference:
Oracle Database 10g Best Practices, Data Guard Redo Apply and Media Recovery
[4]. For similar information for SQL Apply processing on a logical standby,
reference: Data Guard SQL Apply Best Practices in Oracle Database 10g [5].
Network Transport
Tuning operating system parameters that affect Data Guard network throughput
can significantly enhance the ability of a network to support a Maximum
Availability configuration. These parameters include the TCP Send and Receive
buffers and settings that regulate the size of the buffer between the kernel network
subsystems and the driver for network interface cards. The importance of tuning
for applications with significant workload is clear from testing done by Oracle
which demonstrated an order of magnitude improvement in throughput by simply
adjusting 3 parameters (see figure 3).
Fast-Start Failover – Oracle Data Guard 10g Release 2 Page 13
For a complete understanding please reference Data Guard Primary Site and
　
中國航空網(wǎng) www.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：航空資料22(57)