R
Richard Banville
Guest
I have seen the phenomenon you describe in the past as well. It can be overshadowed by increasing the create limit as you describe. However, in the case you describe, the parameter to change is the toss limit not the create limit. In your case, your tosslimit should be around 400 for the table with the average record size of 396. There have been many discussions explaining the ins and outs of create and toss limits so I will not go into that here. After your initial load, the rm chain for this table was probably really long with little space left in each block - you could see this with a proutil chanalys output. When production ran, it filled in many of the "holes" or more appropriately use the free space scatter among blocks on the free chain. Most likely one record per block. The other assumption is that your primary index is your most frequently used index for the queries you need to run the best since that is the one you dumped and loaded by. This is not the case for all applications. For instance, if you customer table has cust-num as the primary index, you may lookup customers frequently by cust-num, but that is a random lookup. If you run your reports or complicated queries "by some other field", then that may be the index you want for the D&L.
Continue reading...
Continue reading...