sql vs Nativ read delet ...

[andreaspr@aon.at]

Also bei SQL gibt es immer einen gewissen Overhead den es bei Native I/O nicht gibt.
Deshalb kann SQL durchaus "langsamer" sein.
Wobei wir hier in bereich von milli sek. sprechen, wenn eben z.B. der Zugriffsplan erstellt wird.

Wenn ich ein SQL sehe welches zu langsam wäre, vergleiche ich nicht ob es mit Native I/O schneller wäre, sondern analysiere warum es langsam ist (fehlende Indice, schlechte struktur des SQL Statements, usw.).

Ich habe auch einmal eine Client Anwendung in der 10.000de INSERT INTOs gemacht wurden.
Dies sollte beschläunigt werden und sebst bei einem simplen INSERT INTO mit VALUES konnte ich eine Performance steigerung durchführen nachdem ich die Struktur des SQLs geändert habe.
Sowas ist aber nur notwendig wenn man um jede milli sek kämpfen muss/möchte.

Ich glaube man muss bei Grundsatzdiskussionen etwas genauer hinschauen.
Meist (wenn nicht nahezu immer) geht es darum, dass Kollegen, sich in der Native I/O welt wohler fühlen als mit SQL.
Und dann kommt jemand daher und will einem aus der "Wohlfühlzone" reisen.
Da holt man jedes Argument was nur irgendwie möglich ist um sein Weltbild zu verteidigen.
Wenn man erkennt wo das eigentliche Problem liegt, und die diskussion dahingehend lenkt, so kann man (davon bin ich überzeugt) die beiden Seiten viel besser zusammen bringen.

[BenderD]

...sondern analysiere warum es langsam ist ...schlechte struktur des SQL Statements... konnte ich eine Performance steigerung durchführen nachdem ich die Struktur des SQLs geändert habe.

... 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!

[Fuerchau]

Was bei Inserts nicht zu verachten ist sind die Anzahl zu verwaltender indizes.
Man kann diese ggf. deaktivieren und hinterher aktivieren.
in Summe ist der (partielle) Neuaufbau von Indizes über mehrere parallele Jobs schneller als die Inserts mit aktiven Indizes (gemeinsame Erfahrungen mit D*B).

[ILEMax]

Ich habe nun den Aufwand betrieben und aus dem Pgm mit

do *hival
qrcvdtaq
Update Datei set w1=:a, w2 = :b, w3=:c where key1=:key1 and key2 = :key2
9 *mal auf verschiedene Dateien mit 5.000-18.000.000 Sätzen
enddo

ein Pgm mit 9 mal

Setll
read
dow not %eof
eval
update
read
enddo

zu machen


das SQL schaffte im schnitt 2.200 Dataq Sätze in der Stunde
Native schafft 60.000

Blamabel!

Fazit: (wie D*B schon erwähnte)
Sql ist leichter und schneller programmiert, aber definitiv NICHT für alles geeignet

Der
ILEMax

[Fuerchau]

Blamabel ist das eher nicht sondern hier fehlt die Analyse warum dein SQL so langsam ist.
Ggf. machte dein SQL einen tablescan weil dein Index für RPG einen Select/Omit enthält und dieser deshalb nicht verwendet wird.
Ein Faktor 30 ist da eher inwahrscheinlich. Ein Faktor nahe 1,1-1,2 sollte erreichbar sein.

[ILEMax]

Ich gebe zu, das ich das nicht untersucht habe.
außer der strdbg - weg hab ich da nicht soviel Kenntnisse.

Sicher ist, das auf den gekeyten PF max. 2 LF liegen, kein LF mit select / Ommit ist und
es für jede Datei einen passenden Key gibt.
Dieser ist jedoch i.d.r. länger (mehr als meine 2-4 Key Felder)

[andreaspr@aon.at]

Ich gebe zu, das ich das nicht untersucht habe.
außer der strdbg - weg hab ich da nicht soviel Kenntnisse.

Welches Release habt ihr?
Hast du aus dem Joblog heraus sehen können ob der entsprechende Index genommen wurde?
Hat er den ODP wiederverwendet?

Wenn du ein DB Monitoring startest kannst du da viel mehr informationen herauslesen.

[ILEMax]

7.1 nahezu alle PTF
ODP wurde wiederverwendet, das stand so im Joblog.
Ob er die Indexe genommen hat weis ich nicht, ich hab's ja nicht weiter untersucht.

Wenn du ein DB Monitoring startest kannst du da viel mehr informationen herauslesen.

Da müßte mich mal einer für ne halbe Stunde an die Hand nehmen.
Jede Menge Halbwissen und eine gehörige Portion Unsicherheit in verbindung mit ständigem Zeitdruck
sorgen dafür, das ich da bisher nicht ran gegangen bin.

[andreaspr@aon.at]

Es gibt ja Möglichkeiten externe Schulungen zu besuchen oder auch Angebote für Inhouse Schulungen anzufordern.
Hier im Forum sind auch einige die dir das Anbieten können.
Je nachdem wo du dich befindest könnten auch 1 Tages Inhouse Schulungen kostengünstig gemacht werden.
Ich z.B. betreibe hauptsächlich Inhouse Schulungen beim Kunden.
Bei Birgitta kannst du auch bei externe Schulungen teilnehmen.

Wie mal ein Finanzexperte gesagt hat:
"Die besten und sichersten Investitionen sind die Ich-Investitionen" (also investieren in Ausbildung)

[BenderD]

das SQL schaffte im schnitt 2.200 Dataq Sätze in der Stunde
Native schafft 60.000

> 1 sec pro Eintrag und Faktor 27, da sollte man erst mal nachsehen, wo die Zeit bleibt.

16/sec für native, da stellt sich auch schon die Frage, wo da die Zeit bleibt - wie viele Datenbankoperationen stehen dahinter? Auch da ist durchaus Optimierungspotential zu vermuten; am Ende könnte eine SQL Lösung da schneller sein!!!

D*B

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