Alfredo Rego <[log in to unmask]> wrote:
 
>For Fred White's thorough analysis of this pitfall, please read his classic
>paper, "The Use and Abuse of Non-hashing Keys in IMAGE."
>
>We'll be delighted to send you a copy.  Better yet, you can access the
>paper online through Adager's World-Wide Web site and print your own copy,
>either in HTML format or in PDF format with Acrobat reader.  Point your
>favorite browser from your favorite platform (Mac, any flavor of Windows,
>Unix, or what-have-you) to:
>
>        http://www.adager.com
>
>Go down Adager's home page to the section titled "How can you learn more
>about Adager?" and click on the link at "Study technical papers written by
>members of the Adager R&D team on all kinds of database-related subjects."
>
>Go down the technical-papers page to the section titled "By Fred White,
>Adager Senior Research Scientist."  There, you'll find the paper, "The Use
>and Abuse of Non-hashing Keys in IMAGE."  Choose either PDF (for Adobe
>Acrobat Reader) or HTML (for standard browsers) and BINGO!
 
Fred White's paper, "The Use and Abuse of Non-hashing Keys in IMAGE," and its
successor, "Integer Keys: The final Chapter," are excellent references for
handling non-hashing keys problems. However, clustering problems can also
occur with hashing keys when the percentage of secondaries is high enough.
 
It's not clear what kind of dataset(s) are involved in Gary Paveza's case.
If the dataset is a master, the problem may be caused by either a misuse of
a non-hashing key (integer), or by a hashing key. In this case, database
analyzers like Robelle's HowMessy will report both the percentage of
secondaries and the 'MaxBlocks' values for any master dataset. If the
dataset is a detail, the freeze may be caused by a sort key, as Mike
Hornsby pointed out.
 
My experience with hashing keys is that, if the secondaries are above 20
pecent, and the value for MaxBlocks is above two digits, the TurboIMAGE
applications may show performance degradation like the one described by
Gary Paveza. The common solution for this problem is to perform a capacity
change to a higher capacity. Most likely, however, the user will experience
similar problems soon after.
 
After reading Alfredo Rego's a paper "Do Migrating Secondaries Give You
Migraines?", I realized that the best and most practical solution to the
hashing key clustering problem is to periodically "repack" those master
datasets which show these symptoms. I have also seen that an Adager "Mastpack"
takes considerably less time than a master capacity change. This makes it
possible to do periodic MastPacks without "significant" down time. For
MastPack to yield good results the dataset must have enough 'breathing
space.' If the master dataset is too full (above 90 %), MastPack may not
yield the expected dataset performance improvement.
 
 
+---------------+
|               |
|            r  |  Rene Woc                       [log in to unmask]
|          e    |                           http://www.adager.com
|        g      |                                Tel 208 726-9100
|      a        |                                Fax 208 726-8191
|    d          |  Adager Corporation
|  A            |  Sun Valley, Idaho 83353-3000            U.S.A.
|               |
+---------------+