On Sep 3, 2025, at 6:21 AM, Patrik Schindler <poc@xxxxxxxxxx> wrote:
An even less resources wasting approach would have been to completely remove any indexes on the destination database, run the bulk inserts, and then create the desired index in one go. I presume creating an index from an existing table being more efficient than maintaining an index constantly with small changes happening very frequently.
</snip>
Again, that depends. First off, how many indexes are we discussing? Secondly are they designed correctly so the access paths can be shared, IE create the longest access path first then let the shorter ones use it. (Long key to short key). Another factor is disk space. Each write to the storage is 4K. That must be continuous storage. So does storage management need to move things around in the storage pool to create the space for the insert?
Creating an index is quite expensive, updating it less so usually.
The first step is as has been suggested already, look at the SQL performance data. Maybe an index created or removed would help. It’s all there to look at. (Since about V7R3, and more and more in succeeding releases)
Performance tools can also help, but not as much as the SQL tooling.
--
Jim Oberholtzer
Agile Technology Architects
midrange.com
