-----Original Message-----
From: John Pitman [mailto:[log in to unmask]]
Sent: Friday, September 24, 2004 3:46 PM
To: [log in to unmask]
Subject: RE: [HP3000-L] IMAGE Guru needed

Not many details live in isolation from any masters In my experience. I have
seen this before, where the detail has a newly allocated sequential key (eg
invoice number, patient number etc), and the problem was the synonym chain
length in the auto master on that key.
Expanding that master by 20% helped a bit, by 30% a bit more, by 50%, a huge
improvement, matching a plunge in synonym chain length.
It COULD be a sorted chain problem, so it does need research both ways. I
used HOWMESSY on the related masters to find the worst one, and worked on
that.

jp

-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]]On Behalf Of
Walter Murray
Sent: Friday, September 24, 2004 2:48 PM
To: [log in to unmask]
Subject: Re: [HP3000-L] IMAGE Guru needed

 "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.

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