Re: Backups taking longer after reorg

On 08-Jan-2016 07:47 -0700, Richard Reeve wrote:

I did a simple DSPFD to an OUTFILE and looked at the percentage of
deleted records to total. I did the reorg on those that had more
than 10% deleted.

Were files in QSYS omitted? If not, then is the DBXREF operating without error [see WRKACTJOB JOB(*SYS) for QDBSRVXR* jobs\joblogs, *SYSOPR message queue, and history log]?

All of the rebuilding of indexes is done but my backup time is still
30 minutes longer than it had been.

The "is done" and "still" are unclear; the former is present-tense, and there is no time-line to correlate the latter. When was the reorg activity run, and was the save started only after all the index rebuild activity had completed? A time-line might be helpful, to include the backup prior to the data maintenance, the backup(s) after that maintenance, and including the timings for each backup.

If possible, learning if a second consecutive backup takes the additional 30 minutes or is instead akin to the typical\prior backups would be somewhat telling.

Note also that a single Reorganize Physical File Member (RGZPFM) can effect *growth* of the member [and the access path sizes]. Without compaction or compression, the amount of physical media requirements can therefore grow to accommodate that object growth.

I am NOT using the Save While Active strategy.

I believe the pertinent question was about the use of Save *Changed* Objects (SAVCHGOBJ), not about use of SWA; the reorganized members [and thus each *FILE of those members] would all be marked as /changed/ objects after a RGZPFM request on a member.

I am doing an IPL tomorrow. Don't know what else to do.

While the effects from that PwrDwn\restart could be positive, without actually investigating the origin of the issue, the effects from not performing the IPL [and optionally burning incense and performing an animal sacrifice] could achieve the same effect; i.e. if the effect is different post-IPL, then that effect [perhaps better performing] for the backup could be viewed as correlation but the IPL should not be misconstrued as causation.

Any help is much appreciated.

If Access Paths are being saved [per the Save Access Paths (ACCPTH) parameter specification], then any keyed access path that was not valid prior to the reorg of the underlying data, since would have been rebuilt as valid; only a valid access path can be saved.

Having run a generic maintenance such as the noted reorganize activity, would have changed the typical in-memory aspects of normal [non-maint] system operations; a similar effect to what is seen for backups taken after an IPL but before the system experiences normal daily user activity. If the backup is run /soon/ after the maintenance then the performance characteristics often will be significantly different than if the backup is performed after a day or more of non-maintenance\normal activity.