Verlagern von Primary Key Indizes

Wenn in einem Dbspace nur noch sehr wenig Platz vorhanden ist, kann man entweder einen neuen Chunk hinzufügen, Daten löschen, oder Daten in andere Dbspaces verlagern. Neben Tabellen bieten sich hierfür auch Indizes an. Gerade diese nehmen häufig viel Platz ein, und auch aus Performancesicht ist es ratsam, Indizes in anderen Dbspaces als die Daten selbst zu speichern: Während bei Anfragen in einem Dbspace der Index durchsucht wird, können in einem anderen Dbspace (wenn es sich auf einer anderen Platte befindet) parallel die zugehörigen Daten durchsucht werden.

Ein Problem beim Verlagern von Indizes stellen die automatisch generierten Indizes auf Primärschlüssel dar: Diese haben in ihrem Namen ein führendes Leerzeichen (z.B. " 100_1"), was es DDL-Statements unmöglich macht, diese zu bearbeiten. Einen Ausweg aus der Misere erreicht man wie folgt:

  1. Droppen des Primärschlüsselconstraints

    Zunächst wird mittels
    alter table <table_name> modify <column_name> <data_type> not null;

    der Primärschlüsselconstraint auf diese Spalte gelöscht.
    Beispiel:

    alter table customer modify customer_num integer not null;

  2. Anlegen eines unique Index

    Auf die ehemalige Primärschlüsselspalte wird manuell ein unique index angelegt, wobei das gewünschte Dbspace für diesen Index angegeben wird:
    create unique index <index_name> on <table_name>(<column_name>) in <dbspace_name>;

    Beispiel:

    create unique index idx_cust on customer(customer_num) in freespace;

  3. Neuanlegen des Primärschlüsselconstraints

    Mittels des folgenden Befehls wieder der Primärschlüsselconstraint angelegt:
    alter table <table_name> modify <column_name> <data_type> not null primary key;

    Beispiel:

    alter table customer modify customer_num integer not null primary key;

  4. Neuanlegen der Fremdschlüsselconstraints

    Da beim Droppen des Primärschlüsselconstraints automatisch alle zugehörigen Fremdschlüsselconstraints ebenfalls gelöscht werden, müssen diese in allen referenzierten Tabellen neu angelegt werden.
    alter table <table_name> add constraint (foreign key (<column_name>) references <table_name>);

    Beispiel:

    alter table "informix".orders add constraint (foreign key (customer_num) references "informix".customer );



Effekt der vier Schritte:
Der unter 3. angelegte Primärschlüsselconstraint findet bereits den unter 2. in einem ausgewählten Dbspace manuell angelegten Unique Index, und nutzt diesen.
Diesen Index kann man nun auch

  • enablen/disablen
  • in optimizer directives verwenden
  • droppen und neuerstellen
  • mittels "alter fragment" in andere Dbspaces verlagern.

Fazit:
Das Verfahren sollte, bevor es in einer Produktivumgebung eingesetzt wird, unbedingt ausgiebig getestet werden. Im Verlieren von referential contraints besteht ein großes Fehlerpotential, wenn diese nicht, wie unter 4. beschrieben, neu angelegt werden. Bei sorgfältigem Vorgehen und konsequentem Nachziehen der Fremdschlüsselconstraints stellt es jedoch eine praktikable Lösung zum Verlagern automatisch erzeugter Indizes dar.