"Friedrich Harasleben" <[log in to unmask]> wrote:

> A batch job which used to run for about 30-45 minutes (stores data in an
> image detail with about 3.200.000 entries) runs now 4 hours and longer
> to handle the same amount of data.

Others have suggested problems with synonyms in master data sets, but
Friedrich says he is adding entries to a large DETAIL data set.  In that
case, if I experienced a sudden dramatic increase in run time, the first
thing I would look for would be very long sorted chains, and a recent change
in the item being used as the sort item.

When DBPUT inserts a new entry in a sorted chain, it does a backward search
beginning at the last entry.  That works fine, as long as most new entries
have to be inserted near the end of the chain.  If a change in the values of
the sort items causes new entries to have be inserted near the beginning of
the chain, then every DBPUT is going to cause almost the entire chain to be
read.

For a five-year-old example, suppose your average chain length is 50,000
entries, sorted on date, and you are still using 6-digit dates, format
YYMMDD.  All goes well, with most new entries being inserted at or near the
end of a chain, up until 991231.  As soon as 000101 rolls around,
performance suffers big-time, with each DBPUT having to do a backward
chained read through about 50,000 entries.

For a more realistic example, imagine long chains with Purchase Order Number
as the sort item.  All goes well as long as newer P.O. numbers are higher
than old ones.  Then you order new pre-printed purchase orders, and the P.O.
numbers are rolled back to 000001.

Long sorted chains are to be discouraged, of course, but they could explain
this kind of sudden change in throughput.  Just a thought.

Walter

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *