Tuning the hash index

From m204wiki
Revision as of 22:06, 4 April 2013 by Rob (talk | contribs) (Created page with "==Monitoring Table C== To monitor Table C, use the CRETRIES parameter and the TABLEC command.Their use is discussed below. === Using CRETRIES in Monit...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Monitoring Table C

To monitor Table C, use the CRETRIES parameter and the TABLEC command.Their use is discussed below.

Using CRETRIES in Monitoring

The page retry statistic (the CRETRIES parameter) is provided. Each retry indicates a slight degradation in indexed retrieval speeds. Far more significantly (given the limitations in hoe Table C may be increased), page retries are a signal that Table C is becoming crowded.

Although these figures vary from file to file, experiments have produced results similar to those in the following diagram. (This from a small file with CSIZE = 10).

As shown above, page retries usually are not significant when utilization is below 70 percent. At approximately 72 percent, the number of retries begins to grow more rapidly as utilization increases (new KEY values are added). The point at which retries sharply begin to increase is 80 percent; at 90 percent the slope further increases.

A rough guideline for users concerned with access performance is to aim for 75 percent utilization. If space is the only constraint, you should be able to achieve 85 percent utilization. Remember that this figure varies depending on the characteristics of the data.

Table C never can be 100 percent utilized. A Table C full condition may happen at any point after utilization reaches 85 percent.

Because of this uncertainty, Rocket Software encourages users to strongly consider the use of the Ordered Index as a replacement for the hashed index. This can be done without code changes. See Indexing files for more information.


Using the TABLEC command in Monitoring