View Full Version : eingefrorene interaktive Jobs
Von diversen QZDASOINIT und überhaupt zahllosen ungezügelten "Power"-Usern mit excessiven SQL-Abfragen etc. mal ganz zu schweigen.
Das könnte auch mit ein Problem sein. Wenn für SQL-Abfragen temporäre Indices erstellt werden müssen, wird beim Erstellen dieser Zugriffswege an Performance genommen was möglich ist, um möglichst rasch zum Ergebnis zu kommen. Das Erstellen eines temporären Indices dauert ebensolange wie das Erstellen eines permanenten Zugriffswegs.
... wird der gleiche temporäre Index in mehreren Job gebraucht, wird der gleiche Index in jedem Job aufgebaut (zumindest wenn die Abfragen von der CQE=Classic Query Engine ausgeführt werden).
Vielleicht solltet Ihr mal die diversen SQL-Abfragen analysieren, ggf. permanente Zugriffswege erzeugen und die Anwender entsprechend schulen.
SQL ist nämlich nur am Anfang einfach!
Birgitta
Was diese SQL-Abfragen angeht, so sind da meist ein paar Tools Schuld die das Abfragen ja so einfach machen.
Dazu gehören Query/400 genauso dazu wie eben MS-Query über Excel.
Im Endeffekt liegt wieder SQL dahinter und dann dauert es eben, bis so eine Abfrage fertig ist.
Einem Enduser, der mit Query/400 und/oder MS-Query (o.ä.) Tools umgeht, ist wohl kaum beizubringen, wie er seine SQL's optimieren soll, ins besonders wenn er ja gar nicht native mit SQL arbeitet.
Es wäre nicht das erste Mal, das so gravierende Schlüssel in der Abfrage wie Fima/Werk/Mandant weggelassen werden, da man doch sowieso nur mit einem Mandanten arbeitet. Wozu denn dann noch die Abfrage und bei Verknüpfungen zu anderen Daten kann ich die ja dann auch weglassen.
Und schon wundert man sich, dass eine Abfrage da schon mal Minuten bis Stunden dauert, die sonst in Sekunden erledigt wäre.
Das würde ich auch gerne machen, aber ich habe da leider keinerlei Einfluß drauf. Wenn ich beweisen könnte, daß es zuviele temporäre Indizies sind (zBsp Retro-Problem OPNQRYF), dann könnte ich zumindest die Verantwortung für das Problem abgeben.
Unsere SAN-Truppe hat allerdings keine überdurchnittlichen IOs zu diesen Zeiten bemerken können.
Eben. Deshalb tendiere ich persönlich immer dazu, die User dazu anzuleiten, ihre wieder kehrenden Abfragen in fähige Programmierhände zu geben zwecks Automatisierung.
Was manch ein User an einem Tag mit zehn SQL-Abfragen und 3Std Arbeit an Excel herumwerkelt, kann oft in 5min realisiert werden.
Würde ich nur 1% von der eingesparten Arbeitszeit bezahlt bekommen läge ich jetzt wohl am Strand der Malediven :D
Würde ich nur 1% von der eingesparten Arbeitszeit bezahlt bekommen läge ich jetzt wohl am Strand der Malediven :D
Super Idee, mach ich auch :cool:
Das Aufbauen von Indizes bedeutet i.W. eine hohe CPU-Auslastung und nicht so sehr Plattenauslastung (Cache!).
Wenn es denn umgekehrt wäre, würden die anderen Jobs gar nicht so sehr gestört werden.
Ein temporärer Indexaufbau legt keinen Index auf der Platte sondern im Speicher an. Dabei geht das Lesen der Datei ggf. noch sehr schnell nur eben die Baumstruktur aufbauen dauert halt und frisst ausschließich CPU.
Kein Wunder, dass die SAN-Truppe da nur wenige IO's registriert.
Wie weit sind wir denn mit den interaktiven CPWs? Hat jemand da mal was herausfinden können? Der eine Thread/Link hat mir nicht weiter helfen können, weil er nicht mehr existiert. Und sonst hab ich da nix gefunden.
Google hilft da meistens:
IBM Power 750 Express server performance data (http://www-03.ibm.com/systems/power/hardware/750/perfdata.html)
Vielleicht wirst du da ja fündig.
Logic IT-Services
03-05-12, 13:31
DSPSYSVAL QMODEL
DSPSYSVAL QPRCFEAT
Am besten google: CPW + (Wert Model) + (Wert PRCFEAT)
Dann solltest Du den CPW Wert herausfinden.
Viel Glück.
Auf der Seite war ich schon gestern. ich weiß, daß unsere i5 ca 6000CPW pro Prozessor hat. Aber ich brauche ja die Grenze, wo CFINT anfängt herum zu spinnen.