RDF System Management Manual for J-series and H-series RVUs (RDF 1.10)

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
“Using CommitHoldMode” (page 322) and the TMF Reference 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 “Using CommitHoldMode” (page 322).
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 13 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.
320 Zero Lost Transactions (ZLT)