DataLoader/MX Reference Manual (G06.24+)

DataLoader/MX Reference Manual—525872-002
7-1
7 Recovery Strategies
This section discusses strategies for planning DataLoader/MX run scenarios so that if
you experience a failure during the load operation, you will be able to rerun
DataLoader/MX and successfully load your database.
This section describes:
•
Why Is Recovery Important? on page 7-1
•
Defining Load on page 7-1
•
Design Time Considerations on page 7-2
•
Some Basic Rules on page 7-2
•
Simple Recovery Approaches on page 7-3
•
Potential Problems on page 7-3
•
The Two Main Approaches on page 7-3
•
Batch Totals on page 7-7
•
Multiprocess Considerations on page 7-8
•
Parallel Considerations on page 7-8
Why Is Recovery Important?
The contents of a database are crucial. To ensure that data is valid, it must be loaded
accurately, whatever its source. Loading a database can be a one-time activity or part
of a daily, weekly, or monthly job schedule.
As with any process, there is always the possibility of failure, that of software,
hardware or power, which can occur at any time during batch loading. You must plan
for recovery from these failures in a way that maintains the validity of the databases.
Creating a plan that works reliably and efficiently is a challenge. Many databases are
too large to be backed up before running a batch load job. Therefore, you must build
recovery possibilities into your load strategy.
Defining Load
The term load is used for all kinds of DataLoader/MX applications. To load a database
is to populate it in one of three ways:
•
Start with an empty table and write rows of data.
•
Append rows to a table that already contains data.
•
Start with a table that contains data, and then amend its data by updating some
rows, appending some rows, and even deleting rows.
In this discussion, loading refers to loading new information into the database in the
third way. Some of the new information takes the form of new rows, some takes the
form of updated rows, and some takes the form of deleted rows.