ich habe eine Query in der bis zu 10 recht grosse Tabellen gejoint werden, auf mehreren Tabellen wird gefiltert (WHERE soundso LIKE ‚soundso%‘) bzw. kann gefiltert werden.
Nun ist das sehr langsam obwohl am Ende wenige Datensätze rauskommen. Ich habe nun zum Teil Abfragen in viele kleine Abfragen aufgesplittet, obwohl ich nicht einsehe dass bei guter Optimierung die selbe Sache mit einer Query langsamer sollte.
Ich glaube (muss mir den EXPLAIN PLAN) nochmal anschauen, Oracle optimiert falsch. Kann ich Oracle mittels Hints oder wie auch immer klarmachen, nach welcher Tabelle er zuerst filtern soll… ich kann in etwa abschätzen, dass eine Filterung nach soundso nur vielleicht 1% der Datensätze der Tabelle liefert, eine andere aber evtl. 50%. Das heisst wenn Oracle die Query falschrum anpackt, dann muss er bis zum Schluss mit einer Menge unnötiger Daten hantieren.
Ich habe mal in der Oracle Doku bei Hints geschaut, aber habe da nur was gefunden, welche Indexe er verwenden soll und noch ein paar andere seltsame Dinge… kann ich irgendwie angeben in welcher Reihenfolge er die Where-Bedingungen anwenden soll?
Hi Bruno,
in der FROM-Klausel:
die „most selective“ Tabelle an erster Stelle, die nächste dann, usw.
In der WHERE-Klausel ist die Reihenfolge egal.
Es kann aber trotzdem sein, daß das ganze langsam wird, da LIKE-operationen Dir jeden Indexzugriff vermasseln.
muss ich dann den Hint ORDERED geben? oder geht das auch ohne
und die Sache ist auch die, dass ich mit Views (ein paar gejointe Tabellen) arbeite, an die ich noch etwas hinjoine… dadurch kann ich die Reihenfolge der FROM-Klausel nicht immer richtig angeben befürchte ich
ich habe eine Query in der bis zu 10 recht grosse Tabellen
gejoint werden, auf mehreren Tabellen wird gefiltert (WHERE
soundso LIKE ‚soundso%‘) bzw. kann gefiltert werden.
ich nehme an, entsprechende Indizes sind vorhanden.
Nun ist das sehr langsam obwohl am Ende wenige Datensätze
rauskommen.
Wenn viele Datensätze rauskämen, könntest Du diese mittels
SELECT count(*) FROM (SELECT …)
auf eines reduzieren. Trotzdem wird es nicht schneller. Was schließen wir daraus? Der Umfang der Ergebnismenge hat nichts mit der Geschwindigkeit zu tun.
Ich glaube (muss mir den EXPLAIN PLAN) nochmal anschauen,
Oracle optimiert falsch.
Ja. Stell den Optimizer auf RULE und mach es selbst. Durch geschicktes Beeinflussen des Statements - „umschichten“, weitere/weniger Subselects, Outer Joins, Umformulierungen („BETWEEN“ statt "a>x and a
muss ich dann den Hint ORDERED geben? oder geht das auch ohne
Der Hint hilft, obwohl Oracle sich (meist) auch ohne daran hält.
Aber wie Cheatah sagte, der Hint zwingt Oracle zu nichts.
und die Sache ist auch die, dass ich mit Views (ein paar
gejointe Tabellen) arbeite, an die ich noch etwas hinjoine…
dadurch kann ich die Reihenfolge der FROM-Klausel nicht immer
richtig angeben befürchte ich
Hmmm… Da kann wohl kein Optimizer helfen… Versuche die Views aufzudröseln und in Deinem Select aufzunehmen. Aber beliebig komplex darf das nicht werden…