Neue Features für Parallel Execution in 12c

Parallele Ausführungspläne lassen mich in der Regel sehr vorsichtig werden, weil ich dabei gerne entscheidende Details übersehe - aber damit bin ich vermutlich kein Einzelfall. "It’s easy to make mistakes, or overlook defects, when constructing parallel queries", schreibt Jonathan Lewis in seinem jüngsten Artikel Parallel Rownum, in dem er einen Fall vorstellt, in dem ein parallelisiertes Select - mit ergänzter Rownum-Spalte - auf eine Tabelle sowie ein im Rahmen der gleichen Query mit einem abweichenden Parallelisierungs-Degree ausgeführtes Insert in eine zweite Tabelle zu unerfreulichen Effekten führen. Einerseits bringt das Rownum Element die Notwendigkeit einer zwischenzeitlichen Serialisierung mit sich, die natürlich ein Bottleneck der Operation darstellen kann. Darüber hinaus führt der unterschiedliche Parallelisierungsgrad des Select- und des Insert-Teils dazu, dass zwei unterschiedliche DFO (= Data Flow Operation) Gruppen ins Spiel kommen und in Folge dessen mehr parallel slaves eingesetzt werden als erforderlich.

Ich habe das Beispiel in meiner 12.1.0.2-Test-Instanz durchgespielt und dabei ein anderes Verhalten beobachtet: dort trat nur ein DFO-Element auf (und auch sonst zeigte der Plan ein paar Abweichungen). Die Erklärung dazu hat Randolf Geist in seinem Kommentar zu meinem Kommentar geliefert: in 12c wurden diverse (potentielle) Verbesserungen für Parallele Operationen eingeführt und eine davon ist die "1 SLAVE" Verteilung, die dafür sorgt, dass nur ein DFO tree bei der Verarbeitung verwendet wird (und folglich die Zahl der verwendeten Slaves beschränkt bleibt). Möglicherweise hätte ich diese Antwort auch selbst finden können, wenn ich meine Blog-Listen in strengerer chronologischer Reihenfolge betrachten würde, denn zu den zum Thema der in 12c eingeführten neuen Features im Kontext der Parallel Execution hat Randolf Geist vor ein paar Tagen einen umfassenderen Artikel veröffentlicht. Dieser erläutert unter anderem folgende Punkte:

• die adaptive HYBRID HASH Verteilung, die es der runtime engine gestattet im Rahmen der Ausführung zu entscheiden, ob eine HASH (= gezielt an einzelne Slaves) oder BROADCAST (= an alle) Verteilung erfolgen soll. Diese Option erlaubt es, Probleme der data distribution skew zu reduzieren, über die Randolf gelegentlich geschrieben hatte (die Links und meine Exzerpte dazu finden sich hier).
• concurrent UNION ALL. Laut Dokumentation galt "Traditionally, set operators are processed in a sequential manner". Das ist nun offenbar anders. Zur Durchführung der parallelen Sub-Operationen dient ein PX SELECTOR.
• PQ_REPLICATE erlaubt es offenbar, einen parallelen FTS durch mehrere Slaves gleichzeitig ausführen zu lassen und die (identischen) Ergebnisse per BRODCAST weiterzuleiten. Das klingt erst mal seltsam, hat aber vermutlich seine Gründe.
• parallel FILTER: erlaubt die parallele Verarbeitung von Filter-Subqueries.
• 1 SLAVE distribution: dient, wie erwähnt, dazu, die Komplexität paralleler Verarbeitungsvorgänge überschaubar zu halten, indem nur ein DFO tree verwendet wird und die seriellen Schritte eines parallelen Plans von einem einzigen Slave eines Slave Sets durchgeführt werden.

Zu jedem dieser Punkte könnte man deutlich mehr (und wohl auch Plausibleres) sagen, aber das hat der Herr Geist ja schon getan. Irgendwann sollte ich dann auch noch dazu kommen, solche Details als aktives Wissen vorzuhalten, statt das vage Gefühl zu entwickeln, schon mal irgendwo etwas Ähnliches gelesen zu haben... - aber immerhin weiß ich, wo ich nachzuschauen habe, wenn ich mich detailliert über Parallel Execution informieren möchte.

Nachtrag 10.07.2015: in einem weiteren Artikel 12c Parallel Execution New Features: PX SELECTOR erläutert Randolf Geist den PX Selector genauer: "In pre-12c [...] serial parts get executed by the Query Coordinator itself, and the new PX SELECTOR changes that so that one of the PX slaves of a PX slave set is selected to execute that serial part. There is not much left to say about that functionality, except that it doesn't get used always - there are still plan shapes possible in 12c, depending on the SQL constructs used and combined, that show the pre-12c plan shape where the Query Coordinator executes the serial part." Darüber hinaus gibt es ein paar Detailinformationen zum Verhalten, die ich hier nicht wiedergebe (die aber - erwartungsgemäß - darauf hindeuten, dass das neue Feature grundsätzlich eine nützliche Ergänzung ist).