Re: Backups taking longer after reorg

On 08-Jan-2016 09:26 -0700, Mike Cunningham wrote:

<<SNIP>> We do a similar process once a week as part of our backup.
Look for files with deleted records, save the current file to a
special library as a save file, do the reorg and then backup the save
files. If needed we could then restore the file from before the reorg
and apply journal changes to that to get back to a set point.

To Remove Journaled Changes (RMVJRNCHG) to get back [without having the reorg as /show stopper/.? Apply Journaled Changes (APYJRNCHG) would require a copy that was saved post-reorg to have been restored from the _prior_ backup.?

It is interesting that for years we have had an issue where a backup
on Monday night will take longer than a backup on Tuesday-Sunday
nights. Tried lots of things to try and find out why but never did
solve it. It's about 20-30 minutes longer for us and does not impact
operations so we just went on to other more pressing issues.

Presuming the RGZPFM\file-save work is done preceding the Monday backups:

The file-data [in the dataspace and the dataspace indexes] from the reorganize activity will have monopolized the memory. Fast-path data copy [fast copy] and Access Path rebuilds are memory-aggressive, as contrasted with other typical activity, causing fewer objects to remain paged. Thus the typical already-paged objects from normal activity [as seen on other days without that maintenance preceding backups] would need to be paged into memory; many of those objects likely are brought into memory having been /faulted/ into memory rather than /paged/, where the former is a much more expensive operation than the latter.

For this same reason, but with different origin for the faulting, a backup after an IPL takes longer. However after an IPL there is also the effect from the /Object Checker/ for /first touch/ processing, for which extra validation is performed against each LIC object [which for a file can be from several to several thousand]. I know the database took steps to reduce faulting [at least] for multiple-member database files by storing a table of objects to page. IIRC the database had also taken some steps at one time to attempt to reduce first-touch for saves, such that if the first touch had not transpired before the dump-to-media phase, then the database\load-dump feature would not perform any first-touch processing.
[http://www.ibm.com/support/docview.wss?uid=nas277597ac9d26bea1486256a94007661d7]
Info APAR II12893 - SAVE TIME TAKES LONGER AFTER AN IPL
[http://www.ibm.com/support/docview.wss?uid=tss1wp100600]
How to Shrink your iSeries Backup Window - a Step by Step Guide
Reference #: WP100600

Perhaps moving the maintenance and individual file-save activity until post-backup [still within one logical process, presumably in effective restricted-state] would show a much lower impact, perhaps insignificant, on the next backup [on Tuesday, for which there is no preceding maintenance activity].? Of course that changes the normal backup copy of the file to be the pre-reorg version and the copy of the file in a save file on disk to be the post-reorg version, for which equivalent recovery\restore process changes would need to be made.

We may look into what happens if we stop doing the reorgs once a
week

Much easier than switching the order of the maintenance and backups to make that inference; if results from omitting the maintenance are positive, then a switch to the order of processing should be helpful as well, but of course with the cost of the process change.