Recursive IM_DOMAIN$ Zugriffe

Jonathan Lewis liefert in seinem Scratchpad eine Lösung für ein Problem, das Franck Pachot vor einiger Zeit angesprochen hatte: in Oracle 18c kann es dazu kommen, dass die folgende Query extrem häufig ausgeführt wird und zu Performance-Problemen führt (oder dazu beiträgt):

select domain# from sys.im_domain$ where objn = :1 and col# = :2

Diese interne Query (sprich: recursive query) gehört - wie der Name schon andeutet - in den InMemory Kontext, erscheint beim Parsen einer User-Query mit Hash Join und wird aber auch dann ausgeführt, wenn die IM Optionen gar nicht genutzt werden: und das selbst dann, wenn die User-Query im Session Cursor Cache vorliegt. Um diese Queries loszuwerden, kann man den internen Parameter "_sqlexec_join_group_aware_hj_enabled" in der Session oder systemweit auf false setzen. Das ist natürlich nur eine Option, wenn man InMemory nicht benötigt.

Deaktivierung des APPEND Hints

Jonathan Lewis erläutert in seinem Scratchpad, welche Optionen es gibt, um einen APPEND-Hint zu deaktivieren. Eine solche Deaktivierung kann z.B. wünschenswert sein, wenn die APPEND-Operationen zu einer massiven Verschwendung von Speicherplatz führen, da die durch sie gefüllten Blöcke immer oberhalb der highwater mark (HWM) ergänzt werden. Nicht in Frage kommt in diesem Fall die naheliegende Lösung eines SQL Patches mit einem Hint ignore_optim_embedded_hints, da APPEND kein Optimizer-Hint ist, sondern in die Kategorie "behaviour" gehört. Stattdessen gibt es folgende Optionen, die die APPEND-Operation in ein normales INSERT ändern:

• Ergänzung eines row-level triggers. Ein solcher Trigger führt allerdings auch dazu, dass das "array processing" in ein "single row processing" umgewandelt wird, was eine Erhöhung des redo Volumens hervorruft.
• Verwendung eines non-unique Index zur Unterstützung eines unique constraints. Auch hier kann es zu einem "single row processing". Außerdem hat ein solcher Index in manchen Fällen ungünstige Wirkungen auf die Entscheidungen des Optimizers.
• Ergänzung eines Foreign Key Constraints: in diesem Fall muss zwar eine Prüfung erfolgen, aber anscheinend kein "single row processing".

Somit ist aus Sicht des Herrn Lewis die Ergänzung eines FK auf eine leere Tabelle (mit PK) die beste Option. Dazu muss in der Tabelle, für die der APPEND-Hint problematisch wäre, eine zusätzliche leere und als "invisible" definierte Spalte ergänzt werden, die per FK auf die leere Parent-Tabelle verweist. Da die Spaltenwerte immer NULL sind, ist keine Prüfung der FK-Beziehung erforderlich und auch eine Index-Maintenance entfällt. Aus Sicht der Wartbarkeit könnten die beiden anderen Alternativen aber vielleicht besser handhabbar sein, als diese aus Performance-Sicht vermutlich günstigste Variante.