RDF System Management Manual for J-series and H-series RVUs (RDF 1.10)

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.
Table 1 Audit Records at the Time of a Primary System Failure
Updates sent to the backup (Sequence in image trail file)Primary database updates (Sequence in master audit trail
file)
TRANS100—Update 1TRANS100—Update 1
TRANS100—Update 2TRANS100—Update 2
..
..
..
TRANS100—Update 10TRANS100—Update 10
TRANS101—Update 1TRANS101—Update 1
TRANS100—Commit record
(Primary system fails)
In the example illustrated in Table 1, a disaster has brought down the primary system immediately
after the commit record for transaction 100 was written to the MAT, but before the RDF extractor
process was able to send the commit record to the backup system. For transaction 101, a single
update was logged in the MAT and sent to the backup system, but the primary system was brought
down before the transaction was completed.
When the command for a takeover is issued, the updater processes treat all transactions whose
outcomes are not known as aborted transactions. In this scenario, only the changes related to
transactions known with certainty to have been committed on the primary system are left in the
backup database. Therefore, in the example illustrated in Table 1, the audit records associated
with transactions 100 and 101 is backed out of the backup database.
Typically, the extractor process sends audit records to the backup system within a second after it
has been written to the MAT on the primary system, so a minimum number of transactions are lost
when a disaster brings down the primary system.
Planned Outages
RDF can be very useful when a planned shutdown of the primary system is necessary. For example,
you might need to bring the system down to install new hardware or to perform a system software
upgrade. In such a situation, you might determine it is unacceptable to stop your business
applications for the time required.
With RDF, you need only stop the applications momentarily, do a switchover from the primary
system to the backup system, and then restart the applications on the backup system. When the
primary system is ready for use again, you can use RDF to bring the primary database up-to-date
with changes made to the backup database while the primary system was shut down. After the
primary database is consistent with the backup database, you can perform another switchover,
this time from the backup system to the primary system, and then restart the applications on the
primary system. For instructions on how to perform a switchover, see “Carrying Out a Planned
Switchover” (page 127).
30 Introducing RDF