RDF/IMP and IMPX System Management Manual (RDF 1.3+)

Introducing RDF
Compaq NonStop™ RDF/IMP and IMPX System Management Manual—522204-001
1-21
Purger Process
•
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. Note that 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.
Now consider another example.
Assume there are three image trails, the master and two secondary trails, and that the
current file in both secondary trails is AA000010. Assume further that the audit records
received from the primary system are associated with all three trails, but the majority of
them are associated with a long-running transaction (T100), and all audit records for that
transaction are sorted only to secondary trail #2.
Now assume that transaction T100 commits after 30 minutes. By that time, the current
file on secondary trail #2 has rolled over 10 times, so the receiver is now writing to file
AA000020 in that image trail. On secondary trail #1, however, only a small number of
audit records were received for other transactions, so the receiver is still writing to file
AA000010 in that image trail.
The receiver maintains information about all of the latest transactions it has handled, and
stores this information in each image file. It does this with regard to all transactions it
has seen on all trails (it does not store information based on the specific transactions it
has stored in a specific trail).
Therefore, in the above example, transaction T100 is stored as “alive” in AA000010 on
secondary trail #1, even though no records associated with that transaction have ever
been stored in the file. The transaction is also stored as “alive” in files AA000010
through AA000020 on secondary trail #2.
Now assume that, some time later, the current file is AA000011 in secondary trail #1
and AA000025 in secondary trail #2. Assume also that all updaters are on the latest file
in each trail.
Because the last update for transaction T100 was in file AA000020 in secondary trail #2,
and because all updaters for this trail have restart locations in AA000025, files
AA000010 to AA000023 are theoretically eligible to be purged (the current file
AA000025 minus the default retain count of 2, indicating that file AA000023 and all
files preceding it are no longer needed).