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

Because the updater may have applied some audit for transactions that had not yet committed at
the specified timestamp, it then executes an undo pass to undo those specific records. For the undo
pass, the purger builds an undo list based on those transactions that the updaters need to undo,
the updaters read this list, and they read backwards in the image trail, performing logical undo
operations on those records that need to be backed out.
The following example illustrates the effect of a STOP UPDATE, TIMESTAMP command. In the
example, t+number 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 20JUN2004 12:00
commit update update update update update update commit update commit update commit
t0 t1 t2 t3 t1 t2 t3 t1 t2 t2 t3 t3
11:50 11:50 11:50 11:50 11:50 11:50 11:50 11:59 11:59 12:00 12:00 12:01
The updater applies all image audit until it reaches the last update for t3 because this image record
contains the timestamp of the last commit record seen by the extractor when it sent the record to
the backup system, the commit of T2, and the updater ends its redo pass here because this timestamp
is greater than or equal to the specified stop time in the STOP UPDATE command. Observe that
the updater has applied audit for T1, T2, and T3, but also observe that the transactions T2 and
T3 committed at or after the stop time. The purger builds the undo list to back out all audit associated
with transactions T2 and T3, and the updater then starts an undo pass to undo audit it had previously
applied for these two transactions. When the updater shuts down, the backup database is in a
completely consistent state and contains only data for transactions that committed before 12:00.
When the updater shuts down, it keeps track of the last record it undid - in our example it is the
first update for T2 at 11:50. Then, when you restart the updaters, the updater position to this same
record in the image trail and commences doing normal redo operations going forward. Thus, even
though the Stop Update to Time operation had caused some audit to be backed out, when you
restart the updaters, these updaters reapply all audit they had previously undone, and the database
stays in a state of synchronization with the database on the primary system.
If you erroneously set the timestamp too far into the future (for example, 26DEC3000), 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.
See also the description of the STOP UPDATE command in Chapter 8 (page 176).
RDF and NonStop SQL DDL Operations
When you must perform NonStop SQL DDL operations, many of these DDL operations require that
you stop your applications before performing those operations, while other DDL operations can
be performed online, without stopping your applications, by using the SHARED ACCESS option.
Because RDF does not replicate NonStop DDL operations, you must carefully coordinate performing
any DDL operation to ensure that the tables and indexes on your backup system stay in
synchronization with those on the primary system.
When you perform NonStop SQL/MP DDL operations such as the following, you can either include
or omit the WITH SHARED ACCESS option:
• The CREATE INDEX statement, used when creating an index on a table
• The MOVE clause of the ALTER TABLE or ALTER INDEX statement, used when moving, splitting,
or merging disk file partitions, or when moving boundaries within partitions
To determine all of the NonStop SQL/ DDL operations that can be performed WITH SHARED
ACCESS, see the SQL/MP Reference Manualand the SQL/MX Reference Manual.
When included, the WITH SHARED ACCESS option specifies that the DDL operation is to allow
concurrent read-write Data Manipulation Language (DML) access and read-only utility access to
the objects on which it operates during all but the final phase of the operation. For this reason,
operations specifying the WITH SHARED ACCESS option are sometimes referred to as Online DDL
operations.
142 Critical Operations, Special Situations, and Error Conditions