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

8. Turn on updating.
9. When RDF has caught up, do a planned switchover from \B to \A (as described earlier).
If you have an RDF Network, there are some situations where File Recovery with the
TOMATPOSITION option is not possible. If that is the case, RDF logs an RDF Event 858 at the end
of the takeover operation.
Reading the Backup Database (BROWSE versus STABLE Access)
Unlike databases protected by TMF, backup databases for RDF protection have no locks on rows
or records, even while these rows or records are being updated. Therefore, applications can read
the backup databases at any time; the data can, however, be inconsistent because reading and
updating can occur simultaneously.
Except immediately after a takeover operation, after the updaters have stopped as the result of a
STOP TMF command, or after the updaters have stopped as the result of a STOP UPDATE,
TIMESTAMP command (discussed further below), you only have the equivalent of BROWSE ACCESS
to the backup database. BROWSE ACCESS, a NonStop SQL/MP access option for transaction
consistency, provides immediate access to the data; however, the data can be inconsistent because
a transaction might not be completely applied to the backup database when the query is in progress.
This access provides the lowest consistency but the highest concurrency.
Immediately after a takeover operation or after the updaters have stopped as the result of a STOP
TMF or STOP UPDATE, TIMESTAMP command, you have the equivalent of STABLE ACCESS to the
backup database; at those points, the backup database is consistent with regard to all transactions
whose outcomes (commit or abort) are known at the backup system.
The following example shows the kind of data inconsistency that can occur if the backup database
is read while the database is being updated:
Suppose that a file named FILEA resides on $VOL1 on the primary system and that a file named
FILEB resides on $VOL2 on this primary system. Suppose transaction number 50 causes changes
to both FILEA and FILEB on the primary system.
Now suppose that the updater for $VOL1 has processed transaction 50, but the updater for $VOL2
has not.
If the backup database is read at this point, the database reflects the incomplete updating for
transaction 50.
To read the backup database while RDF is running, your application should open the backup files
with SHARED READ-ONLY access.
Near Real Time Read Access to Updates on the Primary System
The receiver configuration option FASTUPDATEMODE (formerly known as SLOWMODE) controls
the frequency with which the receiver writes to the image trails and makes image trail audit available
to the updaters. With FASTUPDATEMODE OFF, the default value, the receiver buffers the audit
sent by the extractor and writes those buffers out to the image trails at the most convenient time.
This ensures that RDF can achieve the highest possible extractor-to-receiver throughput, but it does
delay the updaters in how quickly they are allowed to read and apply the audit to the backup
database. One can typically observe updater RTD times cycle from 1-20 seconds, although it may
only take an updater a fraction of one second to apply 20 seconds worth audit.
With FASTUPDATEMODE ON, as each receiver receives an extractor message, it buffers all the
audit sent in that message by the extractor, writes those buffers immediately to the image trails,
and then immediately makes that data available to the updaters. Depending on the value of the
UPDATERDELAY attribute in the global RDF configuration record, the updaters can then read the
image trails and apply the freshly written audit to the backup database immediately, thereby
keeping updater RTD times to the lowest possible value. Because the receiver writes the audit
immediately to the image trails after processing each extractor message, having FASTUPDATEMODE
set ON can also impact extractor-to-receiver throughput.
140 Critical Operations, Special Situations, and Error Conditions