Urs Meier Art der Info Technical Info (Februar 2002) Aus unserer Projekterfahrung und Forschung

Transkript

1 Betrifft Optimizer Autor Urs Meier Art der Info Technical Info (Februar 2002) Quelle Aus unserer Projekterfahrung und Forschung Einführung Mit jedem Oracle Release nimmt die Anzahl Features zu. Nicht nur für uns ist es schwierig die Übersicht zu behalten, auch der Oracle Optimizer muss mit immer mehr komplexen Fällen fertig werden. Man denke hier zum Beispiel nur an Object-Tables, Index Organized Tables oder Datawarehouse-Features wie Materialized Views mit Query-Rewrite. Umso erfreulicher ist die Tatsache, dass mit Oracle9i einige grundlegende Verbesserungen eingeführt wurden. Dieser Artikel beleuchtet kurz eine der Schwächen des Oracle Optimizers, die Sub- Queries, und zeigt, was mit Oracle9i besser geworden ist. Der Test basiert auf dem Vorschlag von Hermann Sauer, dessen Buch (Relationale Datenbanken, Theorie und Praxis, Addision-Wesley) ich bestens empfehlen kann. Wer sich mit dem Oracle Optimizer genauer auseinander setzen möchte, dem empfehle ich den Trivadis Workshop Oracle Optimizer. Testfall Wir erstellen zwei Tabellen. Die erste Tabelle klein hat 10 Records, die zweite Tabelle gross hat 1'000'000 Records. Danach joinen wir die beiden Tabellen, das Resultat wird immer der kleineren Tabelle entsprechen, also 10 Rows. create table klein (k integer); create table gross (g integer); -- create 10 records 0..9 insert into klein(k) values(0); insert into klein(k) values(1); insert into klein(k) values(2); insert into klein(k) values(3); insert into klein(k) values(4); insert into klein(k) values(5); insert into klein(k) values(6); insert into klein(k) values(7); insert into klein(k) values(8); insert into klein(k) values(9); -- create records insert into gross(g) select k1.k* k2.k* k3.k*1000+ k4.k*100+ k5.k*10+ k6.k

2 from klein k1, klein k2, klein k3, klein k4, klein k5, klein k6; -- index both tables create index i_klein on klein(k); create index i_gross on gross(g); -- get statistics for the optimizer BEGIN dbms_stats.gather_table_stats ( ownname => user,tabname => 'KLEIN',cascade => true ); END; / BEGIN dbms_stats.gather_table_stats ( ownname => user,tabname => 'GROSS',cascade => true ); END; / Nun kommen die Joins, welche der Oracle Cost-Based Optimizer schon seit einigen Versionen immer richtig optimiert (der alte Rule-Based Optimizer hätte hier übrigens schon Probleme). Die einzelnen Statements unterscheiden sich in der Reihenfolge im FROM und der Join-Attribute.,klein WHERE g=k;,klein WHERE k=g;,gross WHERE g=k;,gross WHERE k=g;

3 Resultate mit Joins Der Optimizer erkennt diesen einfachen Fall und optimiert alle 4 Varianten identisch und korrekt. Driving Table (oder Index) über die Tabelle KLEIN und Join-Methode Nested Loop für kleines Join-Resultat (10 Rows) sowie Index-Zugriff auf die Tabelle GROSS im inneren Loop: SQL> 2,gross 3 WHERE k=g; K G SELECT STATEMENT Optimizer=CHOOSE (Cost=12 Card=10 Bytes=60) NESTED LOOPS (Cost=12 Card=10 Bytes=60) INDEX (FULL SCAN) OF 'I_KLEIN' (NON-UNIQUE) INDEX (RANGE SCAN) OF 'I_GROSS' (NON-UNIQUE) Nun kommen die Varianten mit den Sub-Queries. WHERE g IN (SELECT k ); WHERE EXISTS ( WHERE k = g); WHERE k IN (SELECT g );

4 WHERE EXISTS ( WHERE k = g); Resultate mit Sub-Queries Natürlich erwartet man für die Sub-Queries den gleichen Execution-Plan wie für die Joins. Dies ist leider nicht der Fall. Bis und mit Oracle8i wurden die Sub-Queries leicht anders optimiert und 2 der 4 Queries waren katastrophal falsch (Antwortzeit rund 40 Sekunden oder beinahe 100x langsamer). Oracle9i geniert hier zwei unterschiedliche s. Einerseits die normale Oracle Sub-Query Optimierung, wie schon in den Vorgänger Versionen, z.b. SQL> 2 3 WHERE EXISTS ( 4 5 WHERE k = g); G SELECT STATEMENT Optimizer=CHOOSE (Cost=15 Card=10 Bytes=60) NESTED LOOPS (Cost=15 Card=10 Bytes=60) SORT (UNIQUE) INDEX (FULL SCAN) OF 'I_KLEIN' (NON-UNIQUE) (Cost=1 Card=10 INDEX (RANGE SCAN) OF 'I_GROSS' (NON-UNIQUE) Bei den Oracle8i Problemfällen stellt Oracle9i automatisch auf den Semi-Join um, z.b: SQL> 2 3 WHERE k IN (SELECT g 4 ); K

5 SELECT STATEMENT Optimizer=CHOOSE (Cost=12 Card=10 Bytes=60) NESTED LOOPS (SEMI) (Cost=12 Card=10 Bytes=60) INDEX (FULL SCAN) OF 'I_KLEIN' (NON-UNIQUE) (Cost=1 Card=10 Bytes=20) INDEX (RANGE SCAN) OF 'I_GROSS' (NON-UNIQUE) (Cost=2 Card= Oracle9i optimiert also auch alle 4 Sub-Queries korrekt, wenn auch mit einem anderen als bei den Joins. Die ehemals katastrophal langsamen Sub-Queries werden mit dem SEMI-Join optimiert (ein SEMI-Join eliminiert Wiederholungen im Join-Resultat). Wer sich mit den undokumentierten INIT.ORA Parameter auskennt (und das sollte jeder, der den Oracle Optimizer etwas kitzeln will), weiss, dass die SEMI-Joins bereits mit Oracle8i manuell forciert werden können. Fazit Oracle9i hat einige undokumentierte Änderungen von Oracle8i nun permanent implementiert, dazu gehört die Sub-Query Optimierung durch Semi-Joins. Die im Artikel gezeigten Tests wurden mit den Default Oracle9i Parametern vorgenommen. Oracle9i optimiert Sub-Queries jedoch noch immer nicht identisch wie die Joins. Die hier gezeigte Fallstudie ist natürlich keine Herausforderung für einen Optimizer. Oracle kann das Problem aber erst mit der jüngsten Version lösen. Bei komplexeren Sub- Queries stösst man noch immer auf Probleme. Die Empfehlung lautet deshalb nach wie vor: a) Wo immer möglich JOINs und nicht Sub-Queries verwenden b) Correlated Sub-Queries (normalerweise EXISTS/NOT EXISTS) müssen in der Haupt-Query eine gute Restriktion (WHERE-Klausel aufweisen) c) Uncorrelated Sub-Queries (normalerweise IN) müssen in der Sub-Query eine gute Restriktion aufweisen Mit optimalen Grüssen Urs Meier Mail: urs.meier@trivadis.com Trivadis AG Tel: Kanalstrasse 5 Fax: Glattbrugg Internet: