SQL zu langsam?

[Fuerchau]

Wie immer: die Methode ist entscheidend !

"insert into myfile (f1, f2, ...) values(W1, W2, ...)" führt auf jeden Fall zu folgender Aktion:
- Syntax-Check
- Prepare
- Execute
- drop Statement
- ODP's erkennt die AS/400 ggf. automatisch
Wenn ich dann ggf. auch noch jedesmal einen Connect-/Disconnect betreibe, wird auch jedesmal der Job verbunden/getrennt. Die Nutzung eines ODP's entfällt damit.

Seit V5R3 macht die AS/400 folgendes:
- Syntax-Check
- entfernen der Werte ersetzen mit "?"
- prüfen im SQLPKG, ob's das Statement schon mal gab
- a) Wiederverwendung
- b) Prepare
- Einfügen der Werte zum "?"
- Execute

Erheblich beschleunigen kann ich den Vorgang durch ein von mir vorher selbst vorbereitetes Statement:
"Insert into myfile (F1, F2, ...) value(?, ?, ...)"
- Prepare-Funktion aufrufen
- Parameter setzen
- Execute-Methode

Die AS/400 führt dann die Statements durch die Wiederverwendung direkt aus.
Der Syntax-Check entfällt (bzw. nur noch 1 Mal), das Statement bleibt im aktiven Job auch aktiv und muss nicht neu generiert werden (Resourcen).

Auch wenn das Connection-Pooling für Internet-Anwendungen sehr schön ist, sollte ich vom Design gut überlegen wann ich denn die Verbindung freigebe.
Habe ich vor, mehrere Daten zu schreiben, sollte ich die Verbindung erst trennen, wenn alle Vorgänge abgeschlossen sind.

Insbesonders wenn man doch mal mit Journalisierung und Transaktionen umgeht, verbietet sich das sowieso.
Ich sehe da auch keinen Unterschied zwischen JDBC oder ODBC/OLEDB, da AS/400-seitig immer der selbe Dienst verwendet wird. Auch für DRDA gilt das Gleiche, ausser das der Eingang ein anderer ist.

Bei SQL mit der AS/400 sollte man sich immer entsprechende Gedanken machen, da die Treiberseite meist PC-Optimiert ist und auf MS-Access/SQL-Server konzipiert wurde.
Dies betrifft insbesonders Update/Insert-Cursor auf Recordsets, die meistens von der AS/400 so nicht unterstützt werden.

[RobertPic]

...
Seit V5R3 macht die AS/400 folgendes:
- Syntax-Check
- entfernen der Werte ersetzen mit "?"
- prüfen im SQLPKG, ob's das Statement schon mal gab
- a) Wiederverwendung
- b) Prepare
- Einfügen der Werte zum "?"
- Execute
...

Hallo Fuerchau, sehr gute Erklärung. Da ich noch kein V5R3 habe, ein Frage:

Meiner Meinung nach, kann man diese Funktionalität auch schon bei V5R2 zuschalten.

bei ODBC: Extended Dynamic Support im ODBC-Treiber
bei JDBC: "extended dynamic=true" im Connectionstring

Gehe ich hier recht in der Annahme, oder gibt es unter V5R3 was ganz Neues?

Robert P.

[BenderD]

Hallo,

das wurde schon länger probiert, prepared Statements abzuleiten und zu cachen, was da neu gekommen ist, ist ein System weiter Cache, allerdings sind all diese Caches (auch der vom extended package suppport) zweischneidig. Bei schlechter Trefferquote, oder schwacher Implementierung, kostet die Sucherei mehr als alles andere. Bei JDBC gab es Treiberstände (?!) bei denen das katastrophal war; da hat das löschen eines packages manchmal Verbesserungen um mehr als den Faktor 10 gebracht.
Mit der ach so famosen neuen Query Engine braut sich wieder was zusammen, die macht keine temporären Indexe mehr (wird mit jedem V5R3 PTF sichtbarer), sondern macht dann halt full Table scans, mit steil ansteigendem Ressourcen Verbrauch.

mfg

Dieter Bender

@Baldur: zu den Inserts habe ich Einwände, die verwenden keinen ODP.

