RDF System Management Manual for H-Series RVUs (RDF 1.8)

Reading the Backup Database
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 in the next topic, 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, you should open the backup files with
SHARED READ-ONLY access.
Access to Backup Databases in a Consistent State
Because the RDF updaters work asynchronously with respect to one another and to transaction
boundaries, when you use the backup database as a read-only resource you are almost always
accessing an inconsistent database.
One way to ensure that the backup database is in a logically consistent state with respect to
transaction boundaries is to stop TMF on the primary system (requiring that you first bring down
all protected applications). For most customers this is unacceptable except under the most extreme
circumstances.
A timestamp parameter is provided in the STOP UPDATE command to allow you to stop the
updaters on the backup system at a consistent point without affecting TMF or any applications
on the primary system.
The format of the timestamp parameter is the same as that used for RDF initialization (20JUN2004
12:48, for example). When you include the timestamp, its value must be based on the time of
your primary system and must be at least 5 minutes in the future. The updaters will apply all
audit associated with transactions that committed prior to the timestamp you specify. Any audit
that was committed at or after your specified timestamp is not applied. When you issue the next
START UPDATE command, the updaters will apply any audit they could not apply previously
because that audit was associated with transactions that were not committed in time for the
STOP UPDATE, TIMESTAMP command. For example, if the current time on the primary system
is 11:30, and you want to bring the backup database to a stable state that includes all transactions
that were committed before noon on June 21, 2004, you would issue this command through
RDFCOM:
140 Managing RDF