Re: extents

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