Hallo Fuerchau, sehr gute Erklärung. Da ich noch kein V5R3 habe, ein Frage:

Meiner Meinung nach, kann man diese Funktionalität auch schon bei V5R2 zuschalten.

bei ODBC: Extended Dynamic Support im ODBC-Treiber
bei JDBC: "extended dynamic=true" im Connectionstring

Gehe ich hier recht in der Annahme, oder gibt es unter V5R3 was ganz Neues?

Robert P.

[Fuerchau]

@Dieter
Da muss ich zumindest bei der Verwendung per ODBC wiedersprechen.
Die Datei, in die ich per Insert schreibe ist mit Status "O" eröffnet.
Also auch hier ist die Verwendung von Prepared-Statements aus Performancegründen durchaus sinnvoll.

Da ich nicht weiß, in wie weit der Java-Treiber benannte SQLPKG's unterstützt kann es da durchaus Unterschiede geben.

Um dem Problem der SQLPKG's aus dem Weg zu gehen, kann man mindestens beim ODBC-Treiber sein Paket in die QTEMP legen. Mit dem IBMDA400 gehts ab V5R3 auch.
Meine Erfahrungen mit dieser Methode sind durchaus sehr gut.

Was den Optimizer angeht teile ich deine Meinung.
Häufig genug wird ein Zugriffsweg vorgeschlagen der anschließend keine Verwendung findet, da der Optimizer den Tablescan immer noch für optimaler hält.
Das ist aber doch eher selten der Fall.

Da ich inzwischen doch einiges mit ODBC getestet habe, konnte ich mittels DEBUG-Modus die meisten SQL's wie gewünscht beschleunigen.

Ach ja, es gibt da noch einen kleinen Engpass:

Mangels Journalisierung werden Anwendungsdateien häufig mit FRCRATIO(1) angelegt.
Dadurch kann es zu erheblichen Einbußen beim Schreiben kommen.
Ein simpler CPYF kann z.B. um mehr als einen Faktor 1000 beschleunigt werden, wenn FRCRATIO(*NONE) gewählt wird.

Wenn Journalisierung gewählt wurde, sollte auf jeden Fall FRCRATIO abgeschaltet werden.

Dadurch kann es natürlich zu erheblichen Unterschieden zwischen DB/400 und MySQL/SQL-Server/Oracle kommen, da diese Datenbanken eben grundsätzlich journalisieren und somit ein direktes physisches schreiben nicht durchgeführt wird.

Manche DB's (z.B. Firebird) erlauben das abschalten des Write-Caches, was gleichbedeutend mit einem geradezu gewaltigem Performanceverlust ist.

[BenderD]

@Baldur

die sind zwar mit O geöffnet, verwenden aber (so stehts zumindest in den Debug Messages) keinen Zugriffspfad (sondern Eingangsfolge). Wegen des lazy close von SQL bleibt die Datei mit und ohne prepare offen.
Package Namen kann man auch beim JDBC Treiber setzen, QTEMP habe ich noch nicht probiert.
Caching ist auch in der Applikation (gerade bei Zugriffen über Netzwerk) das A und O für gute Performance; das sieht man in Java bei Hibernate, der das automatisch macht.

mfg

Dieter

@Dieter
Da muss ich zumindest bei der Verwendung per ODBC wiedersprechen.
Die Datei, in die ich per Insert schreibe ist mit Status "O" eröffnet.
Also auch hier ist die Verwendung von Prepared-Statements aus Performancegründen durchaus sinnvoll.

Da ich nicht weiß, in wie weit der Java-Treiber benannte SQLPKG's unterstützt kann es da durchaus Unterschiede geben.

Um dem Problem der SQLPKG's aus dem Weg zu gehen, kann man mindestens beim ODBC-Treiber sein Paket in die QTEMP legen. Mit dem IBMDA400 gehts ab V5R3 auch.
Meine Erfahrungen mit dieser Methode sind durchaus sehr gut.

Was den Optimizer angeht teile ich deine Meinung.
Häufig genug wird ein Zugriffsweg vorgeschlagen der anschließend keine Verwendung findet, da der Optimizer den Tablescan immer noch für optimaler hält.
Das ist aber doch eher selten der Fall.

