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

For a complete discussion of FASTUPDATEMODE, see the description for this attribute under the
SET RECEIVER command in “Entering RDFCOM Commands” (page 176). While having
FASTUPDATEMODE turned on does give you read access to data freshly committed on the primary
system as soon as possible, please note that the option still only provides you with BROWSE access.
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.
Access to Backup Databases with Stable Access 141