Hi Chuck,
The RgzPfm was done with our defaults:
Member . . . . . . . . . . . . . *FIRST
Key file:
Logical file . . . . . . . . . *NONE
Library . . . . . . . . . .
Member . . . . . . . . . . . .
Rebuild access paths . . . . . . *YES
Allow cancel . . . . . . . . . . *NO
I ran RGZPFM a second time and it did reduce the size of the file. As a non-system guy, my thought is, "That's dumb." I don't have to run CLRPFM twice to clear the file. I'm sure there's a wonderfully valid reason for this, although it makes me wonder if every RGZPFM we have in our processes should be ran twice instead of once.
Thanks,
Kurt
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Monday, July 29, 2013 2:01 PM
To: midrange-l@xxxxxxxxxxxx
Subject: 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.
--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
