Dave,

After making sure that the set has enough entries to be a performance
problem in the first place, I usually take a look at 'max blocks'.  This
column's values are often quite revealing in master dataset performance
issues.

Max Blocks is the greatest number of physically adjacent, completely full
blocks in the dataset.  Since IMAGE records that can hash to a unique
location perform better, one should strive for a relatively low max blocks
value  (so that new entries will be able to find an empty spot without
having to cruise through thousands of 'occupied" entries).

In the case of AC-CLAIM-NUMBERS, before the reblock, 'max blocks' was 5192
and had a blocking factor of 2 (10384 consecutively occupied entries);
after the reblock max blocks was 258 with a blocking factor of 40 (10320
consecutively occupied entries).  That is not much gain in performance.
After the 'repack' it was 150 (Blocking factor 40), or 6000 records that are
consequetively occupied -- not so great either.

(A note should be made here that hashing masters' capacities should be
monitored for performance and that the sets should never be allowed to
reach a 'full' state.  In most cases, DBPUT performance will deteriorate as
the dataset approaches 85% full.  As a rule of thumb on hashing masters, we
often suggest changing their capacities to 65% load factor when they reach
80% load factor.)

IMAGE is usually very predictable -- if the load factor is near 70%, the
percentage of secondaries will be in the 30% range with a relatively low
number of 'max blocks'.   The problem arises when a new entry hashes to the
area of the dataset involved in the 'max blocks'.  The new entry will
either have to look serially for a free location, or it will dislodge a
secondary which must look for a new location.

Since your load factor is in the 40% range, the high value in your max
blocks column is an anamoly.  It may be due to a small sub-item length (4
for instance as in x4) or a rather high sub-item length with not much
uniqueness in the actual search field values.  You may want to see Fred
White's papers regarding the various Bears of IMAGE at
http://www.adager.com/TechnicalPapers.html

In either case, Adager can probably help you. Please contact us, and we can
analyze the situation and should be able to make some recommendations that
will bring the 'max blocks' value down significantly.

Thank you,
 _______________
|               |
|               |
|            r  |  Patrick                   [log in to unmask]
|          e    |                            http://www.adager.com
|        g      |  Patrick Mullen
|      a        |  R & D Labs / Technical Support
|    d          |  Adager Corporation
|  A            |  Sun Valley, Idaho 83353-3000             U.S.A.
|               |
|_______________|

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