SQL zu langsam?

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