RDF System Management Manual for H-Series RVUs (RDF 1.8)

No image file in a given image trail can be purged until it is absolutely clear that all updaters
configured to the trail will no longer require that file for an UNDO pass during a takeover or
stop-update-to-time operation. RDF automatically keeps track of which range of transactions is
represented in each image trail file. The purger process can therefore always determine with
confidence when a particular image trail file can be purged.
For example, assume the following:
• There are two image trails.
• Five updaters are assigned to each trail.
• A long-running transaction (T1000) involves all five updaters on one trail, but none on the
other.
• T1000 became active when the current image file in each trail was AA000002, and is still
active.
• The receiver is currently writing to image file AA000015 in both trails.
• All updaters are currently reading audit records from AA000015.
Although all the updater restart locations are in AA000015, none of the image files from AA000002
through AA000014 can be purged while T1000 is active or aborting because they will be required
if T1000 needs to be backed out during an RDF takeover or stop-update-to-timestamp operation.
This is true for both trails, even though none of the updaters on one trail have ever been involved
with T1000. If an UNDO pass becomes necessary, all updaters must perform that pass in search
of any audit records associated with T1000 (they must go back in each image trail to the point
where T1000 began: AA000002 in this example).
The purger process exists to avoid having the receiver keep track of all this information, which
could impact extractor-receiver throughput significantly. The purger process interacts with the
updaters to determine when image files can be purged.
RDF Operations 55