Oracle TEXT (Teil II): New Features Oracle TEXT 12c

Das Anlegen eines Oracle TEXT Index kann unter Umständen sehr lange dauern. Ein Grund dafür kann die Default-Memory-Einstellung sein, die lediglich bei 64 MB liegt. Mit einer Vergrößerung der Default Memory-Einstellung kann die Performance beim Anlegen des Oracle TEXT Index verbessert werden.

In Oracle 11g lag die maximal wählbare Memory-Einstellung MAX_INDEX_MEMORY bei 2 GB. Mit Oracle 12c wurde MAX_INDEX_MEMORY auf 256 GB erweitert. Abgefragt werden können die Memory-Einstellungen über die Tabelle CTX_PARAMETERS (siehe Abbildung 1).

Die Memory-Größe kann im CREATE INDEX Statement oder über die Änderung der Parameter mit dem Package CTX_ADM eingestellt werden. Das Beispiel in Abbildung 2 zeigt die Nutzung beim Anlegen des Index und die Änderung der Default-Einstellungen über das Package CTX_ADM. Der Memory-Parameter sollte - unter Berücksichtigung des dem System zur Verfügung stehenden Arbeitsspeichers - so hoch wie möglich gesetzt werden.

Im Gegensatz zu einem normalen Index ist ein Oracle TEXT Index bei Änderungen auf der Basistabelle nicht automatisch aktuell. Immer häufiger gibt es die Anforderung, den Oracle TEXT Index auch bei großer Änderungsrate auf der Basistabelle aktuell zu halten. Dies kann man mit einem manuellen SYNC-Befehl erreichen. Die Aktualität des Index ist dann abhängig von der Häufigkeit der manuellen Synchronisation. Mit der Option SYNC ON COMMIT kann beim Erstellen des Oracle TEXT Index dafür gesorgt werden, dass die Änderungen auf der Basistabelle sofort in den Oracle TEXT Index eingepflegt werden. Der Nachteil dieser beiden Möglichkeiten ist jedoch, dass die neuen Änderungen in den Index einfach nur in der $I-Token-Tabelle angefügt und nicht in der richtigen Reihenfolge sortiert abgelegt werden. Dies hat eine starke Fragmentierung des Index zur Folge und führt zu einer schleichenden Performance-Verschlechterung.

Mit dem neuen Feature „Near Real Time Index" führt Oracle in 12c einen zweistufigen neuen Oracle TEXT Index ein. Neben der Haupt-Token-Tabelle $I werden geänderte Daten in der Token-Tabelle $G abgelegt. Beim Suchen über den Oracle TEXT Index werden beide Token-Tabellen $I und $G durchsucht. Die $G-Tabelle ist in der Regel sehr klein und liegt daher in der SGA und kann auch im Keep-Pool gehalten werden. Für das Erstellen eines „Near Real Time Index" muss die neue Storage-Option STAGE_ITAB verwendet werden (siehe Abbildung 3).

In einem Maintenance-Job müssen irgendwann die Token aus der $G-Tabelle in den Oracle TEXT Index ($I-Tabelle) eingepflegt werden. Dies geschieht mit dem Merge-Befehl. Danach sollte mit einem Optimize-Job die $I-Tabelle „rebuild" werden (siehe Abbildung 4).

Zur Erinnerung: In der Token-Tabelle DR$<Indexname>$I des Oracle TEXT Index stehen die Tokens/Wörter und Informationen über deren Vorkommen in den Dokumenten bzw. Tabellen. Diese Informationen werden in der Spalte Token_Info als BLOB abgespeichert. In dieser Spalte werden standardmäßig maximal 4000 Bytes gespeichert. Häufig vorkommende Wörter werden daher mehrfach in die Tabelle DR$<Indexname>$I abgespeichert.

Mit der BIG_IO-Option wird in 12c, unter Verwendung von Securefiles mit großen Chunks, die Grenze von 4000 Bytes aufgehoben. Es werden nun gleiche Wörter nicht mehrfach, sondern weniger Einträge pro Token in der $I-Tabelle gespeichert. Die Byte-Größe pro Eintrag in der Token-Tabelle wird zwar größer, aber die Anzahl der Einträge wird deutlich reduziert. Der Oracle TEXT Index wird dadurch kleiner und beim Lesezugriff müssen weniger Indexsegmente gelesen werden. Die BIG_IO-Option wird als Storage-Attribut konfiguriert wie in Abbildung 5 zu sehen ist.

Der Query Filter Cache ist ein Ergebnis-Cache für Oracle TEXT Abfragen. Die Ergebnisse dieser Abfragen werden in einen separaten Speicherbereich abgelegt und können wiederverwendet werden. Mit einer Storage Preference kann der Query Filter Cache aktiviert werden. Der Index wird dann mit dieser Storage Preference angelegt (siehe Abbildung 6).

Der Query Filter Cache kann jedoch nur für einfache Abfragen eingesetzt werden. Eine Progressive-Relaxion-Abfrage (mehrere Abfragen auf einmal) mit dem Query Filter Cache zu kombinieren ist nicht möglich. In der SQL-Abfrage muss der Query Filter Cache explizit angesprochen werden. Mit den zusätzlichen Optionen save_score oder nur topN by score kann der Score ebenfalls im Cache berücksichtigt werden (Abbildung 7). Ob der Query Filter Cache verwendet wurde, kann in der Tabelle CTX_FILTER_CACHE_STATISTICS abgefragt werden.