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

Introducing RDF
Compaq NonStop™ RDF/IMP and IMPX System Management Manual—522204-001
1-22
Available Types of Replication to Multiple Backup
Systems
On secondary trail #1, however, only file AA000009 and all files preceding it are
actually eligible to be purged (the current file AA000011 minus the default retain count
of 2). Note that file AA000010, in which transaction T100 is marked as “alive,” is not
yet eligible to be purged because it is still protected by the retain count.
Because T100 is marked “alive” in a file pinned on disk, no files on any trails that
potentially contain audit records for T100 can be purged. Thus, even though files
AA000010 through AA000023 are not needed by the updaters on secondary trail #2,
they cannot be purged because the purger can determine that T100 was also “alive” in
file A000010 on secondary trail #1. The purger cannot purge any files associated with
T100 because, if the primary system should fail, all audit records for all transactions
marked “alive” in image files pinned on disk must be available should some of these
transactions need to be undone. Remember, RDF does not keep track of commit/abort
status in normal processing; it determines this only at the time of a takeover. Therefore,
in our example, the purger does not know whether T100 has committed or not.
In general, to avoid having a build up of files on one or more image trails, you should
configure image trails so they all grow at the same rate (excluding the master image
trail, which is managed separately from secondary image trails). If this is not possible,
an alternative is to configure your image files with smaller sizes. If you have long-
running transactions and uneven growth on your image trails, the only solution is to be
sure you have the fast-growing trails on large disks and that those disks have plenty of
available space.
Available Types of Replication to Multiple Backup
Systems
The RDF product allows you to replicate database changes from a single primary system
to multiple backup systems. This makes possible simultaneous read-only access to all of
the backup systems, a capability particularly desirable for query-intensive applications
where a central volatile database can be distributed to several remote systems for local
access by queries.
Replication to multiple backup systems is achieved by establishing multiple RDF
configurations, all protecting the database or portions of it on the same primary system.
As an example, you might wish to replicate the same data to different backup systems,
as follows:
RDF Configuration #1
\A ---------> \B
RDF Configuration #2
\A ---------> \C
RDF Configuration #3
\A ---------> \D