RE: Backups taking longer after reorg

I don't think a reorg writes a lot to the journal. Just enough to prevent you from applying a journal change made prior to the reorg to a file from after the reorg. 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. 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. We may look into what happens if we stop doing the reorgs once a week

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Friday, January 08, 2016 11:00 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: RE: Backups taking longer after reorg

Also, when you do a WRKJRNRCV you can see if they are still active, and if they've been saved or not.

Does a RGZPFM really add that many journal entries?
I had a file just now I inserted a few out of order rows.
RGZPFM FILE(ROB/AAAKEY) KEYFILE(*FILE)
To sort the file.
There's only two journal entries. A partition level one and a table level one.

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: "Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'"
<midrange-l@xxxxxxxxxxxx>
Date: 01/08/2016 10:50 AM
Subject: RE: Backups taking longer after reorg
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



Richard,

DSPOBJD OBJ(*ALL/*ALL) OBJTYPE(*JRNRCV)

You can easily see the size of the journal receivers, especially those
related to your reorg
You must decide if you need to save them or not.

You have choices.

Paul


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

P10 running V7R1M0. Tape drive is 5746. I think you are on to something
with the journal receivers. If that turns out to be the issue, what are
my options?

On Fri, Jan 8, 2016 at 10:09 AM, Steinmetz, Paul <PSteinmetz@xxxxxxxxxx>
wrote:

Rich,

Can you supply more details for your environment, both system and
backup device used.
Are the PF you reorged journaled? Your journal receivers may be large
and you may be saving them, would explain the longer backup times.

Paul



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

All,

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. All of the rebuilding of indexes is done but my
backup time is still 30 minutes longer than it had been. I am NOT
using the save while active stragegy.

I am doing an IPL tomorrow. Don't know what else to do. Any
help is much appreciated.

Rich

On Sat, Jan 2, 2016 at 1:17 PM, Steinmetz, Paul
<PSteinmetz@xxxxxxxxxx>
wrote:

Richard,

Are you doing reorg or reorg while active?
We run a similar process using reorg while active.
Reorg will be quicker, but requires exclusive use of the files, and
I believe will cause the index rebuilds.
Reorg while active will be longer, users can remain on, index
rebuilds are less, done concurrently.

Paul

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

All,

First, let me wish everyone a happy new year. I hope that each
of you is blessed this year with good health and prosperity. Now to
my issue
- I wrote a program that scans through libraries and reorgs files
that have many deleted records. Sounds reasonable
enough.....However, since running this program, my backups are
running much longer. Why would this be? Is there something that I
can do to get the time needed to save these libraries back to a

reasonable timeframe?

I have considered saving the libs to a save file and making the
system available while backing the save files up to tape (which I'm
assuming would be faster given the I/o rate of disk vs. tape). But
I'm perplexed as to why the reorg would add time to my backup.

Any thoughts/suggestions are much appreciated.

Sincerely,

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

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

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

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