sql vs Nativ read delet ...

[ILEMax]

Ich fürchte das ich mich wiederhole
Es sind 9 Dateien.
3 kleine mit bis zu 5000 Sätzen,
6 große mit 1.000.000 - 15.000.000 Sätzen.

Der update findet minimum 0 maximum ca 150 Sätze.
Schätze im Schnitt 40-50 (in den großen Dateien)

So sehen ALLE 9 SQL Befehle aus

/EXEC SQL
+ UPDATE $FOTIP2 SET $AWKAR = 'D', $ADNEW=:HEUTE, $ATNEW=:JETZT
+ WHERE $AKEY8 = :N7A AND $AKEYE = :N1
/END-EXEC

Key der Datei: $akey8 und $akeye und (hier) 3 weitere Felder
(:heute und :jetzt = Numerisch 8 und 6, Datum jjjjmmtt und Zeit hhmmss, auch in der Datei)

Wie kannst du das optimieren?

Der ILEMax

[Fuerchau]

Die Frage ist, was der Optimzer dazu im Joblog (unter Debug) zu meckern hat.
Ob die Variablen in der Ausprägung zum Schlüssel passen....

[BenderD]

Ich fürchte das ich mich wiederhole
Es sind 9 Dateien.
3 kleine mit bis zu 5000 Sätzen,
6 große mit 1.000.000 - 15.000.000 Sätzen.

Der update findet minimum 0 maximum ca 150 Sätze.
Schätze im Schnitt 40-50 (in den großen Dateien)

So sehen ALLE 9 SQL Befehle aus

/EXEC SQL
+ UPDATE $FOTIP2 SET $AWKAR = 'D', $ADNEW=:HEUTE, $ATNEW=:JETZT
+ WHERE $AKEY8 = :N7A AND $AKEYE = :N1
/END-EXEC

Key der Datei: $akey8 und $akeye und (hier) 3 weitere Felder
(:heute und :jetzt = Numerisch 8 und 6, Datum jjjjmmtt und Zeit hhmmss, auch in der Datei)

Wie kannst du das optimieren?

Der ILEMax

... vielleicht bin ich ja begriffsstutzig, 60.000 * 50 reads plus die gleiche Menge updates in der Stunde, das sind pro sec. 1666 elementare db Operationen, für RLA auch kein berauschender Wert, aber noch plausibel.
Wenn ich dasselbe in der gleichen Logik mit SQL mache, sprich: lesen mit cursor und update per current of cursor, dann wäre für mich 1 millisekunde pro elementare Operation grenzwertig (:= net schnell, aber kein Handlungsbedarf, falls Durchsatz ausreichend). Macht man dasselbe per Bulkoperation, also 50 updates mit einem SQL Statement (so verstehe ich das, was Du da machst), dann sollte SQL schneller sein.
Wenn es dann aber um den Faktor 27 langsamer ist, dann besteht da ein hebbares Problem, von der Art fehlender Index oder vermeidbarer cast - in jedem Fall sollte da bereits STRDBG vorher und ein Blick in das Joblog ausreichend Info liefern.
Ganz unabhängig davon, könnte man den Durchsatz mit SQL, durch Parallelisierung der Anforderungen, deutlich über den RLA Wert steigern können (es sei denn die Maschine pfeift auf dem letzten Loch).

D*B

PS: falls die keys für die where clause aus der DataQ kommen, könnte man eventuell sogar mehrere SQLs zu einem (mit where in subselect) zusammenfassen. Auch das hat einiges Potential. Das wichtigste ist allerdings die Index Frage; da könnte es schon helfen, wenn Du mal das Joblog eines exemplarischen Zugriffs hier einstellst.

D*B

[hel400]

... wieder einer der Mythen: für SQL gilt das Kohl Prinzip (wer den Dicken nicht kennt: entscheidend ist, was hinten rauskommt!). Wenn ein SQL Statement durch Umformulierung schneller wird, hat der Query Optimizer einen Bug!

Also wie jetzt ???

Das Forum ist voll von brauchbaren SQL Beschleunigungs-Tipps, nur 2 Beispiele
ein Praxistipp von Hrn. Fürchau (Beitrag #2)
http://newsolutions.de/forum-systemi...6333#post96333

oder im gleichen Thread von Hrn. Bender selbst (Beitrag #4):
http://newsolutions.de/forum-systemi...6333#post96333

Warum muss dann jetzt plötzlich der Optimizer kaputt sein ???

[andreaspr@aon.at]

... wieder einer der Mythen: für SQL gilt das Kohl Prinzip (wer den Dicken nicht kennt: entscheidend ist, was hinten rauskommt!). Wenn ein SQL Statement durch Umformulierung schneller wird, hat der Query Optimizer einen Bug!

Jaja die böse IBM die böse DB2. Teilweise hast du ja recht, teilweise aber übertrieben. Wenn man all deine Postings zusammenfasst glaubt man, dass die IBM i die so ziemlich schlechteste Wahl ist die man treffen könnte. Da frag ich mich schon warum du in diesem Umfeld noch tätig bist?
(Ist jetzt kein Angriff, oder böse gemeint, sondern würde mich und sicher viele andere auch wirklich interessieren!!)

Zurück zum Thema:
In solchen Fällen wie von mir schon hin und wieder beschrieben sehe ich es nicht als Bug. Der Optimizer ist halt nur nicht Optimal
Und ich habe schon oft SQLs umstrukturieren müssen, um größere Performance gewinne erziehlen zu können. (Natürlich auch mit entsprechender Index Strategie)

In Oracle haben wir z.B. das Problem dass der "Optimizer" für das gleiche Query einmal den entsprechenden Index benützt und einmal wieder nicht.
Und das macht wirklich probleme. Ist im übrigen kein unbekanntes Problem bei Oracle!
Aber solche Diskussionen hatten wir hier auch schon zu genüge.