Re: estimating RGZPFM runtime

[Charles Wilt <charles.wilt@xxxxxxxxx>]

Rob,

I'm pretty sure they are always in sequence...but hopefully one of the
journal gurus will jump in and confirm or deny. :)

Charles


On Tue, Nov 19, 2013 at 11:19 AM, <rob@xxxxxxxxx> wrote:

> I would think that a before/after image would be in very close proximity.
> Granted there's no guarantee that they will be consecutive in a high
> volume environment.  Right?  However, I would think they would be close
> enough together that you would not be able to fit a reorg between them.
> Active or dedicated.
> Sequence  Code  Type  Object      Library     Job         Time
> 24706634   R     UB   ITEMMSTR    ROB         ROBS1       11:12:05
> 24706635   R     UP   ITEMMSTR    ROB         ROBS1       11:12:05
>
> IDK how you activate these fields
> Logical unit of work :
> Transaction ID . . . :
> or if they would help your tying it all together.
>
> Sorry about the farm the journals.  I thought you were dumping them
> another file for perceived easier processing.  Must have been another
> poster...
>
> 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:   "Stone, Joel" <Joel.Stone@xxxxxxxxxx>
> To:     Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> Date:   11/19/2013 11:04 AM
> Subject:        RE: estimating RGZPFM runtime
> Sent by:        midrange-l-bounces@xxxxxxxxxxxx
>
>
>
> You lost me at your first statement.
>
> I am thinking that you HAVE to rely on RRN when processing the journals.
> How else can you compare the BEFORE & AFTER images and be sure that you
> are comparing the same entity?
>
> When I say "farm the journals" I am referring to the same thing you are
> doing; ie "read the journals".
>
>
>
> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx [
> mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
> Sent: Tuesday, November 19, 2013 8:36 AM
> To: Midrange Systems Technical Discussion
> Subject: Re: estimating RGZPFM runtime
>
> 1 - We journal like crazy and use it to audit transactions.  We do not
> rely upon RRN.  Then again, we read the journals - not some journal farm
> created by processing the journals.
> 2 - Reorg while active, or reorging while not active, will have the same
> effect.  RRN's are going to change.  You may want to consider the one
> poster's idea about disabling the journal during the reorg.  Modify his cl
>
> by adding your journal farm request right before the reorg, if you still
> want to stick with your journal farm.
> 3 - If you can adapt your train of thought to accept the RRN change
> associated with reorganization you might want to consider reuse deleted
> records.  The only difference being is you can snapshot your journal farm
> around the reorgs, not around the reuse.
> 4 - You may want to consider the KEYFILE parameter of RGZPFM.  This can
> help your performance on reading.  Use the DB tools to see the most
> popular index or suggested index.
> 5 - If you do start using reuse deleted records, and the number of deleted
>
> records doesn't get terribly skewed, then you should never have to do a
> dedicated RGZPFM.  For example, if you're going to have roughly the same
> number of deleted records every night due to some process you may as well
> not try reorging to get the disk space back since it will need it again
> the next night.  However, if you recently discovered that you're dropping
> from retaining 15 years of history to just 2, then by all means, reorg to
> get the space back.  Or one oopsie runaway job really stuffed it full of
> garbage you cleaned out, then reorg to get that space back.
>
> Trying to duplicate the reorg on a different lpar, test library, etc can
> be a terrible waste of time.  Unless you're very certain all things are
> equal:  memory, disk, controllers, current load on system, etc.  Well,
> normally your second setup is less powered than your primary so it may
> show you 'worst case'.  Keep in mind that some indexes may be configured
> for delayed rebuild and be doing that in the background so you'll have to
> check out some system tasks for that to see when it's 'really' done.  But
> if you do the duplication by some process that inherently does a reorg,
> like certain options of CPYF or CRTDUPOBJ, then your results will again be
>
> quite skewed.
>
>
> 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:   "Stone, Joel" <Joel.Stone@xxxxxxxxxx>
> To:     Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> Date:   11/18/2013 04:24 PM
> Subject:        estimating RGZPFM runtime
> Sent by:        midrange-l-bounces@xxxxxxxxxxxx
>
>
>
> How can I estimate down-time required to RGZPFM a file?  Is there a
> utility or rule-of-thumb on these?
>
> Can it be killed if not completed OR will the file then be compromised?
>
> Thanks!
>
>
>
> ______________________________________________________________________
> This outbound email has been scanned for all viruses by the MessageLabs
> Skyscan service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________
> --
> 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 inbound email has been scanned for all viruses by the MessageLabs
> SkyScan
> service.
> ________________________________________________________________________
>
> ______________________________________________________________________
> This outbound email has been scanned for all viruses by the MessageLabs
> Skyscan service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________
> --
> 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.