Re: File Size not as expected

On 29 Jul 2013 11:43, Anderson, Kurt wrote:

This is the info (specifically looking at size) of a file that I
duped and added a record to.

... Deleted
Member Size ... Records Records
CDRMISCP 12288 ... 1 0

This is the info (again, look at size) of a file that had millions of
records, where I deleted all but the first, then ran RGZPFM.

... Deleted
Member Size ... Records Records
CDRMISCP 2473984 ... 1 0

The file was created with SQL. File definition:
EditID INTEGER NOT NULL DEFAULT 0,
CDRSeq# INTEGER NOT NULL DEFAULT 0,
MiscCode Char (5) NOT NULL DEFAULT ' ',
MiscValue VarChar (100) ALLOCATE(30) NOT NULL DEFAULT ' ',
StmDte Date NOT NULL DEFAULT '0001-01-01'

Is there a reason why the given information for the 2nd file has the
file size so much larger?

We're on IBM i 7.1.

No mention was made of the specific invocation of Reorganize Physical File Member, so the defaults are presumed. The ALLOCATE attribute of the file was not shown; that and the SIZE can be very relevant.

Regardless, RGZPFM defaults in balance, to enable better future I/O performance over fully minimizing space. The reorganize needs to be run a second time to reclaim both the Variable segments and the /reserved/ space; i.e. space that was not fully truncated with the first request given the expectation by the DB that the file likely will be used again to have new records added and thus a new /extent/ should be avoided for the next INSERT; first since the Rgz.

Also note that depending on whether /SQL fast delete/ was put in effect for the DELETE activity, the size of the dataspace could be drastically different than as compared to when non-SQL or SQL-non-fast-delete effected the delete activity from the file member. Deleting /all but the first row/ could, depending on the ability of the DB to recognize the cardinality of the deletion as a percentage of the overall number of records, cause the fast-delete to be utilized.