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

Introducing RDF
Compaq NonStop™ RDF/IMP and IMPX System Management Manual—522204-001
1-4
Unplanned Outages
Updater processes $UP1 through $UP10 read audit information from the master image
trail and apply it to volumes $D1 through $D10, respectively, on the backup system. For
example, updater process $UP1 only looks for audit information for tables and files
associated with volume $D1 on the primary system (ignoring any for volumes $D2
through $D10), and applies that information to the corresponding tables and files on
$D1 on the backup system.
Updater processes $UP11 through $UP15 read audit information from the AUX01
image trail and apply it to volumes $D11 through $D15, respectively, on the backup
system.
As mentioned earlier, the RDFCOM process on the primary system provides the user
interface for issuing RDF commands. The RDF monitor process executes most user
commands, and monitors all other RDF processes.
Unplanned Outages
An unplanned outage typically occurs as the result of a sudden disaster that prevents the
database on the primary system from being used. The classic purpose of RDF is to make
rapid recovery from an unplanned outage possible by maintaining a replicated database
on a backup system. When the primary system is unexpectedly affected by a disaster,
you can shift operations to the replicated database on the backup system after having the
RDF updaters bring the backup database to a consistent state. You do that by starting
RDFCOM on the backup system and initiating an RDF takeover operation.
An RDF takeover operation ensures that all audit information associated with committed
transactions is applied to the backup database. If the status of a transaction is unknown
on the backup system because the commit or abort record was not sent by the time the
disaster brought the primary system down, the transaction is considered to be aborted,
and any audit information associated with that transaction is backed out of the backup
database.
If the primary system is unexpectedly brought down because of a disaster, the outcome
of some transactions might never be known, as illustrated in Table 1-1
.
Table 1-1. Audit Information At the Time of a Primary System Failure
Primary database updates
(Sequence in master audit trail file)
Updates sent to the backup
(Sequence in image trail file)
TRANS100—Update 1 TRANS100—Update 1
TRANS100—Update 2 TRANS100—Update 2
..
..
..
TRANS100—Update 10 TRANS100—Update 10
TRANS101—Update 1 TRANS101—Update 1
TRANS100—Commit record
(Primary system fails)