Databases Reference
In-Depth Information
B.2
Subminute Failover
HADR has been demonstrated with a failover of a database supporting 600 concurrent
SAP users and was achieved in only 11 seconds. Clearly HADR is capable of supporting
subminute failover.
One of the issues with Data Guard is that you must stop and restart the instance
during failover, which negatively impacts availability. The following quote is from a case
study on Oracle's own internal processing systems, which use Data Guard. It is signifi-
cant to note that this system does not deliver subminute failover.
B.3
Geographically Separated
Both HADR and Data Guard use TCP/IP to send log buffers from the primary server
to the standby site. As such, both allow for the servers to be separated by a large dis-
tance. In addition, both products offer asynchronous buffer transmission so that very
large distances do not adversely affect the performance of the primary server.
B.4
Support for Multiple Standby Servers
With the first release of HADR, DB2 supports one primary and one standby database.
The key objective is to provide the highest levels of availability possible. An issue with
multiple standby servers is that the impact on the primary server becomes too great to
efficiently support synchronous mode. Therefore, in order to support multiple standby
servers, the use of asynchronous mode is more appropriate. IBM's solution for asyn-
chronous multisite standby servers is Q Replication, with which you can have multiple
targets for a given source database. The tradeoff to consider when looking at asynchro-
nous modes to multiple standby servers is the potential transaction loss in comparison
to HADR in synchronous or near-synchronous modes.
B.5
Support for Read on the Standby Server
Oracle Data Guard allows for the log replay to be suspended on the standby server so
that the database can be opened in read-only mode. This, however, elongates the
failover times as the standby server cannot be both in read-only mode and be replaying
logs at the same time. In some reports, delaying the log apply can add 15 minutes to the
failover times. If read on standby is a higher priority, then DB2 Q Replication would be
a better alternative. Q Replication allows for read and write on the remote databases.
Combined with automatic client reroute, this solution provides “instant” failover as
there is no need to recover in-flight transactions after a failover.
