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

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

Each updater maintains a file status table to keep track of the files it has open. An updater closes
any database file that has not been updated recently. Updaters also close database files when a
STOP RDF or STOP UPDATE command is issued, or when the updater restarts because of error
conditions. Additionally, if you alter the updater's OPENMODE while UPDATE is ON, then the
updater closes all its file and then reopens them with the new OPENMODE.
An updater process can have up to 3000 files open simultaneously. When it has the maximum
number of files open and needs to open another file, it first determines if there are any files that
have not been accessed recently and closes just them; if all of the open files have been accessed
recently, then the updater closes all of them before it continues processing. For the SMF
ramifications of this file limit, see the note in
“Using SMF With RDF” (page 65) .
REDO Pass
Updaters perform REDO operations during all normal processing. The updater applies each
audit record as a redo operation, regardless of whether the transaction associated with that audit
record committed, aborted, or is still in progress on the primary system.
The updaters apply all audit records to their data volumes regardless of whether the associated
transaction has committed, has aborted, or is still in progress. If a transaction commits, each
updater involved in the transaction applies all audit associated with that transaction and associated
with its protected volume to its corresponding UpdateVolume on the backup system. If a
transaction aborts, the updater applies all application-generated audit followed by all TMF
Backout-generated audit - all with REDO operations. For those who are familiar with audit record
formats, updaters always apply the after-images when performing Redo operations.
UNDO Pass
Updaters perform an UNDO pass over the image trail during final processing of RDF takeover
and stop-update-to-time operations. This is because data already applied to the backup database
must be undone if the associated transaction(s) did not commit prior to the start of the takeover
operation or prior to the specified timestamp.
For takeover operations there are three phases of undo: local undo, file undo (if file-incompletes
from the primary system are still unresolved), and network undo (if you are operating in an RDF
network). For stop-update-to-time operations there is only local undo (file-incompletes cause
abend, and network undo is not supported).
If an updater encounters a multi-block operation on the primary system that aborted, then the
updater also enters a special UNDO pass while it searches for the start of the aborted multi-block
operation, and it undoes any audit associated with the aborted transaction in order to guarantee
all aspects of the aborted transaction are undone from the backup database.
For those familiar with audit record formats, the updater applies before-images when it performs
UNDO operations.
Restart Information
RDF has a CONTEXT file in which each updater process maintains a context record. A context
record specifies the position (referred to as the restart position) in the image trail where the
updater was at the last context save point. All data for the associated data volume in the backup
database prior to the specified restart position is safe on disk (has been applied to the backup
database).
If an updater detects a restartable error, it restarts. Upon being restarted, an updater reads its
context record and restarts processing in the image trail at the specified restart position.
Partitioned Files, Alternate Key Files, and Indexes
Each updater is responsible for applying audit data to partitions corresponding to the volume
on the primary system that updater is protecting. Updates are applied directly to the specific
48 Introducing RDF