R
Richard Banville
Guest
I thought I answered that but I'll give it another go without the complete rmchain/createlimit/tosslimit dissertation. The rm chain maintains the free space used for record creation. When you do a load and the toss limit is not set appropriately, there will be many blocks on this rm free chain with just under 396 bytes (in your case). The blocks are scattered sequentially throughout the area. This can be proven with a chanalys run just after the load. These will not be used for the average record you are insertion (396), only for the "outliers" between 300 and 396. BTW, this will make your load time much longer too. This rm free chain after the load then contains a "list of holes" as you put it but it is really just a list of a bunch of blocks (many in your case I am guessing) that will be attempted to be used when inserting new records to this table during production. There are a list of reasons why the application can use these "holes" even if their average record size is 396, mostly due to when the actual record is created (due ro release, validate, txn scope, etc) and when the record becomes its final average size. As these blocks with free space for just one record are used, you will get the scattering affect you describe. So why are these holes maintained? It is just a list of free space that is to be used for new record creation. This list is goeverned by create and tosslimits. The storage engine does not maintain a running list of average record sizes for each table so you must tell it how best to maintain the rm free list for record insertion (it will work it you don't, it just won't be the most efficient). In your case, you would do this by setting your tosslimit for this table to 400.
Continue reading...
Continue reading...