Resourcen SQL Jobs

[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