PDA

View Full Version : Performance ODBC / JDBC Jobs 9406-520



heini
09-02-10, 08:27
hallo forum,
wir habe sehr viele Jobs -> QZDASOINITaktiv - das sind hauptsächlich Verbindungen für Access-Abfragen. diese laufen mit einer Ausführungspriorität von 20.
Frage: ist es möglich (und wie) diese Jobs mit einer anderen Prio zu starten (zb. mit prio 50 wie batch-jobs) )) wie richtet man so was ein bzw. was muss dazu getan werden ?
danke für die hilfe
heinz

BenderD
09-02-10, 08:40
... da gibt es einen Eintrag für prestarted Jobs im Subsystem (je nach Release), der hat eine Job Description und eine Class und da hängt die Priorität dran. Zusätzlich kann man noch über Oops Nerv Anforderungen nach verschiedenen Kriterien einem SubSystem zuordnen. (Allerdings muss man da aufpassen, dass man sich nicht die Füße auf der Erde festnagelt, niedrigere Prioritäten können die Auswirkungen schlimmer machen (Stichwort: Sperren!!!)

D*B


hallo forum,
wir habe sehr viele Jobs -> QZDASOINITaktiv - das sind hauptsächlich Verbindungen für Access-Abfragen. diese laufen mit einer Ausführungspriorität von 20.
Frage: ist es möglich (und wie) diese Jobs mit einer anderen Prio zu starten (zb. mit prio 50 wie batch-jobs) )) wie richtet man so was ein bzw. was muss dazu getan werden ?
danke für die hilfe
heinz

andreaspr@aon.at
09-02-10, 08:47
sowei ich weis ist QPWFSERVER die klasse für QZDASOINIT.
also:
CHGCLS CLS(QSYS/QPWFSERVER) RUNPTY(xx)

heini
09-02-10, 08:48
die jobs laufen ja im qsyswrk, wo finde ich diesen eintrag?
wir haben V5R3M5

Fuerchau
09-02-10, 08:56
Das Ändern der Prio hat nur geringe bis gar keine Auswirkungen, ins besonders, wenn viele Abfragen laufen.
Wenn ein temporärer Index gebildet werden muss, interressiert die Klasse nämlich überhaupt nicht, das System wird bis zum Maximum belastet.

Hier gilt es eher, die Abfragen von Access/Java zu optimieren, so dass die Systemlast sinkt.

Übliche Probleme dieser Abfragen in Access sind Joins zwischen verknüpften und lokalen Tabellen.
Diese ziehen nämlich erst den gesamten Inhalt einer Tabelle in den Speicher, führen dann den Join intern aus und verwerfen den Rest wieder.

Das nächste Problem sind häufig fehlende Indexe für den SQL-Optimizer.
Hierbei besteht bei Access meist das Problem, dass Access max. 32 LF's unterstütz und stirbt, wenn mehr als 32 LF's vorhanden sind.
Alternativ hilft nur die Verknüpfung auf eine LF mit Schlüssel, die allerdings kein Select/Omit enthalten darf.
Den Rest erledigt der Optimizer.

Für JDBC gilt i.W. das selbe, dass hier ungünstige Abfragen (auf LF's mit Select/Omit, fehlender Index, usw.) gestartet werden.

Im Normalfall sollten ODBC/JDBC-Abfragen in wenigen Sekunden (möglichst < 2) erfolgreich sein.

AS400.lehrling
11-02-10, 12:47
Das nächste Problem sind häufig fehlende Indexe für den SQL-Optimizer.
Hierbei besteht bei Access meist das Problem, dass Access max. 32 LF's unterstütz und stirbt, wenn mehr als 32 LF's vorhanden sind.
Alternativ hilft nur die Verknüpfung auf eine LF mit Schlüssel, die allerdings kein Select/Omit enthalten darf.
Den Rest erledigt der Optimizer.


Das ist doch schon von Schreiben in RPG her so ublich das man lf's erstellt um den temporären Aufbau eines Such Indexes zu umgehen.

Ist ja auch in Holgers PDF zu den Programmiergrundlagen gut dokumentiert.

Finde es fast erschreckend das sich scheinbar niemand einen Kopf darum macht vernümpftige Such Pfade zu erstellen sondern scheinbar nur an XP & Co im sql rumwühlt und dan die Schuld für schleichendes Arbeiten auf die i5 abwällst - so nach den Motto "Unter Windows haben wir im Excel klare Abfragen definiert".

Gruß AS400.lehrling

Fuerchau
11-02-10, 14:01
Dem kann ich nur zustimmen.
Ich habe immer wieder Access-Anwendungen gesehen, die von Nicht-Programmierern erschreckende Antwortzeiten haben.
Die Schuld wird dann häufig auf den Server (AS/400 oder auch SQL-Server) geschoben.

AS400.lehrling
11-02-10, 14:10
Dem kann ich nur zustimmen.
Ich habe immer wieder Access-Anwendungen gesehen, die von Nicht-Programmierern erschreckende Antwortzeiten haben.
Die Schuld wird dann häufig auf den Server (AS/400 oder auch SQL-Server) geschoben.

Na mysql oder andere bekante sql server werden damit ähnliche performance probleme haben wie die i5.

Gruß AS400.lehrling