|
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.
--
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.