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.