RDF System Management Manual for H-Series RVUs (RDF 1.8)

RDFCOM; STOP UPDATE, TIMESTAMP 21JUN2004 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 following example 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 20JUN2004 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 (12:01). As soon as it encounters
a commit or abort record whose timestamp is greater than the specified timestamp, the updater
will have processed all audit data for transactions that committed or aborted up to the specified
timestamp. Thus, the database is in a completely consistent state with regard to transaction
boundaries.
The updater keeps track of the first record it could not apply because its transaction committed
or aborted after the specified timestamp. In the preceding example, the updater’s restart position
in the image trail will be the first update record for t2. Thus, when restarted, the updater will
backtrack to that record. This practice ensures that no audit data is lost during the STOP UPDATE
to a timestamp operation.
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 173).
RDF and NonStop SQL/MP DDL Operations
When certain Data Definition Language (DDL) operations are performed on NonStop SQL/MP
tables protected by RDF, applications that depend on these operations are briefly denied access
to the database while the DDL operations are in progress. These periods of unavailability,
commonly called outages, end when the DDL operation completes.
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/MP DDL operations that can be performed WITH SHARED
ACCESS, see the SQL/MP Reference Manual.
RDF and NonStop SQL/MP DDL Operations 141