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

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: The NOW clause of the INITTIME parameter causes RDF to be initialized at the 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 “Example” (page 224).
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 tableA
(which used to contain it, but now does not), and the audit record will not be applied to the backup
74 Installing and Configuring RDF