Im Blog der CBO-Entwicklung erklärt Nigel Bayliss detailliert, wie das Management des Speicherplatzes in den Datenblocks bei direct path load funktioniert. Tatsächlich gibt es in diesem Zusammenhang mehrere unterschiedliche Strategien und erst in 12.1.0.2 wurde die Information, welche Strategie tatsächlich verwendet wird, in den Ausführungsplänen ergänzt. Der Grund für die Verwendung mehrerer Strategien ist dabei, dass das Verfahren in sehr unterschiedlichen Kontexten einsetzbar sein muss: für partitionierte und nicht partitionierte Tabellen, für serielle und parallele Operationen, in Einzel-Datenbank-Instanzen und für RAC-Systeme. Die verwendeten Strategien sind dabei folgende:
High Water Mark (HWM) Loading
Dies ist wohl das einfachste und am leichtesten zu verstehende Verfahren: neue Daten werden in Extents oberhalb der HWM eingefügt. Verwendet werden kann es für serielle Ladeoperationen, parallele Ladeoperationen, die über den partition key (PKEY) verteilt werden, und equi-partition loads (die zum Beispiel dann verwendet werden, wenn Daten zwischen zwei equi-partitioned tables kopiert werden, sofern die Anzahl der Partitionen relativ groß ist).
Temp Segment Merge (TSM) Loading
Der älteste Mechanismus, der für parallele Loads entwickelt wurde, und das Standardverfahren für parallele loads in ein einzelnes Segment in 11.2 (sofern kein Auto-DOP im Spiel ist). Dabei wird jeder parallel execution server producer mit einem temporären Segment verbunden, in das er seine Ergebnisse schreibt, und bei Commit erfolgt ein Merge dieser temporären Segmente. Das Verfahren skaliert recht gut, weil die einzelnen Operationen klar voneinander getrennt sind: eine Erhöhung des DOP verbessert folglich die Performance. Allerdings hängt der DOP mit der minimalen Anzahl ergänzter Extents zusammen: DOP 16 ergänzt also mindestens 16 Extents - was unter anderem auch zu (ich nenn es so, obwohl ich weiß, dass ich dafür im OTN-Forum keine Pluspunkte bekäme) Fragmentierungseffekten führen kann.
High Water Mark Brokering (HWMB) Loading
Dieses Verfahren kann verwendet werden, wenn mehrere PX Server (potentiell) das gleiche Segment füllen. Es wird in 11g und 12c häufig verwendet, wenn mehrere Partitionen gleichzeitig befüllt werden, und ist in 11g das gewählte Verfahren für single-segment loads mit Auto-DOP. Bei diesem Verfahren ist eine Koordinierung der Verschiebung der HWM erforderlich und dafür sorgt eine HV enqueue, die die HWM-Verschiebungen der PX Server Prozesse abstimmt. Bei diesem Verfahren entstehen in der Regel weniger neue Extents als beim TSM-Verfahren.
Hybrid TSM/HWMB Loading in 12c
Wurde insbesondere zur Optimierung von Einzel-Segment loads eingeführt. Im Execution Plan erscheint dafür ein step "LOAD AS SELECT (HYBRID TSM/HWMB)". Das Verfahren kombiniert - wie der Name schon vermuten lässt - die positiven Eigenschaften von TSM und HWMB, insbesondere in RAC-Systemen. Dabei treten wiederum die HV enqueues zur Koordinierung der Verschiebung der HWM in einem Extent auf, aber zusätzlich werden zur gleichen Zeit mehrere temporäre Segmente eingesetzt. Das Verfahren ist besser skalierbar als die beiden Alternativen (vor allem in RAC-Systemen und bei hohem DOP) und reduziert die Anzahl erzeugter Extents. In 12c wird Hybrid TSM/HWMB für INSERT und MERGE in ein Einzel-Segment verwendet (unabhängig von der Verwendung von manuellem oder automatischem DOP). TSM wird weiterhin für bestimmte parallelisierte Muli-Segment-Ladeoperationen verwendet. Vor allem aber erscheint das verwendete Verfahren explizit in den Ausführungsplänen, wo es jeweils beim LOAD AS SELECT erscheint.
Ein hochinteressanter Artikel, denn so detailliert erläutert das CBO-Team die internen Mechanismen selten. Insbesondere die Aufnahme der Information in die Ausführungspläne finde ich ausgesprochen nützlich. Gerne hätte ich die Aussagen ins Deutsche übertragen, aber dem Leser wird aufgefallen sein, dass ich diesmal noch früher aufgegeben habe als üblich und irgendwo zwischen Englisch und Deutsch hängen geblieben bin.
Keine Kommentare:
Kommentar veröffentlichen