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

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 2 (page 32)).
◦ 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).
◦ A single primary system whose database changes are replicated to databases on multiple
backup systems. Such an environment makes possible simultaneous read-only access to
all of the backup databases (this is desirable for query-intensive applications such as
telephone directory assistance).
◦ Triple contingency—a special instance of the database replication feature whereby a
single primary system is protected by two identical backup systems. This feature allows
your applications to resume, with full RDF protection, within minutes after the loss of your
primary system, provided the two backup systems are not too far behind.
◦ Loopback configuration—where the primary and backup systems are the same system.
This has no value from a disaster protection standpoint, but can be useful for testing
purposes. Data from a set of volumes can be replicated to a different set of volumes on
the same node.
◦ RDF does not require an identical one-to-one volume relationship between volumes on
the primary system and those on the backup system. Backup volume names do not have
to match primary volume names. The subsystem can direct audit records from more than
one audited volume on the primary system to a single volume on the backup system,
provided that no more than one partition of a file exists on any backup volume. (For
information on partitioned files, see the Guardian User’s Guide.)
• Application independence
RDF is application independent. It can protect through replication any audited NonStop SQL
tables and indexes as well as any audited Enscribe key-sequenced, relative, or entry-sequenced
files, including partitions, alternate key files, and Queue files. Unstructured Enscribe files,
however, are not supported.
RDF Subsystem Overview 31