Home page Home page Home page Home page
Pixel
Pixel Header R1 C1 Pixel
Pixel Header R2 C1 Pixel
Pixel Header R3 C1 Pixel
Pixel
By apk | Friday, 4 May 2012 20:45 | 0 Comments

Problems in the Revelation world seem to be like buses. You don't hear about something for years, then in 2 days you receive 5 questions on the same topic. Right now, that topic seems to involve overflow frames.

We were thinking about overflow frames in regards to selects, and why some files, especially larger and more active files seem to have excessive amounts of overflow. We decided that, if you really think about it, the file is suffering from the laws of unintended consequences. Suppose you have an active file, in which you are creating new records frequently. Also suppose you are also issuing frequent non-index based selects on this file. As you know, when selects are issued against a file, the sizelock is increased to prevent the file from expanding or contracting. This means whenever a workstation is issuing a select, any new record written to the file is probably going to go into overflow, even if that write would have created a new group.

What this tells us is that large amounts of overflow in heavily used files do not indicate any problems with the hashing algorithm, but actually result from the resize hold placed against the file.
Pixel
Pixel Footer R1 C1 Pixel
Pixel
Pixel
Pixel