RE: Backups taking longer after reorg

Richard,

Depending how your journaling is setup, your receivers could be large.

Record images . . . . . . . . . *AFTER *AFTER, *BOTH

Did you run the command I posted, find the receivers related to your reorg?.
DSPOBJD OBJ(*ALL/*ALL) OBJTYPE(*JRNRCV)

You might also have other security software that is monitoring the PF, they could journal receivers also.

Paul



-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Richard Reeve
Sent: Friday, January 08, 2016 2:46 PM
To: Midrange Systems Technical Discussion
Subject: Re: Backups taking longer after reorg

I am still confused as to why a reorg (after all indexes were rebuilt) would cause the backup time to be axtended. I expected to see the backup time reduced. What am I missing? Should I delete the journal receivers ( or ommit them from the backup)? Would an IPL help. What about a RCLSTG?
If I do a RCLSTG, does the system need to be restricted?

FWIW - the slow response is because I'm at a funeral. I appreciate everyone's willingness to help.

Rich
On Jan 8, 2016 2:19 PM, "CRPence" <crpbottle@xxxxxxxxx> wrote:

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=nas277597ac9d26bea1486256a9
4007661d7
]
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.

--
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.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

--
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.

Please contact support@xxxxxxxxxxxx for any subscription related questions.