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.
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.
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
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.
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.