An extent is nothing to be concerned with. They are not cause to perform a reorganize of the data; in fact a single reorganize request may even /pad/ the file with additional extents. The /extent/ is just a word to describe that more storage was allocated to hold more rows. Extents obtained during run-time are expensive [as impact in waits, to other jobs using the member], because effectively all activity to the dataspace is stopped while the extent is being added. When the database detects that there are multiple extents being added [over a short period of time, for example,] according to some algorithm, extra extents will be added than if the request were just the first in a day to add a few rows because there were no available extents in which to place those rows. It is the /extra/ extents that sometimes people will waste their [CPU] time reclaiming the storage via RGZPFM, but it is silly, because presumably the file will get more rows into those pre-allocated extents, so they will not have to be obtained at run-time; thus costing the reorg time *and* the run-time extent impact.

When it is known that a member will have 10M rows added for example, if that member is created or changed to have its final number of rows pre-allocated [existing plus those to be added], then no extents will be needed during the addition of those rows.

Regards, Chuck

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].