Why Online Reorg record counts increased?
Article ID: 268293
Updated On:
Products
Issue/Introduction
Why Online Reorg record counts increased? Online Reorg ran for 8 hours 24 min. I can’t explain though how we gained 7,438 ABC records and 8,084 DEF records.
ABC rows moved: 25,451,798
DEF rows moved: 31,800,061
Environment
Release : 15.1
Resolution
OLREORG runs as a subtask concurrently with application processing. From that 8hr time span, there is a good possibility that other work might have entered which would explain the increase. You can view what was added and deleted in the 8hr span by running a RXX report.
logging is required to run OLREORG because the LXX has to record each and every row that is moved by OLREORG. Every record is committed or when the move is complete. Another way of saying this is that OLREORG issues a checkpoint after every record is moved to completion. It is expected for the LXX to have lots of activity thus having to be prepared with automation that MUF might spill a few times.
The very first OLREORG on a table could take several hours to complete depending on the number of rows on the table and how badly the data are currently organized. You can always cancel the OLREORG job (or REQABORT) if you have other high-priority work to do, and then you can resume the reorg later. Since each moved row is a checkpoint, the point to where it was cancelled should be the mark on where it begins once you resubmit OLREORG depending on how long the previous job was ran and activity.
Feedback
