Zitat Zitat von franz77 Beitrag anzeigen
Ich habe das gestern und heute mit dem IBM Support diskutiert mit folgender Conclusio.

Beim Insert wird tatsächlich sowas ähnliches wie ein Tables-Scan gemacht. Das Visual-Explain zeigt dann halt Table-Scan an.
... der IBM Support war auch schon mal besser.

Was da so passiert, lässt sich leicht nachvollziehen:

Als erstes macht man das unter debug und sieht ins Joblog, wo man dann diagnostics der Query engine findet. Dort sieht man, dass - welch Überraschung - der insert erst mal einen open macht; am billigsten ist da ein öffnen nach Eingangsfolge (womit der visuelle Explain schon aus der Kurve fliegt - die Tools waren auch schon mal besser).

Als nächstes macht man ein STRDBMON TYPE(*DETAIL) und lässt erneut rattern. Dann sieht man sich das ganze an (mit SELECT QQTIME, QQSTIM, QQETIM, QQ1000 FROM ...)
da sieht man dann, dass erst mal ein Connect gemacht wird, dann kommt eine Stafette von Einträgen, die auch davon abhängt, was man da genau macht (static SQL, dynamic SQL, prepare once run multiple...). Die Zeit für den insert ist in dem Eintrag für den insert in Anfang Ende Timestamp komplett, inklusive prepare, dargestellt.

300 Millisekunden sind keineswegs in Ordnung, da ist was krumm - ob es sich rentiert danach zu suchen, hängt davon ab, ob es stört. Für elementare DB Operationen sind Zeiten von max. 1 Millisekunde typisch, auf schnellen Maschinen auch deutlich besser, auf schwächlichen Maschinen auch wenige Millisekunden. Auf einer meiner Spielzeugmaschinen waren es hier knapp 6 Millisekunden beim Erstaufruf, knapp 4 bei Folgeaufrufen (caching lässt grüßen)

Rekord Löffel ist für elementare Operationen immer schneller, egal wovon das IBM Marketing gerade träumen macht, ändern könnte man das, indem man den RLA langsamer macht.
Für komplexe Transaktionen hat SQL mehr Möglichkeiten zu cachen und kann seine Nachteile auch überkompensieren; in der Programmierer Performance ist SQL immer schneller, wenn vor dem Bildschirm ein Profi sitzt.

D*B

PS: SETOBJACC reduziert natürlich den verfügbaren Speicher und verdrängt erst mal anderes aus dem Speicher. Das reinpagen größerer Programme (auch der SQL runtime) ist auf einer AS/400 kein Renner (single level storage lässt grüßen). Knapper Hauptspeicher erklärt oft zähe Erstaufrufe.