RDF/IMP and IMPX System Management Manual (RDF 1.3+)

Introducing RDF

Compaq NonStop™ RDF/IMP and IMPX System Management Manual—522204-001

1-28

RTD Warning Thresholds

RDF/IMP and IMPX allow you to designate a pair of RTD warning thresholds: one for

the extractor, and another for all of the updaters. Having set those thresholds, you then

can issue a STATUS RTDWARNING command with a designated repeat interval to

display information and statistics for only those processes (the extractor or any updater)

that have fallen behind the configured RTD threshold. For information about setting the

RTD threshold, see the SET RDF

command description.

Support for Network Transactions

As of version 1, update 2, the RDF/IMPX product supports network transactions:

transactions that update data residing on more than one RDF primary system.

In the past you could execute such transactions, but the RDF product could not

guarantee database consistency among the associated backup systems following the

failure of one of the primary systems.

More specifically, the updates for a transaction on one of the two primary systems may

have been successfully transmitted and applied to the associated backup database, but a

disaster brought down the other primary system before the updates by the transaction on

that system could be sent to its backup database. After executing RDF takeover

operations on both backup systems, the data from the network transaction would be

present in one backup database but not in the one brought down by the disaster. Thus

the distributed backup database is inconsistent with regard to the affected network

transaction.

For information about this capability, see Section 13, Network Transactions

Lockstep Operation

Lockstep operation, which is available with the RDF/IMPX product, prevents an

application from executing further processing based on a committed business transaction

until all audit associated with that transaction is safely stored in the image trails on the

backup system.

This is accomplished by means of a new procedure, named DoLockstep, that you call

immediately after calling

endtransaction. With this lockstep protocol, the business

transaction is actually committed on the primary system prior to the start of the

DoLockstep operation, but the application is not allowed to continue processing until

DoLockstep has returned status to the application.

For information about this capability, see Section 14, Lockstep Operation