×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 21-Mar-2012 20:32 , Mike Krebs wrote:
How does a SQL created table extend itself? A record at a time?
Because an algorithm determines the next dataspace extent size, there
is no one specific answer, although to be sure, the extents are not
"record at a time". There is a minimal extent, I believe based on the
effective [fixed-length] record size along with the expected number of
records to be added according to the current activity statistics for the
dataspace. There is a separate algorithm for extending the variable
segment(s)
So... An extent will /leave space/ for some number of additional
records to be inserted without another extent. The dataspace size, even
for a very simple format [e.g. RCDLEN(nbr)] may take significantly more
storage than would be calculated based on the number of rows, after a
large number of insert activity was directed to that file using
SIZE(*NOMAX); e.g. after being the target of a CPYF with many records.
Two consecutive RGZPFM [no allow-cancel] against a member with
ALLOCATE(*NO) should reduce the dataspace size to reclaim the allocated
but unused space; reduced to the minimal extent, IIRC. Of course unless
known there will be no additional rows added, a reorganize request is an
expensive operation to effect reclaiming a tiny amount of storage in
most cases, and impacts the performance of the next insert activity
if\when they occur because a new extent will be required. Note that
INZPFM has the option to allocate to the Next Increment, but that refers
to the "Increment number of records" element of the SIZE parameter, not
the next LIC extent; i.e. not allowed when SIZE(*NOMAX) is in effect.
For any one file, the extent size can be inferred by reviewing the
"Data space size in bytes" field MBDSZ2 from DSPFD for *MBR details
[QAFDMBR model output file] after each insert of one row. I just did
that for a five column [all char(100)] TABLE, and after the eighth row
inserted the dataspace size went from 12,288 to 20,480 bytes which
revealed as [probably the minimal] extent size, 8K. I then ran two
consecutive RGZPFM against the member, and the size remained 20,480
bytes, so I infer the minimal increment was 8092 bytes. That was done
on a v5r3 system.
The following messages and\or the other messages in the threads, may
have commentary of interest for the subject of this thread, and for the
question quoted in this message.
_i Subject: Re: Efficiency question on file extents... i_
http://archive.midrange.com/midrange-l/201202/msg00465.html
_i Subject: Re: PF data space management i_
http://archive.midrange.com/midrange-l/200803/msg01703.html
_i Subject: RE: Max Records in Physical or Printer Files i_
_i - To Max or Not To Max... i_
http://archive.midrange.com/midrange-l/200201/msg00653.html
Regards, Chuck
midrange.com
