With sorted image trails, the activity of any one image file typically remains so low that it can
be stored on the same disk volumes as the main database with no significant I/O impact. This
approach is not recommended, however, if you require very high RDF performance or if RDF
is running with the UPDATE option turned off; in this case, the image trails could eventually
fill the volume; in such cases, it is best to have volumes exclusively dedicated to the image trails.
NOTE:
You should keep all image trail files off of the $SYSTEM volume and its controller.
Otherwise, if there is a lot of audit data to send from the primary system to the backup system,
it could take a while for the updaters to start.
Image trails can be added only after RDF has been initialized but before it has been started.
RDF Control Points
When the extractor has no information to send from the audit trail, it transmits a buffer containing
no audit images (an empty buffer) to the receiver. When the receiver process receives an empty
buffer, it generates an RDF control-point record in each image trail. Therefore, even when no
TMF transactions are generated on the primary system, RDF adds internal control points to the
image trail on the backup system. The file-filling rate for RDF control point records is very slow.
A receiver determines which updater will apply each audit record, and sorts the data into the
image trail used by that updater. The records in the image trails are subsequently used by updater
processes to update the backup database. Each receiver creates its own image trail files,
preallocates extents, initiates rollovers, and manages them, except for purging, a task performed
by the purger process .
The receiver also adds RDF control points to individual image trails if they have not received
new audit while other trails have. Thus, the image trails can appear to be growing in size even
though no transaction activity is taking place on the primary system. The primary importance
of RDF Control Points is that they are used to reflect accurate RTD times for the updaters when
new audit has not been added to their image trails for any period of time. They are also useful
for the coordination of other special operations.
RDFNET Process
The RDFNET process is a process pair that runs only on the primary node of the network master
in an RDF network. The RDFNET process creates synchronization information used only during
RDF takeover.
Updater Processes
An updater process is a process pair that runs on the backup system when updating is enabled
or during takeover processing. Every volume on the primary system that is protected by RDF
has its own updater process on the backup system.
Each updater reads the image trail to which it has been configured, looking for audit records
(image records) associated with the data volume it protects (it ignores audit records associated
with volumes protected by other updaters). When it finds applicable audit records, the updater
sends the audit records to the disk process to be applied to the backup database.
Each updater performs the following functions:
•
Reads large blocks of data from the RDF image file and searches for image records associated
with the updater’s volume on the primary system.
•
Opens and closes database files on the backup system for updating and maintaining the
backup database.
•
Defines restart points and updates restart information in the context file (named CONTEXT).
For an explanation of restart points, see
“Restart Information”
.
•
Sends information to RDFCOM for use in the STATUS RDF command display.
46
Introducing RDF
Содержание NonStop RDF
Страница 68: ...68 ...
Страница 186: ...186 ...
Страница 260: ...260 ...
Страница 278: ...278 ...
Страница 284: ...284 ...
Страница 290: ...290 ...
Страница 308: ...308 ...
Страница 322: ...322 ...
Страница 336: ...336 ...
Страница 348: ...348 ...
Страница 464: ...464 ...
Страница 478: ......