Da ich inzwischen doch einiges mit ODBC getestet habe, konnte ich mittels DEBUG-Modus die meisten SQL's wie gewünscht beschleunigen.

Ach ja, es gibt da noch einen kleinen Engpass:

Mangels Journalisierung werden Anwendungsdateien häufig mit FRCRATIO(1) angelegt.
Dadurch kann es zu erheblichen Einbußen beim Schreiben kommen.
Ein simpler CPYF kann z.B. um mehr als einen Faktor 1000

beschleunigt werden, wenn FRCRATIO(*NONE) gewählt wird.

Wenn Journalisierung gewählt wurde, sollte auf jeden Fall FRCRATIO abgeschaltet werden.

Dadurch kann es natürlich zu erheblichen Unterschieden zwischen DB/400 und MySQL/SQL-Server/Oracle kommen, da diese Datenbanken eben grundsätzlich journalisieren und somit ein direktes physisches schreiben nicht durchgeführt wird.

Manche DB's (z.B. Firebird) erlauben das abschalten des Write-Caches, was gleichbedeutend mit einem geradezu gewaltigem Performanceverlust ist.

[Fuerchau]

Ja ok, dann war das ein Missverständnis.
ODP (OpenDataPath) verstehe ich vom Begriff einfach als geöffnete Datei.
Dass beim Insert kein Zugriffsweg notwendig ist ist schon klar.

Das mit der QTEMP habe ich bereits häufig ausprobiert, da ich da vorallem keine Namenskonflikte habe. In der QGPL sieht man ja häufig so Namen die mit MS anfangen und FBA (Access, MS-Query, VBA) aufhören.
Berechtigungsprobleme sind noch das geringste.

Und auf die gespeicherte Zugriffsanalyse kann man bei richtiger vorherigen SQL-Analyse sowieso verzichten.

[COS]

Nur so nebenbei erwähnt: Spaßeshalber mal 'ne MySQL auf einem stinknormalen Bürorechner installiert, der neben der iSeries steht und dort eine entspr. Tabelle erzeugt. Das Einfügen von Sätzen dauert dabei 'ne knappe Millisekunde... Auch wenn das jetzt kein echter Vergleich ist

Markus

Deutliche Performance-Steigerungen kann es (bei JDBC-Insert oder -Update) bringen,
wenn man, statt einzeln jedes Statement auszuführen,

...
stmt.execute()  bzw  stmt.executeUpdate() 
...

die Batch-Funktionalitäten von Statement bzw. PreparedStatement benutzt
(natürlich nur da, wo es Sinn macht; zB Massen-Verarbeitung Insert/Update)

...
for () {
notwendige Parameter setzen
stmt.addBatch() 
}
.........
con.setAutoCommit(false);
updateCounts = stmt.executeBatch();

...

[BenderD]

... falls der Treiber das überhaupt unterstützt - das war bei dem Toolboxtreiber nicht immer der Fall, was IBM nicht davon abhielt diese Empfehlung abzugeben; überflüssig zu sagen, dass es damit langsamer wurde.

mfg

Dieter Bender

Deutliche Performance-Steigerungen kann es (bei JDBC-Insert oder -Update) bringen,
wenn man, statt einzeln jedes Statement auszuführen,

...
stmt.execute()  bzw  stmt.executeUpdate() 
...

die Batch-Funktionalitäten von Statement bzw. PreparedStatement benutzt
(natürlich nur da, wo es Sinn macht; zB Massen-Verarbeitung Insert/Update)

...
for () {
notwendige Parameter setzen
stmt.addBatch() 
}
.........
con.setAutoCommit(false);
updateCounts = stmt.executeBatch();

...

[COS]

... falls der Treiber das überhaupt unterstützt - das war bei dem Toolboxtreiber nicht immer der Fall, was IBM nicht davon abhielt diese Empfehlung abzugeben; überflüssig zu sagen, dass es damit langsamer wurde.

mfg

Dieter Bender

der iSeries-Treiber JT/400 bzw. JT/Open unterstützt dieses sehr wohl -
und es wird dadurch deutlich schneller !

[BenderD]

@COS: lesen sollte man schon, nicht alle Versionen des Toolboxtreibers haben dies unterstützt und bei fehlender Unterstützung wird es langsamer.