Reorganize large Physical files

[surisimha]

Hi,

There is a PF with total number of records greater than 300000000. This PF has two logical files each having one member. This file needs to be re-organized every week. Currently it's taking more than 1 hour to do so. Now RGZPFM on the file takes place (which took more than 1 hour to complete)

I tried the following approach, thinking that it would reduce the time.

a. RMVM (two logical files having one member each), - this took less than 1 minute to execute
b. RGZPFM - this took 10-15 minutes to execute
c. ADDLFM - this took more than 2 hours to execute

But it took more than 2 hours to complete.

Can someone help me in reducing the time to re-organize the file?

Thanks,
Suri

[gcraill]

Re: Reorganize large Physical files

Can you change the file to re-use deleted records and therefore reduce the weekly number of deleted records ?

[tomholden]

Re: Reorganize large Physical files

first off i would have to ask the obvious question...why does it have to be reorganized weekly? (personally anytime i see something like that i immediate assume there's a flaw in the design and 99% of the time i'm correct...) i think that IF this is simply to compress/remove deleted records i would do a one-time reorg then use Greg's suggestion of changing the file to reuse deleted records (yes i know there'll be some overhead the first time the file is loaded again but the deleted records from that load will remain and be reused on the next load process). still i have to question if there's something amiss with the application design. i've worked on some complex and quite large systems and i have never seen a process than loads in excess to 30 million records within a week (well unless it's an audit log and in that case using a journal would seem a better choice IMO)

[FaStOnE]

Re: Reorganize large Physical files

As a suggestion on when you do reorg the file:

Use the RBDACCPTH(*OPTIMIZE) option. I have a table with 32 Million+ records with over 50 logicals (Vendor specified, not mine!). It does not re-use deleted records and I have to reorg it now and then (maybe once/twice a year). Originally, this reorg took over 7-8 hours with all the logicals. Now, it reorgs in less than 2-3 hours.

It might help a little .. but, I agree with Greg and Tom ... if you can, Re-use Deleted records.

[BenThurley]

Re: Reorganize large Physical files

30 million records in a week is easily achieved. Imagine a large telephony company with a file for usage. How many customers would you need to get 30 million calls in a week?

[tomholden]

Re: Reorganize large Physical files

30 million records in a week is easily achieved. Imagine a large telephony company with a file for usage. How many customers would you need to get 30 million calls in a week?

how many of those calls will you purge on a weekly basis? even if it's roughly the same number reuse deleted is even a better option rather than purge, reorg, rinse & repeat on a weekly basis.

[gcraill]

Re: Reorganize large Physical files

how many of those calls will you purge on a weekly basis? even if it's roughly the same number reuse deleted is even a better option rather than purge, reorg, rinse & repeat on a weekly basis.

We were hitting well over 5 times that figure weekly a few years back. But I agree with Tom, the design meant we didn't have any reorgs on them, so it had 0 impact.