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

In Figure 1, there are 20 audited volumes on the primary system ($D1 through $D20). Only volumes
$D1 through $D15, however, are configured for RDF protection.
Audit records for volumes $D1 through $D10 and $D16 through $D20 are sent to the master
audit trail (MAT). The RDF master extractor process reads the MAT and sends audit records
associated with volumes $D1 through $D10 to the RDF master receiver process on the backup
system.
Audit records for volumes $D11 through $D15 are sent to the auxiliary audit trail. The RDF auxiliary
extractor process reads the auxiliary audit trail and sends audit records associated with volumes
$D11 through $D15 to the RDF auxiliary receiver process on the backup system.
The master receiver writes transaction status information to the master image trail. In this example,
each receiver process writes all audit records to a single secondary image trail. As will be discussed
later, however, either could write to multiple sorted image trails.
Updater processes $UP1 through $UP10 read audit records from the secondary image trail and
apply it to volumes $D1 through $D10, respectively, on the backup system. For example, updater
process $UP1 only looks for audit records 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 records from the AUX01 secondary 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 coordinates user commands among the RDF
processes and monitors those processes during all RDF states.
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 records associated with transactions that are
known to have been committed is applied to the backup database
Unplanned Outages With ZLT
Zero Lost Transactions (ZLT), functionality that is available only with the RDF/ZLT product, ensures
that no transactions that commit on the primary system are lost on the RDF backup system if that
primary system is downed by an unplanned outage. RDF achieves this though the use of remote
mirroring for the relevant TMF audit trail volume(s). That is, one mirror of an audit trail volume
remains local to the primary system, but the other mirror is located at a remote standby site.
When a primary system is downed by some unplanned outage or disaster, there might be some
audit data that the extractor on the primary system was unable to send to the backup system before
the outage. With ZLT functionality, RDF fetches all remaining audit data from the remote mirror,
thereby guaranteeing no loss of committed data during the RDF takeover operation.
For information about the ZLT function, see Chapter 17 (page 320).
Unplanned Outages Without ZLT
Without ZLT functionality, it is possible for some committed transactions to be lost during an
unplanned outage. When the RDF TAKEOVER command is issued, any transaction whose final
outcome is unknown on the backup system is backed out of the backup database. One or more
transactions might have committed on the primary system, but, before the extractor could read and
send the associated audit data to the backup system, the primary system failed. Loss of audit data
in this manner typically involves no more than a fraction of a second.
RDF Subsystem Overview 29