Re: Sever pulling a bazillion rows from IBMi via JDBC (I think)

Patrik:

If the target of the operation is off IBM I (I may have misread that) then the specifics of the task change, if not drastically, but the substance does not. Building indices is very expensive.

By expensive I mean in resource usage, some of that CPU, some of that Memory, and most of it is I/O (read and write) and the I/O channels used. Even Fibre can be maxed out at 6Gb or 8Gb, and more rarely at 16Mb.

Since the source of the data is IBM I , then the most important part of the question is: Are there proper indexes built to support the query. The aforementioned tooling in ACS will assist in determining that. Visual Explain has an amazing ability to show what the system actually does, and suggest what might be done to mitigate the I/O of the query.
--
Jim Oberholtzer
Agile Technology Architects

On Sep 3, 2025, at 7:00 AM, Patrik Schindler <poc@xxxxxxxxxx> wrote:

Hello Jim,

Am 03.09.2025 um 13:45 schrieb Jim Oberholtzer <midrangel@xxxxxxxxxxxxxxxxx>:

Again, that depends.

It always does. :-) Because the destination is unclear, I can only apply general advice.

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.
[…]

The destination database is not IBM i, as far as I've understood. The source is.

Not sure how much of your further hints are still relevant in practice, considering the increasing ubiquity of solid state memory vs. true DASD (Disk Arm Shaking Devices). Please note the word "practice". :-)

Creating an index is quite expensive, updating it less so usually.

Uhm. The goal set by the OP was to minimize run-time, not system resource consumption. I know the term "expensive" as another word for "resource intensive". What's your definition?

:wq! PoC

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.