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.
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