Randolf Geist über Parallel Execution Skew

Für AllThingsOracle hat Randolf Geist eine kleine Serie zum Thema Parallel Execution Skew gestartet - wobei der Begriff Skew in diesem Kontext die ungleiche Verteilung der zu leistenden Arbeit auf die in der parallelen Verarbeitung verfügbaren Ressourcen bezeichnet.

• Parallel Execution Skew – Introduction: nach der einleitenden Definition folgt der Hinweis, das eine ungleiche Arbeitsverteilung zwischen den parallelen Ressourcen im ungünstigsten Fall zu einer Verlängerung der Laufzeit gegenüber der seriellen Verarbeitung führen kann, da die Parallelisierung einen signifikanten Overhead hervorruft. Im Anschluss wird ein Beispiel vorgeführt, in dem die Parallelisierung eines Joins (Hash Join mit Hash Distribution) sehr effektiv erfolgt und die Ausführung um den Faktor der Parallelisierung beschleunigt. Ohne den folgenden Artikeln vorgreifen zu wollen, lässt sich aus dem Versuchsszenario bereits ableiten, dass die effektive Parallelisierung mit der Datenverteilung für die Join-Spalte zusammenhängt - eine Spalte mit einem prädominanten Wert würde (bzw. wird in den folgenden Artikeln) zu ungünstigeren Ergebnissen führen. Interessant ist auch noch der Hinweis auf das seit 11.2 verfügbare Feature der in-memory Parallel Execution, das die Verwendung des Buffer Caches bei parallelisierten Operationen ermöglicht - in älteren Releases verwendeten parallele Operationen immer direct path reads.
  In Ergänzung zum Artikel hat Randolf Geist in seinem eigenen Blog noch einen weiteren Artikel Parallel Execution Overhead veröffentlicht, der anhand eines Joins mit drei Tabellen zeigt, dass der Parallelisierungseffekt bei komplexeren Operationen aufgrund des Parallelisierungs-Overheads unter Umständen deutlich schwächer ausfällt, auch wenn keine Skew-Effekte im Spiel sind.
  Eine weitere Ergänzung ist das Analysing Parallel Execution Skew - Video Tutorial, das ursprünglich als Teil der XPLAN_ASH-Serie (die ich hier auch mal verlinkt haben dürfte, aber den Link gerade nicht finde) vorgesehen war.
• Parallel Execution Skew – Demonstrating Skew: liefert die Demonstration des in der Einführung erläuterten Verhaltens anhand eines Beispiels mit einem "skewed foreign key" also einer massiven Ungleichverteilung der Werte des Fremdschlüssels mit einem prädominanten Eintrag. Zur Analyse der Aktivität kann die View v$pg_tqstat verwendet werden, die allerdings nur im privaten Speicherbereich der Query Coordinator session gefüllt wird und somit erst nach der erfolgreichen Verarbeitungen und nicht von anderen Sessions aus abgefragt werden kann. Im Ausführungsplan ist die Verknüpfung der Operationen von allem über die Table Queues möglich (zu denen Jonathan Lewis recht umfassende Erklärungen geliefert hat - insbesondere in Teil 3 seiner Artikelserie zum Thema).
  Zeitgleich hat der Herr Geist im eigenen Blog die Teile zwei und drei seines Video Tutorials Analyzing Parallel Execution Skew veröffentlicht, die sicherlich deutlich umfassendere Ausführungen enthalten (Laufzeit jeweils ca. 1h) - aber die Betrachtung verschiebe ich auf einen geeigneteren Zeitpunkt.
• Parallel Execution Skew – 12c Hybrid Hash Distribution With Skew Detection: weist darauf hin, dass es in 12c eine automatische Erkennung und Behandlung von Skew-Effekten gibt, die allerdings nur in bestimmten Fällen verwendbar ist. Voraussetzung ist die Existenz von Histogrammen für die Join-Spalten: wenn popular values existieren, wird eine zusätzliche rekursive Query zur Bestimmung der populären Werte eingesetzt und die ermittelten Werte werden bei der Verteilung an die Slaves speziell behandelt (d.h. per broadcast an alle Worker übermittelt, während die seltenen Werte per hash distribution verteilt werden). Im Plan erscheint ein Step: PX SEND HYBRID HASH (SKEW). Aktuell sind die Einschränkungen für die Verwendung des Features noch relativ groß (nur bei Hash Joins, nicht bei Merge Joins verwendbar; nur für inner joins; nur bei Verwendung eines einzelnen Join-Prädikats einsetzbar etc. - im CBO-Trace findet sich ein Eintrag "Skew handling disabled since conditions not satisfied", wenn die Voraussetzungen nicht erfüllt sind). Weitere technische Details zum Verfahren (und seinen Grenzen) liefern zwei Artikel in Randolf Geists Blog, deren Aussagen ich zum Teil in meine Zusammenfassung des AllThingsOracle-Artikels integriert habe (allerdings längst nicht vollständig, da der Herr Geist die Details mal wieder recht umfassend ausführt: sollte ich diese Details gelegentlich benötigen, weiß ich jedenfalls, wo ich nachschlagen kann).
• Parallel Execution Skew – Addressing Skew Using Manual Rewrites: liefert - was angesichts des Titels nicht allzu sehr überrascht - einige Vorschläge zur manuellen Optimierung paralleler Zugriffe. Erläutert werden dabei folgende Optionen:
• Nachbildung der in 12c eingeführten skew aware Features: dabei wird die Query in zwei Teile gesplittet: einen Zugriff für die non-popular values und einen zweiten per UNION ALL verknüpften Teil für die populären Werte. Das Ergebnis liefert eine gute Performance, ist aber relativ unhandlich und erfordert einen zweifachen Zugriff auf die Daten.
• Verteilung der popular values auf weniger ungleich verteilte Werte mit Hilfe einer Mapping-Tabelle: diese automatische Verteilung kann mit Hilfe einer View dauerhaft hinterlegt werden - das Verfahren sieht interessant aus, ist aber womöglich noch erläuterungsbedürftiger als die erste Variante.

Zum Abschluss der Serie hat der Autor dann noch einen Summary-Artikel mit Links auf die AllThingsOracle-Artikel und die Videos ergänzt.