Publication of updated blocks to the cache structure can now be deferred until just before the end of the associated transaction. Multiple updates to a block may produce only a single write of the block to the cache rather than a cache write for each update.
The greater the number of database updates in parallel transactions, the greater the expected improvement in performance.
Note:
Deferred cache operations create an asymmetry between users on the
update nucleus, who see uncommitted updates, and users on other cluster nuclei,
who may or may not see uncommitted updates (unless they read with hold).
This document covers the following topics:
Since the write of updated blocks to the cache may fail due to conflicting updates to the same blocks by other nuclei in the cluster, every cluster nucleus must be capable of redoing the updates it has not yet written to the cache. The nucleus maintains information about these updates in the "redo pool".
The size of the redo pool is specified by the new ADARUN parameter
LRDP. The LRDP parameter is
effective only in a cluster nucleus; that is, when a nonzero
NUCID is specified.
If LRDP is not specified, the nucleus takes as
default the value of the LFIOP parameter. If
LRDP is explicitly set to zero, the nucleus writes each
update immediately to the cache.
Different nuclei in the same cluster can have different settings of
LRDP. It is also possible, although not recommended, to
run one nucleus with LRDP=0 and a peer nucleus with
LRDP>0.
Note:
If one nucleus runs with LRDP=0 and a peer
nucleus runs with LRDP>0 and the different cluster
nuclei concurrently update the same Data Storage blocks, incorrect DSST entries
may be produced. These are reported by ADADCK. Such errors are harmless and do
not affect the results of the application programs.
The nucleus reports on the use (high watermark) of the redo pool in a shutdown statistic and in the response to the DRES command from the operator console or from ADADBS OPERCOM.
