Resourcen SQL Jobs

[nordlicht]

Liebes Forum,

wer kann mir weiterhelfen? Wir sind Anwender auf einer I5. Unser Plattenspeicher beträgt ca. 1,5 TB. Unsere normale CPU Auslastung liegt im average bei ca. 50%, die Plattenauslastung beträgt zur Zeit knapp 50%.

Nun hatten wir in der letzten Woche folgendes Phänomen: Die CPU Auslastung war über Nacht auf weit über 100% geklettert und die Auslastung des Plattenspeichers betrug mehr als 80%. Wir haben sehr schnell den Resourcenfresser festgestellt. Es war der Job QZDASOINIT im Subsystem QSYSWRK. Als ich diesen Job beendet hatte, normalisierten sich sowohl die CPU Werte als auch die Plattenauslastung (wieder bei knapp unter 50%).

Frage: Welche Möglichkeiten habe ich, den Resourcenverbrauch für CPU und besonders den Plattenspeicher für einen Job zu limitieren? Gibt es einfache Möglichkeiten?

Danke im voraus.

[Fuerchau]

Gerade was diesen Job QZDASOINIT angeht ist dieser leider nur schwer wenn überhaupt limitierbar.
ber die Klasse des Leitweges haben wir schon versucht die Prio auf 50 (Default 20) zu setzen, aber das System ignoriert dieses leider.

Ursache sind an dieser Stelle ODBC-Zugriffe die anscheinend wenig optimiert sind:
- fehlender Zugriffspfad
- CA-Trieber ODBC-Konfig->Leistung->Suchmuster ist an !
und was der Dinge da noch mehr sein können.

Den Ansatz hier über den qzd...Job zu machen ist falsch.
Hier muss die Ursache am ODBC-Zugriff bekämpft werden !

[BenderD]

Hallo,

Ansatzpunkte gibt es da schon:
Speicher QUSER limitieren
QRYTIMLMT limitieren
Prio runter geht durchaus
problematisch ist, das sich das schlecht splitten lässt in Anforderungen die dürfen und solche die nicht und ohne Ursachenforschung ist das riskant, da rumzuschrauben; da kann man durchaus auch Probleme verschärfen.

mfg

Dieter Bender

Gerade was diesen Job QZDASOINIT angeht ist dieser leider nur schwer wenn überhaupt limitierbar.
ber die Klasse des Leitweges haben wir schon versucht die Prio auf 50 (Default 20) zu setzen, aber das System ignoriert dieses leider.

Ursache sind an dieser Stelle ODBC-Zugriffe die anscheinend wenig optimiert sind:
- fehlender Zugriffspfad
- CA-Trieber ODBC-Konfig->Leistung->Suchmuster ist an !
und was der Dinge da noch mehr sein können.

Den Ansatz hier über den qzd...Job zu machen ist falsch.
Hier muss die Ursache am ODBC-Zugriff bekämpft werden !

[Fuerchau]

Da muss ich dich leider enttäuschen, Dieter.
Die Einstellungen des QRYTIMLMT auf der AS/400 hat aus ODBC-Sicht überhaupt keinen Einfluss.
Die Defaults der ODBC-Treiber stehen in der Windows-Registry (bei Linux weiß ichs nicht) und können ggf. per Command-Execute überschrieben werden.
Da der Pessimizer ja inzwischen ja bekannt ist, wird dieses Limit sehr häufig auf der Client-Seite hochgesetzt.

Allerdings gibt es eine Abfrage, deren QRYTIMLMT überhaupt nicht beeinflussbar ist.
Beim Öffnen eines Recordsets wird u.U. die SYSCOLUMNS durchforstet.
Im CA-ODBC-Konfig gibt es eine kleine Gemeinheit, deren Default inzwischen geändert wurde:
"Suchmuster aktivieren" !
Diese Angabe führt dazu, dass über die SYSCOLUMNS ein temporärer Index aufgebaut wird, wenn der Lib-Name einen Unterstrich enthält !
Und Peng! hat man den Salat.

Schaltet man dieses Flag aus, können allerdings keine generischen Abfragen der SYS-Tabellen mehr durchgeführt werden.
Aber wer braucht das schon.

