Re: impact of deleted records

On 30-Jun-2014 15:45 -0500, Krill, Coy wrote:

CRPence on Monday, June 30, 2014 11:31 wrote:

On 30-Jun-2014 12:17 -0500, Krill, Coy wrote:

<<SNIP>> I have a 300GB+ file that is replicated and the bulk of
the file is deleted records. Unfortunately it's always locked and
in use for an online banking system and I would love to reorg it
without having to take down our online banking.
It's also one of those files that cannot be set to reuse deleted
records due to the way it's processed.

If a physical database file has a requirement that prohibits the
attribute REUSEDLT(*YES), then the file is also likely prohibited
from having the Reorganize Physical File Member (RGZPFM) performed
with the Allow Cancel (ALWCANCEL) [online\while-active]
specification in effect for that reorg request; i.e. the effects of
the ALWCANCEL(*YES) reorg request is quite similar to the effects
from use of the REUSEDLT(*YES) definitional attribute, whereby the
/Arrival Sequence/ is unlikely to be maintained.

I have to ensure the arrival sequence doesn't change, so it sounds
like this will not be an option for this file. I just happens to be
the largest file and have the most deleted records. Thanks for the
input!

Hmmm... In my prior response, I was thinking only of what I recall was the /better performing/ request, specifying the Replace Deleted Records option of the Key File (KEYFILE) parameter; i.e. RGZPFM KEYFILE(*RPLDLTRCD) ALWCANCEL(*YES)

Apologies... The less efficient compress-only capability still exists with the online\while-active RGZPFM request, with the KEYFILE(*NONE) ALWCANCEL(*YES) combination.

Note: the Rebuild Access Path (RBDACCPTH) likely should be set to no [RBDACCPTH(*NO)] in the described scenario [not the OP, but the oldest quoted message].

<http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_71/cl/rgzpfm.htm>