RDF System Management Manual for H-Series and J-Series RVUs (RDF 1.9)

Access to Backup Databases with Stable Access
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, meaning that you normally only have Browse access to the
backup database. The following discussions provide three means of achieving Stable access to
your backup database without having to perform an RDF Takeover operation.
Stopping TMF on the Primary System
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.
Using the STOP RDF, DRAIN Command
If you cannot stop TMF on your primary system, but you can stop the applications that are
updating your RDF-protected databases, then you can achieve STABLE access to the backup
database by performing the following steps.
1. Stop the applications that are updating your RDF-protected database on your primary
system.
2. Issue the RDFCOM STOP RDF, DRAIN command.
3. When RDF has shut down, it will have applied all committed audit for transactions that
completed on the primary system prior to stopping your applications in Step 1.
STOP UPDATE to a Timestamp
A timestamp attribute is provided with 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 attribute 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. For any
audit the updater may have applied prior to stopping its redo pass but where that audit is
associated with a transaction that committed at the stop time or after, the updater executes an
undo pass to back that audit out of the database. When you next restart the updaters, they begin
applying the audit that they had previously backed out during the undo pass. 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 are committed before noon on June 21, 2004, you
would issue this command through RDFCOM:
RDFCOM; STOP UPDATE, TIMESTAMP 21JUN2004 12:00
If the specified timestamp is not at least five minutes greater than the current time, RDFCOM
aborts the command and displays the following message:
The specified timestamp must be at least five minutes greater than the current time.
The STOP UPDATE command itself is logged to the EMS event log under the general RDF
message 835. As each updater reaches an audit record whose transaction committed at or after
the specified timestamp, the updater terminates its redo pass and logs the following RDF event
in the EMS log:
785 Redo pass ending on reaching timestamp timestamp.
Because the updater may have applied some audit for transactions that had not yet committed
at the specified timestamp, it then executes an undo pass to undo those specific records. For the
undo pass, the purger builds an undo list based on those transactions that the updaters need to
150 Critical Operations, Special Situations, and Error Conditions