Zero Lost Transactions (Zlt); How It Works - HP NonStop RDF J-series RVUs Management Manual

17 Zero Lost Transactions (ZLT)

Zero Lost Transactions (ZLT), functionality that is available only with the RDF/ZLT product,
ensures that no transactions that commit on the primary system are lost on the RDF backup
system if that primary system is downed by an unplanned outage. RDF achieves this though the
use of remote mirroring for the relevant TMF audit trail volume(s). That is, one mirror of an
audit trail volume remains local to the primary system, but the other mirror is located at a remote
standby site.
When a primary system is downed by some unplanned outage or disaster, there might be some
audit data that the extractor on the primary system was unable to send to the backup system
before the outage. With ZLT functionality, RDF fetches all remaining audit data from the remote
mirror, thereby guaranteeing no loss of committed data during the RDF takeover operation.
If a remote mirror is not available at the time of the outage, ZLT functionality cannot be
guaranteed. ZLT functionality can be guaranteed only if you enable the TMF CommitHoldMode
capability on your primary system by including the COMMITHOLDMODE parameter in a
TMFCOM ALTER AUDITTRAIL command. When CommitHoldMode is enabled, TMF suspends
all commit operations if a remote mirror fails. For information about using the TMF
CommitHoldMode capability, see
Manual.
If all of the remote mirrors are functioning, ZLT functionality has no impact on normal RDF
operations. If you must perform an RDF takeover operation, however, there are additional steps
involved that can lengthen the time to perform the overall operation. In return, you get the ZLT
guarantee of not losing any transactions that committed on the primary system. When
CommitHoldMode is enabled and a remote mirrors fails, all active transactions are prevented
from aborting or committing. That dramatically impacts transaction processing on your primary
system. For more about this situation, see

How It Works

One mirror of each audit trail disk volume is removed to a remote location from the local mirror.
The distance is limited by the chosen disk technology and acceptable communications latency.
Thus, each audit trail volume is still mapped to a mirrored pair of disks, but one of the disks is
physically removed. For the remote mirror, an alternate cable must be present so that this mirror
can be attached to a standby system in the event of a takeover. That standby system can be either
the backup system itself or a separate system geographically removed from the primary and
backup systems. If you are using a separate standby system, it must be connected to the backup
system by way of Expand lines (of unlimited length).
Figure 17-1 shows the configuration where a single system serves as both the standby and backup
systems, and the remote mirror is located at the standby/backup site.
"Using CommitHoldMode" (page 340)
"Using CommitHoldMode" (page
and the TMF Reference
340).
How It Works 337