OI 9.11 soon to be 9.2.

I have an index that the indexer freezes on. Looking at the UDH manager I can see that serveral records remain locked. It looks like a "hidden" error occurs and leaves records locked which is freezing the indexer on the next go round.

After clearing the locks and restarting the indexer I attempted to remove the index on the particulare field. It is taking an unusually long time to remove the Btree. UDH manager shows FIELDS from the dictionary and *INDEXES from the !bang file.

Any idea what its doing and how to remove the index from this field?

Thanks,

John

Ok it looks like I didn't wait long enough… However, something just doesn't feel right. I decided to look at the LH Info screen and the !bang file has 762294 records with 127053 frames. This translates into a Primary Frame percent of 127. The threshold is set at 80% and the sizelock is 0.

Question, how could a file get past the threshold?

I would assume that this is the reason for the long delays. It appears to be in the process of adding frames very slowly though.

Ideas?

Threshold isn't an absolute value. When the limit is reached and the opportunity is right the file will get adjusted to bring the file within the threshold. This normally happens during an active select when only one workstation is accessing the file. If it is a busy file the table may never have the opportunity to be resized.

Your question brings up another question. What about index tables that are never actively selected?

The apparent slow response is something I've encountered and a way to check for that behavior involves using SysInternals ProcessMonitor. The utility allows you to watch the service as it accesses the .LK/.OV files. After a period of activity statistics can be generated to determine how much time was spent accessing .LK or .OV files.

Looking at the service's file activity in a time ordered list could reveal an initial read from the .LK and numerous reads from the .OV just to fulfill the one request. Theoretically re-hashing the file should place more of the data base in the .LK so it is more efficient to access.

There are some instances where this method falls apart. For example, if one commonly accessed record is exponentially bigger than the other records in the table. Regardless of how the table is hashed reading the larger than average record will always incur several accesses to the .OV file.

I'm planning to write a KB article on using ProcessMonitor to watch the LinearHash service for this type of issue. I'll let you know when it is completed.

Thanks Jared,

It's good to know there isn't something seriously wrong. Please let us know when the KB is available.

John

View this thread on the Works forum...