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