Re: Reorg while active

I second Larry on this - you can do it online while users are working, be not afraid, but expect increased system load.

We have some monitoring files which usually have between 0.8 and 1.8bln records and 20-50% of deleted records,
so reorg is a good idea - but we do have 4 Cores and 256GB RAM for this 20 files, so it is not an issue.

If you're in doubt, use the iACS reorg function and monitor the progress. Do not expect the progress
percentage counter to run linear - if you cancelled an online reorg before, the first some % do go rather
fast while the rest of the reorg can need a significant amount of time. The preparation phase can do
need some hours - expect on large files this process can run over night and impact your
night batch processing or backup.

Also be aware of:
* maintaining the LF also depends on their size and make - your disk I/O will increase
* keep backup in mind while reorganizing - good test for your system performance ;-)
* depending on your QPFRADJ system value the QZDASSINIT job runs with varying priority
drawing some CPU
* If you use transactional based system mirroring (journal based) like Maxava, BUS4i etc,
you maybe want to exclude this file from mirror while being reorganized - there is a good
chance you'll need to keep an eye on your disk.
* avoid reorganizing multiple files the same time. It can be done if your business partner
sold you an appropriate machine.
* last but not least - sometimes, applications do use ALCOBJ *exclusive - you can imagine what might happen...


Best regards,
Mit freundlichen Grüßen
Holger Scherer

IBM Champion 2022
IBM Community Advocate
POWERbunker.com - your IBM i bunker

Am 18.10.2022 um 17:43 schrieb Larry DrFranken Bolhuis <midrange@xxxxxxxxxxxx>:

I have customers that do this routinely on files with 9 digits of rows.

Pretty much the two things two know are to specify NOT to rebuild the access paths or they'll get rebuilt when an application touches them, and that's bad. The alternative is to maintain them. Yes that slows it down but means users can access data.

The second thing is pay attention to the journal receiver size and quantity. You'll generate a LOT of entries so set the receiver size small, and delete them once detatched from the journal.

Or you could remember that "I sell Disk." ;-)

As an FYI if you run this through ACS instead of green screen batch job you get a VERY nice status of where it's at and how it's progressing.