View Full Version : SQL Performance
übrigens:
like '0301__03____________%'
==
like '0301__03%'
Ist mir schon klar - war nur reine Bequemlichkeit beim programmieren - es können auch noch weiter hinten in dem Feld Einschränkungen kommen - dürfte aber von der Performance egal sein.
@BenderD
Mit dem Umbau hab ich kein fachliches Problem - ist mir schon klar wie das zu lösen ist - nur ich DARF NICHT!
Wenn ich mir die View so anschaue, stellt sich mir die Frage ob tatsächlich "LEFT JOIN" benötigt wird.
Left join heißt ja, dass auf der rechten Seite durchaus Sätze fehlen dürfen, also NULL zurückkommt.
Die Bedingungen sehen allerdings mehr so aus, dass ein "inner join" besser erscheint.
Dann würde ich die Beziehung auch eher in die Where-Klausel legen:
select ...
from file1 a, File2 b
where a.key=b.key and ...
Left join heißt ja, dass auf der rechten Seite durchaus Sätze fehlen dürfen, also NULL zurückkommt.
Das Join auf GIDPF01G (3x) kann tatsächlich NULL zurückbringen - diese Sätze sind sehr oft nicht vorhanden!
Daher auch die Case-Abfrage auf NULL (mittlerweile auf "coalesce" umgebaut).
@Baldur:
den left outer kann man nicht weglassen, das sind 1 zu 0 bis n Beziehungen zwischen der ersten Table und ihren Satelliten und von denen, die es gibt, will man nur bestimmte haben. Von daher war die Formulierung in der join Klausel durchaus adäquat und dies darf das Problem eigentlich nicht verursachen.
@Dirschl:
wielange läuft denn nun genau die Abfrage:
SELECT * FROM PPGIDPV WHERE
RSPD00 = 'ATAT ' and RSPF00 = 'J' and ITTY1N <> 'VO' and
QPR100 like '0301__03____________%' order by IITM00 optimize for 20 rows
und wenn das länger als 1 sec dauert, welche Indexe hast du genau auf der RSPD00 und was wird für ein Access Plan generiert (sieht man unter debug, oder mit dem DBMON)?
Dieter Bender
PS: die Abfragen mit Like und Wildcard % am Anfang, die kann man eigentlich nur mit Hardware (Prozessor und parallel Database Feature, oder Platte für zusätzliche Riesen Indexe) flott machen.
Wenn ich mir die View so anschaue, stellt sich mir die Frage ob tatsächlich "LEFT JOIN" benötigt wird.
Left join heißt ja, dass auf der rechten Seite durchaus Sätze fehlen dürfen, also NULL zurückkommt.
Die Bedingungen sehen allerdings mehr so aus, dass ein "inner join" besser erscheint.
Dann würde ich die Beziehung auch eher in die Where-Klausel legen:
select ...
from file1 a, File2 b
where a.key=b.key and ...
@BenderD
Aktuelle Messung: ca. 1 sec
Die Zeiten schwanken etwas, sind aber im Vergleich zu gestern aufgrund der Umbauten wesentlich schneller.
Im Debug sehe ich keinen Zugriffsplan - vom DBMON habe ich leider keine Ahnung.
Die Selektionsfelder befinden sich bei dieser Abfrage alle in der Datei GIDPF300 - lt. Debug verwendet er 2 Indexe.
Das ist doch i.O., oder ?
Noch schneller gehts doch gar nicht.
Das ist doch i.O., oder ?
Noch schneller gehts doch gar nicht.
Ist richtig!
Diverse Schwankungen die ich bei den Messungen noch festgestellt habe, werde ich jetzt einfach mal ignorieren und als gegeben hinnehmen (die SQL-Performance werde ich wohl nie kapieren :mad: - obwohl ich mittlerweile auf dieser Maschine sehr viel mit SQL arbeite - aber ich muss nicht alles kapieren :D )
Besten Dank für Eure Hilfe!
Schwankungen resultieren ggf. aus anderen Job's, oder hast du die Maschine für dich alleine ;) ?
Ist mir schon klar, dass andere Job's die Schwankungen theoretisch verursachen können.
ABER: Die Maschinie "fadisiert" sich üblicherweise - und Schwankungen um das 3-5 -fache - bei gleicher Auslastung - lassen sich nicht durch andere Job's erklären - und schon gar nicht nach 18:00 Uhr!
Aber was soll's - ist halt so (habe auch schon mal festgestellt, dass nach einem Betriebssystemwechsel die SQL-Performance zusammengebrochen ist - hat plötzlich 10-15 mal solange gedauert wie vorher!)
Anderes Problem:
Kann ich eigentlich einen Index über ein Teilfeld legen (z.B: Index über Substr(qpr100, 4, 16).
Hallo,
entweder CHGJOB QRYTIMLMT(0) für interaktive Jobs, oder strdbg für den Job (bei Batchjobs vorher STRSRVJOB) bringt diagnostic messages in das Joblog über Verwendung von Zugriffspfaden, warum bestimmte nicht verwendet werden, ob der Optimizer fertig geworden ist, etc. das ist eigentlich immer der Einstieg zur Analyse, wenn man berweits weiß, wo es klemmt.
Weiß man noch nix, dann STRDBMON mit DETAIL(*ALL) für alle Jobs (vorsicht immenses Datenvolumen) und dann ... muß man doch ein wenig Wissen und Erfahrung haben, damit man findet, was man sucht - et voila in wenigen Stunden weiß man, wo es klemmt (zuweilen).
Nach OS Wechsel (und nach PTFs) klebst seit V5R2 teils erheblich, wg. der famosen neuen Query Engine, die leider Häppchenweise als Beta auf die Büchse kommt...
Dieter Bender
PS: Wenns wieder mal Ausreißer gibt, mehr Infos bitte, das spart Zeit
@BenderD
Aktuelle Messung: ca. 1 sec
Die Zeiten schwanken etwas, sind aber im Vergleich zu gestern aufgrund der Umbauten wesentlich schneller.
Im Debug sehe ich keinen Zugriffsplan - vom DBMON habe ich leider keine Ahnung.
Die Selektionsfelder befinden sich bei dieser Abfrage alle in der Datei GIDPF300 - lt. Debug verwendet er 2 Indexe.