Bitmap Indizes machen eine Menge Ärger, wenn es um DML geht. Diese Erkenntnis ist nicht neu und weitgehend richtig, und ich habe hier auch schon mal gelegentlich einen - eher anekdotischen - Fall vorgeführt, in dem ein Insert in eine Tabelle mit Bitmap Index deutlich langsamer von statten ging als ein entsprechendes Insert in eine Tabelle mit B*Tree Index (wobei ich bei erneuter Betrachtung des Beispiels darüber nachdenke, ob das Ergebnis nicht ziemlich massiv durch eine unglückliche Dimensionierung der redo log files beeinflusst war). Nun hat Jonathan Lewis einen Artikel zum Thema veröffentlicht, der erklärt, warum ein Insert im Bitmap-Fall auch schneller erfolgen kann als im B-Tree-Fall und inwiefern dieses Verhalten erklären könnte, wieso Bitmap Indizes nicht zur Vermeidung eines Table Locks beim Löschen von Datensätzen aus der zugehörigen Parent-Tabelle verwendet werden können. Das gleiche Thema hat übrigens dieser Tage auch Richard Foote in seinem Blog angesprochen, dabei aber eine andere Argumentationslinie verfolgt und den Artikel nach einem Kommentar des Herrn Lewis auch noch mal überarbeitet.
Die Antwort auf die angesprochene Frage ist - wie das im Fall von Antworten, die man kennt, ja häufiger vorkommt - eigentlich ganz einfach: ein Blick auf die Session Statistiken eines entsprechenden Test-Falls zeigt, dass die Maintenance des B*Tree-Index sehr viel größere Ressourcen erfordert als die des Bitmap-Index, mehr LIOs, mehr Redo und Undo, mehr Memory in PGA/UGA etc. Diese Statistiken habe ich in einem Kommentar im Scratchpad aufgeführt, und Jonathan Lewis schreibt dazu:
As Martin has pointed out, there are a number of statistics that show large differences between the B-tree and bitmap approaches, but the one he didn’t mention was the key: sorts (rows).
Also knapp vorbei - schade eigentlich... Die Lösung lautet: Oracle verschiebt die Bitmap-Index-Maintenance ans Ende der Insert-Operation - in ähnlicher Weise wie das im Fall eines direct path Inserts für alle Index-Typen geschieht. Die vorsortierten Werte werden dann in den Index-Baum ge-merged, was I/O, Block-Splits etc. minimiert. Andererseits macht diese Verzögerung eine Verwendung im Rahmen der FK-Lock-Vermeidung unmöglich. Eine ähnliche Verzögerungsstrategie kann Oracle offenbar auch bei Delete- und Update-Operationen verwenden. Wie gesagt: ganz einfach, wenn man die Lösung kennt.
Keine Kommentare:
Kommentar veröffentlichen