We?re working on a huge file reorg project. We have a 17TB system that?s
over 75% full. We have determined we can get down around 50% by getting rid
of deleted records. Once we accomplish that, we'll change over to reusing
deleted records.
RMVM beforehand and ADDLFM afterward has always been the way to go to avoid
thrashing. But that was before the proliferation of SQL indexes.
:-)
Paul Nelson
Cell 708-670-6978
Office 409-267-4027
nelsonp@xxxxxxxxxxxxx
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
CRPence
Sent: Wednesday, June 29, 2016 3:15 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: RMVM for SQL index objects
On 29-Jun-2016 14:55 -0500, Paul Nelson wrote:
On 29-Jun-2016 14:40 -0500, Paul Nelson wrote:
Does anybody know the equivalent command in the SQL world?
That's probably it. If I add the index back after a file reorg, will
that set me up for level checks?
Ah. So the inquiry from the OP is regarding an intention to disable
the keyed Access Path (ACCPTH) [maintenance] during a Reorganize
Physical File Member (RGZPFM) against the underlying data?
So perhaps the AccPth of the INDEX is defined UNIQUE, thus preventing
changing the Maintenance (MAINT) attribute? In that case, the DROP
INDEX [or Delete File (DLTF)] can be used after a Save Object (SAVOBJ),
and the Restore Object (RSTOBJ) done afterward -- there could be two
restores, one first without the member, and then another to restore the
member, but there would be no point in so doing.
FWiW the ALWCANCEL(*NO) reorg will already disable a non-unique keyed
AccPth, and move the rebuild until afterward in an async runpty-52
QDBSRV## system job. And a non-unique AccPth could be modified with
Change Logical File (CHGLF) to set the Maintenance (MAINT) attribute to
the special value of *REBLD [¿possibly required?: in conjunction with
RECOVER(*NO)].
Maybe some background about the scenario, to help explain the
reasoning for the approach; perhaps discussion can lead to a different
path.?
midrange.com
