Oracle Ausführungsplan UNION ALL mit Konstante

Ein View mit einer UNION-Abfrage wird verwendet:

SELECT 1, …

UNION ALL
SELECT 2, …

Die 1. Ergebnisspalte ist eine Konstante, d.h. der Wert für die Spalte steht schon vor der Ausführung des SQL fest. Nun führe ich eine Abfrage auf den View aus und schränke in der WHERE-Clause den Wertebereich auf 1 ein.
Eigentlich erwarte ich, dass die Datenbank erkennt, dass der 2. SELECT niemals ein passenden Ergebnis liefern kann. Tatsächlich jedoch wird die 2. Abfrage von der DB mit ausgeführt. Das Ergebnis ist korrekt, jedoch ist die Ausführungszeit deutlich langsamer.

Ich verwende Oracle 9/10. Gibt es eine Möglichkeit dem Oracle die nötige Intelligenz z.B. durch HINTS beizubringen?

Gruß Markus

Hi!

Ich verwende Oracle 9/10. Gibt es eine Möglichkeit dem Oracle
die nötige Intelligenz z.B. durch HINTS beizubringen?

Mehrere Möglichkeiten:

  1. Warum nimmst Du nicht gleich das erste Select für die Abfrage anstatt der View? (Es würde vieeeel schneller funktionieren)
  2. Du machst aus der View eine Materialized View und vergibst einen Bitmap-Index auf die Spalte mit der Konstanten
  3. Du legst zwei weitere Views an (eine für die 1.Konstante, eine für die 2.)

Aber mMn wird in der Union-View IMMER auf beide Tabellen abgefragt: zuerst wird verknüpft und dann erst eingeschränkt …

Ich erinnere mich zwar dunkel, dass mein den Parser/Optimizer irgendwie „umbiegen“ kann, aber ich weiß beim besten Willen nicht mehr, wie …

Grüße,
Tomh

Ich verwende Oracle 9/10. Gibt es eine Möglichkeit dem Oracle
die nötige Intelligenz z.B. durch HINTS beizubringen?

Mehrere Möglichkeiten:

  1. Warum nimmst Du nicht gleich das erste Select für die
    Abfrage anstatt der View? (Es würde vieeeel schneller
    funktionieren)

Weil dazu die Applikation geändert werden muss. Die gesuchte Lösung sollte allein durch DB Konfiguration umgesetzt werden können.

  1. Du machst aus der View eine Materialized View und vergibst
    einen Bitmap-Index auf die Spalte mit der Konstanten

Es handelt sich um enorme Datenmengen. Alleine die Indizes für die wichtigsten Spalten dürften mehrere 100MB umfassen. Zudem fluktuieren die Daten.

  1. Du legst zwei weitere Views an (eine für die 1.Konstante,
    eine für die 2.)

Siehe 1.)

Aber mMn wird in der Union-View IMMER auf beide Tabellen
abgefragt: zuerst wird verknüpft und dann erst eingeschränkt

Ich erinnere mich zwar dunkel, dass mein den Parser/Optimizer
irgendwie „umbiegen“ kann, aber ich weiß beim besten Willen
nicht mehr, wie …

Mich hat es auch sehr verwundert. Dem Betrachter der View ist auf anhieb klar, wozu die View dient. Aber Oracle selbst kann es nicht sehen … vielleicht sollte ich die Frage mal an Tom Kyte richten :o)

Trotzdem Danke!

Kleine Frgae zum Verständnis : Was hat eine WHERE - Einschränkung irgendeiner Art mit einer Konstanten in der Select Clause zu tun ?

Gruss

Kleine Frgae zum Verständnis : Was hat eine WHERE -
Einschränkung irgendeiner Art mit einer Konstanten in der
Select Clause zu tun ?

Ich hatte das anfangs angerissen: die view besteht aus sql-abfragen, die mittels union zu einem Gesamtergebnis zusammengefasst werden. Wenn ich nun eine Spalte in die Selects projeziere und in jedem Block einen anderen Wert zurück liefere, so kann ich am Resultset erkennen, in welchem Select der Ursprung liegt.

Also wenn der View folgende Ergebnisse liefert:

1 …
1 …
2 …
1 …

Kann ich den urspruch direkt zuordnen. Wenn ich nun einen Select auf den View absetze mit der Einschränkung spalte=1 erhalte ich als Ergebnis

1 …
1 …
1 …

Eigentlich logisch. Leider führt Oracle intern auch den anderen Select aus. Am Ergebnis ändert das zwar nichts, die Auswertung kostet aber Zeit. Dabei könnte Oracle aber schon beim Vergleich mit dem Select erkennen, dass dieser Teil der Union-Abfrage mit der gegeben Bedingung spalte=1 niemals einen Wert zurück liefern wird.

Soweit verstanden?