HADR
standby log spooling is a new feature in DB2® V10. This feature allows
transactions on the primary to make progress without having to wait for the log
replay on the standby. Log data that is sent by the primary is written, or
spooled, to disk on the standby if it falls behind in log replay. The standby
database can later read the log data from disk. This allows the system to
better tolerate either a spike in transaction volume on the primary, or a slowdown
of log replay on the standby. This feature can be used in both single and
multiple standby environments.

When making
use of log spooling, ensure that adequate disk space is provided to the active
log path of the standby database in order for it to hold the spooled log data,
in addition to the disk space required for active logs. Log space is determined
by the logprimary, logsecond and logfilsiz configuration parameters.

Log
spooling can be enabled by setting the hadr_spool_limit
database configuration parameter. It specifies an upper limit on how much data
is written, or spooled, to disk if the log receive buffer fills up. The default
value of 0 means no spooling. The special value of -1 means unlimited spooling,
as much as supported by the disk space available in the active log path on the
standby.

When
configuring for log spooling, in addition to the extra disk space requirement
on standby, another consideration is that there could be a larger gap between
the log position of the primary and log replay on the standby, which might lead
to a longer takeover time because the standby cannot assume the role of the new
standby until the replay of the spooled logs finishes.

Note that
making use of log spooling does not compromise the HADR protection provided by
the HADR feature. Data from the primary is still replicated in log form to the
standby using the specified sync mode; it just takes time to apply (through log
replay) the data to the table spaces.

There are a number of ways that the
HADR standby or standbys can be used beyond their HA or DR purpose.

Reads on standby

The reads on
standby feature can be used to direct read-only workload to one or more standby
databases without affecting the HA or DR responsibility of the standby. This
feature can help reduce the workload on the primary without affecting the main
responsibility of the standby.

Only the primary
database is accessible unless the reads on standby feature is enabled on one or
more of the standbys. Applications connecting to the standby database do not
affect the availability of the standby in the
case of a failover.

Delayed replay

Delayed replay can
be used to specify that a standby database is to remain at an earlier point in
time than the primary, in terms of log replay. If data is lost or corrupted on
the primary, it can be recovered on the time delayed standby.

Rolling updates and
upgrades

Using an HADR
setup, one can make various types of upgrades and DB2® fix pack updates to your
databases without an outage. With multiple standby mode enabled, an upgrade can
be performed while maintaining the protection provided by HADR

The high availability disaster recovery (HADR) feature
provides a high availability solution for both
partial and complete site failures. HADR protects against data loss by
replicating data changes from the primary database (source), to one or more standby
databases (targets).

A partial site failure can be
caused by a hardware, network, or software failure. Without HADR, a partial
site failure requires restarting the database management system (DBMS) server
that contains the database. The length of time that it takes to restart the
database and the server where it is located is unpredictable. It may take
several minutes before the database is brought back to a consistent state and
made available. With HADR, a standby database will
assume control in seconds. In addition, the system can redirect the clients
that used the original primary database to the new primary database by using
automatic client reroute or retry logic in the application.

A complete site failure will
occur when a disaster, such as fire, causes the entire site to be destroyed.
For example, the primary database may be located at your primary data center in
one city, and a standby database might be located at your second data center in
another city. If a disaster occurs at the primary site, data availability is maintained by having the remote
standby database take over as the primary database with full DB2® functionality.
After a takeover operation occurs, one can bring the original primary database
back up and return it to its primary database status; this is known asfailback. One can initiate a
failback if one can make the old primary database consistent with the new
primary database. After reintegration of the old primary database into the HADR
setup as a standby database, one can switch the roles of the databases to
enable the original primary database to once again be the primary database.

With HADR, the level of
protection from potential loss of data is based on configuration and topology
choices. Some of the key choices will now be detailed:

What level of
synchronization will one use?

Standby databases are
synchronized with the primary database through log data that is generated on
the primary and shipped to the standbys. The standbys constantly roll forward
through the logs. One can choose from four different synchronization modes. In order
of most to least protection, these modes are SYNC, NEARSYNC, ASYNC, and
SUPERASYNC.

Will one use a peer
window?

The peer window feature specifies
that the primary and standby databases are to behave as though they are still
in peer state for a configured amount of time if the primary loses the HADR
connection in peer state. If primary fails in peer or this "disconnected
peer" state, the failover to standby will have zero data loss. This
feature provides the greatest protection.

How many standbys
will one deploy?

With HADR, one can use either
single standby mode or multiple standby mode. With multiple standbys, a user can
achieve both high availability and disaster
recovery objectives with a single technology