Montag, Juli 02, 2012

Rebuild eines partitionierten Index mit Komprimierung

Richard Foote bezeichnet die Index Compression als "perhaps one of the most under used and neglected index options available." Und wenn der Herr Foote so etwas schreibt, dann entspricht das vermutlich den Tatsachen. In seinem Blog findet man eine kleine Serie (aus dem Jahr 2008) zum Thema, die die folgenden vier Beiträge umfasst:
Grundsätzlich dient index compression dem gleichen Zweck wie die table compression - nämlich dazu, die Größe eines Segments in der Datenbank zu reduzieren, um damit - auf Kosten eines relativ harmlosen CPU-Overheads - Storage und I/O-Operationen beim Zugriff einzusparen, was fast in jedem Fall ein sinnvoller Handel ist. Die technische Implementierung ist dabei allerdings eine andere, denn die index compression ersetzt immer nur führende wiederholte Werte im Index, was ihre initiale Definition etwas komplizierter macht als die Tabellen-Komprimierung. Umgekehrt bringt die Index-Komprimierung dafür nicht den Nachteil, dass nachfolgende UPDATEs die Segment-Struktur durcheinander bringen und die Größe des Objekts ungünstig beeinflussen. Ein Nachteil der index compression ist allerdings, dass sie auf Partitionsebene nicht nachträglich definiert und beim rebuild berücksichtigt werden kann, sondern einheitlich für das komplette Objekt bei der Anlage angegeben sein muss, was den Umbau bestehender Indizes etwas komplizierter macht (will heißen: eine Löschung und einen Neuaufbau erfordert). Einen entsprechenden Hinweis mit dem Verweis auf das MOS-Dokument 312843.1 "Rebuild a partitioned index specifying compression raises Ora-28659" findet man hier.

2 Kommentare:

  1. Ein Nachteil der index compression ist allerdings...
    Ist das heute auch noch so?

    AntwortenLöschen
    Antworten
    1. gute Frage: das müsste ich mir gelegentlich mal anschauen - wobei ich es nicht für unwahrscheinlich halte, dass das Verhalten inzwischen geändert wurde.

      Löschen