HP NonStop RDF, Руководство по управлению

Страница: 151 / 478

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 187) .
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.
RDF and NonStop SQL DDL Operations 151