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

Stable Access” (page 141) in Chapter 5. A stop-update-to-time operation typically includes an undo
pass to back out any updates the updaters may have applied for transactions that did not commit
by the specified timestamp. Any transactions backed out are reapplied when you issue the next
START UPDATE command.
If you issue the STOP UPDATE command without the TIMESTAMP option, the RDFCOM prompt is
not returned until all updaters have stopped. If you include the TIMESTAMP option, then the RDFCOM
prompt is returned immediately since the stoppage is required to be at least 5 minutes in the future.
See also the discussion on RDF states displayed by the STATUS RDF command in this chapter as
well as in the section "Displaying Current Configuration Parameters and Operating Statistics" in
Chapter 4.
Updaters cannot always respond immediately to a STOP UPDATE command. If an updater has
audit records queued for the disk process, the updater must wait until all of that information is
processed before it can shut down.
If you erroneously set the timestamp too far into the future (for example, 26NOV2009), the only
way to correct this mistake is to enter a STOP RDF command, restart RDF, and reenter the STOP
UPDATE command with the correct timestamp.
If all protected data volumes on the primary system are not up and enabled when the specified
TIMESTAMP is reached, both the stop-update-to-time operation and the RDF product abort. In such
a case, you can restart RDF immediately but you should not reissue the stop-update-to-time command
until all protected data volumes on the primary system are up and enabled.
Examples
To suspend updating activities and stop the updater processes, enter this command:
STOP UPDATE
To suspend updating activities and stop the updaters from processing transactions committed by
2:30 P.M. or later on January 20, 2004, enter this command:
STOP UPDATE, TIMESTAMP 20JAN2004 14:30
TAKEOVER
The TAKEOVER command puts the backup database into a consistent state with regard to transaction
boundaries, after which it can become your new database of record.
TAKEOVER [!]
If you omit the ! option, then RDFCOM attempts to reach the primary system to verify that it is
indeed inaccessible. If it is able to reach the RDF monitor and extractor on the primary system,
then the TAKEOVER command is immediately aborted. If the primary system is inaccessible, it then
prompts you to confirm that you really want to execute the takeover. The reason for both tasks is
to allow you to be certain you are not mistakenly issuing the TAKEOVER command.
If you include the ! option, then the step to access the primary and the prompting are both omitted
and the takeover operation proceeds immediately.
NOTE: If you include the ! option and the primary system is still accessible, then the TAKEOVER
command may very well put your backup database out of synchronization with the primary
database. Therefore you should only include the ! option if you are absolutely certain you want to
proceed unequivocally with the takeover operation.
Where Issued
Backup system only.
Security Restrictions
You can issue the TAKEOVER command if you are the member of the super ID group that initialized
RDF.
RDFCOM Commands 243