Determining A Valid Inittime Value; Special Considerations; Enscribe Create Records; Stop-Rdf-Updater Records - HP NonStop RDF J-series RVUs Management Manual

Determining a Valid inittime Value

When using the INITTIME parameter without the NOW clause, it is important that you specify
a valid inittime value.
To do so, first issue a STATUS RDF command and take note of the highest updater RTD time.
Then round that RTD time up to the next higher minute (0:43 becomes 1:00, 1:27 becomes 2:00,
3:04 becomes 4:00, and so forth). Finally, subtract that rounded-up time from the current system
time shown in the status display.
inittime := (current-system-time — rounded-highest-updater-RTD-time)
RDFCOM then subtracts an additional three minutes from the specified timestamp. This is to
ensure that the extractor's starting position is at a point in the MAT where RDF had previously
sent audit records to the backup system and the updaters had applied it to the backup database.
This practice guarantees that no audit record is lost during initialization.
When you include the INITTIME parameter in the INITIALIZE RDF command, RDFCOM initiates
a backward scan of the MAT searching for the first commit or abort record whose timestamp is
less than the specified inittime . When RDF is subsequently restarted, some of the audit records
will be reapplied to the backup database. This does not cause any inconsistencies between the
primary and backup databases, but rather ensures that they stay completely synchronized with
one another.
CAUTION:
current date and time. The NOW value should only be used in a situation where you have
configured a reverse trigger and the INITIALIZE RDF command is used for reversing the direction
of RDF. For more information see

Special Considerations

When using this form of the INITIALIZE RDF command with a timestamp specified with
INITTIME, there are three special cases that you might encounter.

Enscribe Create Records

If the previous version of RDF performed an Enscribe create operation on the backup system
prior to execution of the INITIALIZE RDF command and the extractor's restart position in the
audit trail precedes the location of the Enscribe create record that an updater previously applied,
then, when you restart RDF and the updater tries to apply the create record, it will report a File
System error 10 (File Already Exists) and you must purge the existing file. The updater will
continue to report the error until you have purged the file.

Stop-RDF-Updater Records

Stop-RDF-Updater records in the master audit trail (MAT) are associated with committed NonStop
SQL DDL operations performed on the primary system with the SHARED ACCESS parameter.
Although such operations can be performed on the primary system without stopping your
applications, they must be performed manually on the backup system after all updaters have
shut down in response to the same Stop-RDF-Updater record.
As a general rule, you should not initialize RDF to an inittime if you recently performed a
NonStop SQL/MP or NonStop SQL/MX operation with SHARED ACCESS on the primary system.
For example, suppose you have a NonStop SQL/MP or NonStop SQL/MX table (tableA) that
contains the range of keys A through Z and you just moved its partition boundary such that
tableA now contains only the keys A through M and a new table (tableB) contains the keys N
through Z. Suppose also that you performed this operation manually on the backup system.
If you then initialize RDF to a point in the MAT prior to the Stop-RDF-Updater record associated
with the partition boundary change and an updater encounters audit records associated a key
N through Z, the updater will report an error because it will try to apply the audit record to
The NOW clause of the INITTIME parameter causes RDF to be initialized at the
"Example" (page 236).
Initializing and Configuring RDF 81