Availability Guide for Application Design

Data Protection and Recovery
Availability Guide for Application Design—525637-004
4-28
Solution Using Low-Priority Transaction Processing
to Perform the Batch Function
online function requiring no operator and are able to execute concurrently with online
processing.
What Are the Design Implications for the Transactional
Model for Batch Programs?
Consider the size of the unit of batch recovery. The simplest approach is to have a
single transaction that processes the entire batch job. This approach, however, is
undesirable for several reasons:
•
Some event might cause this large transaction to abort when it is almost finished;
rolling back the database and rerunning such a large transaction is a major
inconvenience and will likely disrupt business operations.
•
Large portions of the database could be locked until this large transaction commits,
denying online users access to the data they need.
•
It is difficult to configure TMF correctly, because you do not know how large future
instances of the transaction will be.
The other extreme performs one transaction for each database record written. This too
is undesirable because of the overhead involved. A compromise lies somewhere in
between, where you can take advantage of packing multiple records into a single buffer
and committing them with one transaction without suffering the inconvenience of long
transactions. Some possible methods to set your unit of recovery are:
•
Counting input/output operations
Using a counter, you can specify that each transaction consists of a specific
number of input/output operations. In this case, the unit of recovery is, at most, a
full count of input/output operations.
•
Using a key range
Upon choosing a densely populated key—for example, a purchase order number—
your program can set the size of the transaction by processing records within a
specific key range for each transaction. In this case, the unit of recovery is never
larger than the key range.
•
Using transformation phases
Converting data from a source database to a target database might involve several
phases. Each phase (except the last phase) puts its output onto a transaction-
protected queue. The next phase takes its input from the queue, does its part of
the transformation, and writes its output to another queue. Each phase makes up a
single transaction; the unit of recovery is, at most, one phase.
You can mix this technique with counting input/output operations or with using a
key range to break each phase into smaller portions.
With any of these techniques, it is critical that you save sufficient context—record
values, counters, batch status, and so on—at the beginning of the transaction in order