RDF System Management Manual

Managing RDF
HP NonStop RDF System Management Manual—524388-003
5-28
Access to Backup Databases in a Consistent State
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:
RDFCOM; STOP UPDATE, TIMESTAMP 21JUN2004 12:00