Brendan Furey erläuert in seinem Blog die Möglichkeiten, die Oracle bietet, die Join-Reihenfolge über Hints zu beeinflussen. Darin weist er zunächst darauf hin, dass der USE_HASH Hint eigentlich nur einen Parameter benötigt und nicht die Angabe der beiden Aliase der Tabellen, die man miteinander verknüpfen will: bei der Angabe von zwei Aliasen betrachtet Oracle dies als zwei Hints und wird folglich einen der beiden übergehen. Welcher der Hints nicht berücksichtigt wird, hängt von der Reihenfolge ab, in der die Tabellen gejoint werden, und in diesem Zusammenhang wird auf einen klassischen "Quiz Night" Artikel von Jonathan Lewis verwiesen, der erläutert, dass im Fall eines 4-Tabellen-Joins, bei dem die Join-Reihenfolge über LEADING Hints und die Join Methode über USE_HASH Hints bestimmt ist, immer noch acht unterschiedliche Pläne entstehen können, weil dadurch noch nicht festgelegt ist, welche rowsource als "build table" und welche als "probe table" zu betrachten ist, was über die Hints SWAP_JOIN_INPUTS und NO_SWAP_JOIN_INPUTS gesteuert werden kann. An dieser Stelle ergänzt der Herr Furey seine Überlegung, dass in diesem Fall eigentlich zwei Ebenen von Sortierungen zu berücksichtigen sind, da man den gleichen Plan mit mehreren unterschiedlichen Hint-Kombinationen hervorrufen kann: eine Outer-level join order (die die Reihenfolge angibt, in der die Tabellen in einem komplexen Join verknüpft werden) und eine Inner-level join order (die anzeigt, auf welcher Seite eine Joins eine Tabelle bei der Verknüpfung mit einer anderen rowsource eingesetzt wird: also im Hash Join etwa als build oder probe table). Nach dieser Definition hat der LEADING Hint unterschiedliche Auswirkungen, abhängig davon, ob ein Hash Join oder ein anderer Join Typ im Spiel ist. Ich denke, das ist eine interessante Art, den Sachverhalt zu betrachten, obwohl ich mir noch nicht ganz sicher bin, ob diese Unterscheidung massive Vorteile bei der Beschreibung der Situation bringt.
Keine Kommentare:
Kommentar veröffentlichen