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

Introducing RDF
Compaq NonStop™ RDF/IMP and IMPX System Management Manual—522204-001
1-17
Updater Processes
information, an updater sends the audit information to the disk process to be applied to
the backup database.
Each updater performs the following functions:
•
Reads large blocks of data from the RDF image file and searches for image records
associated with the updater’s volume on the primary system.
•
Opens and closes database files on the backup system for updating and maintaining
the backup database.
•
Defines restart points and updates restart information in the context file (named
CONTEXT). For an explanation of restart points, see Restart Information.
•
Sends information to RDFCOM for use in the STATUS RDF command display.
•
Issues a logical REDO request to the disk process (during the normal forward pass
over the image trail) for each update associated with its volume.
•
Issues logical UNDO requests to the disk process when backing out changes
associated with transactions that need to be undone during RDF takeover or
stop-update-to-timestamp operations.
•
Bundles the REDO and UNDO requests into batch TMF transactions, the duration
of which is specified by the UPDATERTXTIME configuration parameter.
•
For Enscribe files only, performs the following DDL operations:
CREATE
PURGEDATA
ALTER MAXEXTENTS (used only for increasing MAXEXTENTS)
•
For SQL files only, performs the following DDL operation: PURGEDATA
An RDF updater can send up to 28 KB of audit information to the disk process in a
single request and can manage two outstanding requests at any given time. The updater
is a multithreaded process. The two most prominent threads perform these tasks:
•
Reading and queueing audit for submittal to the disk process
•
Submitting the audit to the disk process and handling replies from that process
An updater cannot always respond immediately to the STOP UPDATE and STOP RDF
commands. If an updater has audit information queued for the disk process, the updater
must wait until all of that information is processed before it can shut down.
You specify the primary and backup CPUs for each updater. If the original backup
process has to take over because the primary CPU failed, this backup process runs by
itself. When it determines that the primary CPU has come back up, it creates a new
backup process in that CPU.
When it has to take over, the original backup process becomes the primary process, and
remains so even after it creates a new backup process; that is, RDF does not switch back
to the original CPU configuration after the new backup process is created. If you stop
the updaters by way of a STOP RDF or STOP UPDATE command, however, when you
restart the updaters, your original configuration is once again used.