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.
Keine Kommentare:
Kommentar veröffentlichen