RDF/IMP and IMPX System Management Manual (RDF 1.3+)

Managing RDF
Compaq NonStop™ RDF/IMP and IMPX System Management Manual—522204-001
5-23
Access to Backup Databases in a Consistent State
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
(20JUN2000 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, 2000, you would issue this
command through RDFCOM:
RDFCOM; STOP UPDATE, TIMESTAMP 21JUN2000 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 shuts down because it has reached a commit/abort
record generated after the specified timestamp, it logs the following shutdown message
to the EMS event log:
785 Redo pass ending on reaching timestamp timestamp.
Because some audit data will not have been applied, the updaters must reexamine that
audit data when they restart. Consequently, when restarting the updaters after a STOP
UPDATE to a timestamp, the initial RTD times of the updaters will be greater than the
duration of time they were actually stopped.
The example that follows illustrates the effect of a STOP UPDATE, TIMESTAMP
command. In the example, tn indicates a transid, and the timestamp below reflects the
time of most recent commit or abort record in the audit trail.
RDFCOM; STOP UPDATE, TIMESTAMP 20JUN2000 12:00
commit update update update update update update commit update update commit commit
t0 t1 t2 t3 t1 t2 t3 t1 t2 t3 t2 t3
11:50 11:50 11:50 11:50 11:50 11:50 11:50 11:59 11:59 11:59 12:01 12:02
The updater applies the updates associated with t1 because that transaction committed
before the specified timestamp. It does not, however, apply the updates associated with
t2 and t3 because those transactions did not commit until after the specified timestamp.
The updater does not actually shut down until it encounters the commit record for t2