Job Prio des Users ändern?

[BenderD]

... wenn denn das ERP komplett über QZDASOINIT zugreift, wäre Holgers Vorschlag der schlechteste, weil er allen schadet und nichts positives bewirkt und der von Robert der, der am wenigsten schadet, weil er nichts bezweckt.
Selektiv einzugrenzen gibt es nur die Möglichkeit über die Exit Schnittstellen von DB2, oder über Auftrennung der Serverjobs in verschiedene Subsysteme und dann kann man auf SubsystemEbene unterschiedliche eine class mit unterschiedlichen Prios zuordnen. Aber eigentlich gehört das an der Quelle geheilt: am Index Design!!!

D*B

[AG1965_2]

Viele Softwarehäuser haben sich für den internen Gebrauch eine Überwachung gebastelt, die, wenn ein Job zu sehr die anderen Leute behindert, die Priorität dieses Jobs heruntersetzt.
Wenn 1. an den SQL-Statements wirklich nichts mehr zu optimieren ist, und 2. Indizes wirklich nichts mehr helfen, würde ich 3. daran denken, so was auch auf einem Produktivsystem einzusetzen, um nicht immer manuell eingreifen zu müssen.

[Fuerchau]

Zu 1. und 2.: dies halte ich für ein Gerücht, alles lässt sich optimieren und sei es, die SQL's in Einzelschritte zu zerlegen.
Oft genug habe ich erlebt, dass Join-Beziehungen mittels temporärer Ergebnistabelle (create qtemp/mytemptable as select ...) um Faktoren schneller sind. Mitunter von Minuten zu Sekunden!
Man bedenke, dass eine CTE/derived Table/Scalarer Subselect keine temporären Zwischentabellen ergeben sondern je Quellsatz zur Ausführung kommen.

zu 3.: Klar, wenn man bei 1 und 2 nichts findet, landet man bei 3 was nicht wesentlich was bringt sondern nur Geld kostet.

Und was die ominöse Prio angeht, so betrifft dies die "Häufigkeitsverteilung" auf der sog. Zeitscheibe.
Bildlich gesprochen erhält jeder Job über die Prio entsprechende Anteile. Je mehr Job's im System, so geringer der %-Anteil. Zu verstehen ist das wie die Anzahl der Tortenstücke die durch die "Anzahl Jobs" * (100-Prio) berechnet werden und gleichmäßig verteilt sind.
Jeder Job bekommt so eine definierte Ausführungszeit.
Bei jedem I/O oder sonstigen Wartebefehlen wird die Zeitscheibe vorzeitig abgegeben, der Rest verfällt und genau davon lebt das System eigentlich.
Wenn ein rechenintensiver Job seinen Zeitanteil nun voll ausschöpft, leiden alle anderen Jobs, die ihren Anteil vorzeitig aufgeben, extrem darunter.
Wenn also bei z.B. 1000 Job's nur 1 einziger Job etwas weniger häufig dran kommt, seinen Anteil aber ausschöpft, ändert das am Gesamtverhalten des Systems nur unwesentliches.

Bei Systemen mit wenigen Jobs (ich meine hier < 100) kann es da schon Auswirkungen bringen.

Ggf. interessant ist eher "Zeitscheibe in Millisekunden", Dialog z.B. 2000, Batch 5000!
D.h., wenn ein intensiver Rechenjob eben ohne IO-Unterbrechung 5 Sekunden rechnet wird er danach zwangsunterbrochen.

[BenderD]

... bei Performance geht es oft wüst durcheinander:
@"Optimierung" Statements: SQL ist an der Ergebnismenge orientiert! Wenn zwei Beschreibungen derselben Ergibnismenge unterschiedliche Laufzeiten haben, dann ist das eine Schwäche des Optimizers (das könnte nach dem nächsten PTF/RELEASE genau umge´kehrt sein - mit einer Ausnahme: mit optimize for n rows kann man den Optimizer beeinflussen.
@Einzelschritte: Wenn man aus einem SQL Statement mehrere mit Zwischentabellen machen kann (manchmal geht das), dann kann man dadurch Richtung Selektivität forcieren, sprich: Extrakte ziehen, die man verjoint (kostet aber oft CPU, da man Lesezugriffe gegen CPU tauscht).
@Zeitscheibe: beim ersten synchronen I/O (reinpagen von Platte) verliert man die CPU. I/O intensive Jobs erreichen also das Ende der Zeitscheibe fast nie - rumschrauben daran bringt hier eher nix.
@Prio: die Job Prio kommt immer dann zum Zuge, wenn ein verdrängter Job wieder CPU haben will. Das heißt: auch ein Job mit Prio 99 kann ein System voll auslasten.
@Speicherpools: Hier wird tatsächlich aufgeteilt, was allerdings bei den Einstellungen der meisten Systeme nicht wirklich zieht, die dynamische Steuerung macht die Reaktion auf Speicherfrass nur träger, verhindert diesen Effekt aber nicht.

Die meisten Probleme mit der Datenbank liegen im Index Design! Sprich fehlende Indexe. Bevor man hier nicht untersucht hat, ist jede andere Maßnahme nicht sehr sinnvoll.

D*B

[AG1965_2]

Ja, 3. ist die letzte Möglichkeit, den Systembetrieb aufrechtzuerhalten, wenn ein User / Programm unerwartet ungewöhnlich viele Ressourcen benötigt. Das ist keine Optimierung; der Verursacher hat noch länger zu warten.
Ich hab' auch schon mal ein Produktivsystem gesehen, wo interaktive Benutzer Klassen mit, wenn ich mich recht erinnere, 120000 msec (2 Minuten) max. CPU-Zeit hatten.
Da gewöhnt man sich ganz schnell an, so ziemlich alles zu submitten, da sonst der Job beinhart endet.

[Fuerchau]

Bei Dialogjobs können in 8 Stunden da schon mal 2 Minuten zusammenkommen.

Und was die "Optimierung" angeht so musst ich schon feststellen, dass das Programm je nach Datenmenge mal günstig oder ungünstig lief.
Laut Debug-Diagnose wurde der Zugriffsplan immer neu erstellt und somit der Weg immer neu kalkuliert.

Die "Extrakt"-Ziehung (das habe ich wirklich von Dieter gelernt), bringt dort mitunter gewaltige Vorteile, ins besonders wenn Derived Tables / CTE's mit GroupBy-Konstrukten gebaut und verjoint werden.
Hier ist die temporäre Tabelle mit Index gewaltig im Vorteil.

[BenderD]

... einen prestarted Job mit CPUTIME zu kastrieren macht überhaupt keinen Sinn - das ist sowieso nur ein Angst Anker gegen loopende Jobs.

@Extrakte: Das war in der leider nicht mehr aktiven Bigdata Installation ein wichtiges Instrument...

D*B