Die Prio wird über die CLSD des PJ's gesteuert.
Wir haben festgestellt, dass man zwar die Jobs runterfahren kann, aber nach einem Rekonnect ist die alte Prio wieder da !?

Selbst das Ändern der CLSD sowie ein IPL brachte bisher nichts.
Die QCDA-Jobs laufen weitestgehend mit der Prio von Dialog-Job's.

[BenderD]

@Baldur:
dass QRYTIMLMT kein Patentrezept ist, ist mir völlig klar, da hier Schätzwerte vor Ausführung des Queries herangezogen werden; dass da Client seitig gefummelt wird ebenfalls, aber ich denke für direkte Benutzeranforderungen ist das schon als Abfangjäger einsetzbar.
Zu den Prioritäten: dass sieht mir eher nach einem Bug als nach einem Feature aus. Ich war schon mit Installationen befasst, wo genau über die Class die Prios auf viel zu niedrige Werte (> 60) gesetzt war und da hat sich nix zurück gestellt.

@nordlicht:
interessant wäre gewesen, was der QZDASOINIT da eigentlich getireben hat. 30% Zuwachs bei 1,5 Terra sind immerhin fast 500 Gig, die kriegt man nur mit einem riesigen (temporären) Cross Join hin, oder es muss ein Bug im Treiber oder der Database vorliegen. Was habt ihr da eigentlich für Workload, die über ODBC oder JDBC reinkommt?

mfg

Dieter Bender

Da muss ich dich leider enttäuschen, Dieter.
Die Einstellungen des QRYTIMLMT auf der AS/400 hat aus ODBC-Sicht überhaupt keinen Einfluss.
Die Defaults der ODBC-Treiber stehen in der Windows-Registry (bei Linux weiß ichs nicht) und können ggf. per Command-Execute überschrieben werden.
Da der Pessimizer ja inzwischen ja bekannt ist, wird dieses Limit sehr häufig auf der Client-Seite hochgesetzt.

Allerdings gibt es eine Abfrage, deren QRYTIMLMT überhaupt nicht beeinflussbar ist.
Beim Öffnen eines Recordsets wird u.U. die SYSCOLUMNS durchforstet.
Im CA-ODBC-Konfig gibt es eine kleine Gemeinheit, deren Default inzwischen geändert wurde:
"Suchmuster aktivieren" !
Diese Angabe führt dazu, dass über die SYSCOLUMNS ein temporärer Index aufgebaut wird, wenn der Lib-Name einen Unterstrich enthält !
Und Peng! hat man den Salat.

Schaltet man dieses Flag aus, können allerdings keine generischen Abfragen der SYS-Tabellen mehr durchgeführt werden.
Aber wer braucht das schon.

Die Prio wird über die CLSD des PJ's gesteuert.
Wir haben festgestellt, dass man zwar die Jobs runterfahren kann, aber nach einem Rekonnect ist die alte Prio wieder da !?

Selbst das Ändern der CLSD sowie ein IPL brachte bisher nichts.
Die QCDA-Jobs laufen weitestgehend mit der Prio von Dialog-Job's.

[nordlicht]

Hallo Baldur, hallo Dieter,

vielen Dank für Eure prompten Antworten. Nun zum Thema.

Bei unseren SQL Verbindungen handelt es sich um von Endanwendern gestartete Prozesse, die Daten aus unseren I5 Datenbanken selektieren. Diese Daten transferieren die User dann in ExcelSheets, um sie dort weiter zu bearbeiten. Welche Last kommt da auf uns zu? Immer mehr. Unglücklicherweise sind wir gezwungen, diese Tür immer weiter zu öffnen. Ich will nicht ausschließen, dass zum Teil auch unkontrollierte und unlogische Aktionen gestartet werden.

Mir geht es primär darum, diese performance-- und speicherlastigen Jobs im Vorfeld zu erkennen und evtl. zu eliminieren. Dieter hat mit dem Begriff ‚Abfangjäger’ schon den Nagel auf den Kopf getroffen.

Ist das mit den von Euch vorgeschlagenen Möglichkeiten QQRYTIMLMT und MAXSTG (im Userprofil) hinzukriegen?

