I don't remember all the specifics, but we had to JRN the PF in order for REORG while active.
Good knowledge base docs on reorg while active.
631414267 Basics on Reorganize While Active
420665507 Explanation of the Records Found in the RGZPFM Status File
431878187 RGZPFM Frequently Asked Questions
28453658 Performance Suggestions for RGZPFM
590089723 Questions, Answers, and Tips on RGZPFM - Improving Its Performance
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Tuesday, November 19, 2013 9: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
______________________________________________________________________
As an Amazon Associate we earn from qualifying purchases.