RDF System Management Manual for H-Series and J-Series RVUs (RDF 1.9)

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-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 136).
Features
In providing backup protection for online databases, RDF offers many advantages:
• Continuous Availability
RDF maintains an online copy of your production database on one or more backup systems.
If the primary system should go down, the backup database(s) will be consistent and you
can resume your business processing on a backup system with minimal interruption and
data loss.
• Fault tolerance
You can restart RDF after a system failure. Single processor failures do not bring the
subsystem down. If a double processor failure occurs, RDF goes down, but it can be restarted
with no loss of data (issue a START RDF command after the processors have been restored).
• High performance
RDF can typically replicate data from the primary RDF node as fast as the customer
application is capable of generating it.
• Flexibility in protection
You can run RDF with updating on the backup system either enabled or disabled.
RDF is also very flexible with regard to system interrelationships and to disk usage
requirements on backup systems. Besides the most basic configuration of a single primary
system protected by a single backup system, you can have configurations such as these (see
Figure 1-2 (page 37)).
— Multiple primary systems protected by one backup system.
— Reciprocal protection between two systems, where each is the backup to the other
(different databases on the two systems).
RDF Subsystem Overview 35