Oder anders rum. Habe ich eine Chance diese SQLS in einer eigenen LPAR laufen zu lassen, mit Zugriff auf die DBs des Produktiuonssystem? Was kann ich I5seitig noch tun?

Vielleicht kennt Ihr Möglichkeiten das Microsoft SQL Pcseitig durch andere Alternativen (Fremdsoftware) zu ersetzen, wobei der Anwender sicher nicht auf seine Funktionalität verzichten will..

Ich bin für Anregungen immer dankbar.

Gruß
Nordlicht

[Fuerchau]

QRYTIMLMT hilft da leider gar nichts (siehe oben).
MAXSTG hilft da auch nichts, da nur temporärer Speicher belegt wird und der User auch noch QUSER ist.
Eine LPAR mit Durchgriff bringt da auch nichts, da der SQL ja immer auf der DB selber läuft !
Andere Software bietet nur andere Oberflächen, aber intern bleibt SQL eben SQL.

Das Problem der Query-Abfragen (MS-Query oder auch AS/400-Query) ist halt immer wieder die zwangsweise Unkenntnis über das aktuelle Datenbankmodell.
Welcher User weiß schon, welche Abfrageart die günstigste ist und ausserdem will er ja nur eben mal was auswerten.

Da kannst du nur in den sauren Apfel beißen, die Maschine beschleunigen (Hardware o.ä.) oder eben:

- Die Datenbank kopieren in eine 2. LPAR und die Abfragen nur darauf zulassen (Nachteil: nicht aktuell)

- gezielte Views mit Vorselect (Mandant o.ä.) in eigene Lib's und nur diese erlauben

- tja ..... viele viele Wege

Und zu allem Überfluss empfehle ich das Produkt PCSACC/400 um den Datenklau weitestgehend zu überwachen (verhindern geht ja eh nicht).

[BenderD]

Hallo Nordlicht,

man kann schon die Ressourcen begrenzen und zwar auf dem umgekehrten Weg, wie in dem Beitrag von KM im selben Forum aktuell skizziert:
Prio für die QZDASOINIT Jobs absenken
Storage Pool mit oberem Limit einrichten
QZDASOINIT Jobs in diesen Pool einzwängen
damit laufen diese Jobs noch langsamer, nehmen aber anderen weniger weg.

Schrauben am Query Timelimit ist nicht so ganz trivial, da man das schlecht selektiv machen kann; allerdings wäre schon denkbar, dass man diesen Weg geht; wenn man hier einen Wert, von sagen wir mal 100 reinstellt, dann laufen alle elementareren Sachen, die einen Zugriffspfad haben immer noch, der von dir erwähnte Langläufer wäre mit hoher Wahrscheinlichkeit rausgeflogen - eine scharfe Grenze ist das aber nicht.

Speicher limitieren sollte auch gehen, der Speicherverbrauch wird nicht QUSER zugeordnet, sondern dem Benutzer des Connects, auch dies hätte den eingangs erwähnten Job mit hoher Wahrscheinlichkeit gekippt. (es gibt da zwar noch Anteile, die nicht zu packen sind, Database statistics etc...). Im richtigen Leben kann aber auch dies zweischneidig sein, da oft ein großes Gruppenprofil hinter allem hängt und dann der verkehrte an dem Haken aufgehängt wird.

Ein Abfangjäger auf Speicherzustand kritisch, der dann die QZDASOs runtersägt wäre zu überlegen.

Partitionierung hilft hier erst mal nix, da man ja uf die Prod Datenbank geht und die Problematik Datenbank seitig aufschlägt.

Alternative Tools können helfen, da Reporting Engines die Möglichkeiten einschränken können und dann nach festgelegtem Regelwerk SQLs generieren, die sich besser optimieren lassen; dieser Weg kann allerdings teuer werden.

Entkoppeln kann man das nur über Replikation der Datenbank (oder Teile davon) auf einen dezidierten Datenbankserver, dann sind die Daten zwar nicht aktuell, man kann aber besser Konsistenz garantieren, da man dann Lesebetrieb von Änderungsbetrieb trennen kann.

mfg

Dieter Bender