Verzögerte Cursor Invalidierung nach DDL-Operationen in 12.2

Heute habe ich zwei neue Artikel in meinem Blog-Reader gefunden, die sich mit Themen der verzögerten Invalidierung abhängiger Cursor bei unterschiedlichen DDL-Operationen beschäftigen:

• Richard Foote erläutert das Verhalten im Zusammenhang mit der Anlage von - was war es noch mal? Ach ja: - Indizes. Wenn man nicht möchte, dass die Erzeugung eines neuen Index automatisch alle von der zugehörigen Tabelle abhängigen Cursor invalidiert, dann kann man das in 12.2 durch die Ergänzung der Klausel DEFERRED INVALIDATION beeinflussen. Allerdings ist es durchaus möglich, Szenarien zu erzeugen, in denen das Verhalten nicht unbedingt dem entspricht, was man sich wünschen würde - und natürlich tut das der Herr Foote in seinem Artikel.
• Frank Pachot spricht deferred invalidation im Kontext von partition exchange an. Dabei zeigt er, dass die Spalte v$sql.is_rolling_invalid in diesem Zusammenhang offenbar nicht plausibel aktualisiert wird, obwohl die verzögerte Invalidierung funktioniert. Werden nicht alle Indizes ausgetauscht, ergibt sich allerdings eine sofortige cursor-Invalidierung. Insgesamt kann das Feature nützlich sein, um einen hard-parse-peek beim partition exchange zu vermeiden.

Die verzögerte Invalidierung gab es bereits vor 12.2 im Rahmen von dbms_stats-Operationen und die Ausweitung auf explizite DDL-Operationen erscheint sehr plausibel.

Semantik des parallel(n) Hints

Jonathan Lewis weist in seinem Blog darauf hin, dass der Hint /*+ parallel(n) */ keineswegs einen parallelen Plan erzwingt, auch wenn eine ausreichende Anzahl an parallelen Ausführungsprozessen zur Verfügung steht. Tatsächlich weist der Hint den Optimizer nur dazu an, die Kosten der parallelen Ausführung für jeden überprüften Plan zu berücksichtigen - aber letztlich wählt der Optimizer den Plan mit den niedrigsten Kosten (sofern kein Bug im Spiel ist) und das kann durchaus ein serieller Plan sein.

Dazu liefert der Artikel ein Beispiel dafür, wie sich das Verhalten zwischen unterschiedlichen Releases verändern kann: für die Beispielquery eines (eindeutigen) id-Zugriffs liefert 11.2.0.4 auch bei Verwendung eines parallel(4)-Hints einen seriellen Plan, was beim Index-Zugriff auf einen einzelnen Datensatz durchaus verständlich ist. Erst wenn man den Zugriff mit einem zusätzlichen FULL-hint ergänzt, ergibt sich die Parallelisierung. In 12.2.0.1 sieht das Verhalten anders aus: dort erscheint ein PX SELECTOR im Plan, der eine hash distribution über Blockadressen ermöglicht, was im Fall globaler Indizes in partitionierten Tabellen hilfreich sein könnte. Das Phänomen hat Jonathan Lewis bereits vor knapp einem Jahr in einem anderen Artikel beschrieben.

Online Partitionierung einer existierenden Tabelle in 12.2

Eine sehr schöne Ergänzung der Partitionierungs-Optionen in 12.2 beschreibt Maria Colgan in ihrem Blog: die Möglichkeit, eine nicht partitionierte Tabelle ohne downtime - also online - in eine partitionierte Tabelle umzuwandeln. Die Syntax dazu sieht etwa folgendermaßen aus:

alter table t
partition by ...
(
   partition p1 ...,
   partition p2,
 ...
)
update indexes online

Das sieht für mich sehr intuitiv und vor allem kompakt aus. Dabei dient "update Indexes" wie üblich dazu, die Indizes während des Aktualisierungsvorgangs verfügbar zu halten. Die Default-Optionen bei der Umwandlung der Indizes sind folgende:

• Indizes, die bereits als "global partitioniert" angelegt wurden, behalten ihr Partitionierungs-Schema
• Indizes, die nicht mit dem "partition key" starten, werden "global non-partitioned indexes"
• Indizes, die mit dem "partition key" starten, werden lokal partitionierte Indizes
• Bitmap Indizes werden zu lokal partitionierte Indizes

Dass man diese Default-Optionen überschreiben kann, ist bei Frau Colgan nur implizit angedeutet (nämlich durch die Verwendung des Terminus "default"), aber Richard Foote hat dazu vor kurzem ein Beispiel veröffentlicht: auf das "update indexes" folgen dann in Klammern die Spezifikationen der Konvertierung.

Eine zweite nützliche Ergänzung zur Partitionierung in 12.2 ist die Möglichkeit, die Basis-Tabelle für eine "partition Exchange" Operation mit einem Befehl "create table ... for exchange with table ..." anzulegen. Allerdings scheint dieses Kommando nicht zur automatischen Generierung der passenden lokalen Indizes zu dienen, so dass hier weiterhin eine gewisse Sorgfalt bei der Vorbereitung des partition exchange erforderlich bleibt - was aber insofern kein größeres Problem darstellt, als der Austausch von Partitionen aus meiner Sicht ohnehin ein Task ist, der verskriptet werden sollte.

Darüber hinaus erwähnt die Autorin noch eine dritte nützliche Ergänzung: die Einführung von interval partitioning für List-partitionierte Tabellen. Dabei hoffe ich, dass die Intervall-Partitionierung in 12.2 stabiler geworden ist, als sie das in früheren Releases geworden ist, aber das ist ein Thema, das im Artikel nicht angesprochen wird - und dem im Detail nachzugehen mir aktuell die Zeit fehlt.