Job Prio des Users ändern?

[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