LOCAL Primary Key wird nach CONSTRAINT DISABLE/ENABLE GLOBAL angelegt

von Tobias Redmann

Um eine partitionierte Tabelle mit Daten zu füllen, habe ich alle Indizes sowie alle Constraints dieser Tabelle deaktiviert (DISABLE). Nachdem alle Daten eingefügt wurden, wurden mittels ALTER TABLE XXX ENABLE CONSTRAINT YYY die entsprechenden CONSTRAINTS wieder angeschaltet (ENABLE).

Dabei ist mir aufgefallen, dass der zuvor angelegte local Primary Key Constraint nun global angelegt wurde.

Ein kleines Beispiel verdeutlicht dieses Verhalten

Getestet wurde dieses Scripte auf einer Oracle 11gR2 Datenbank.

-- Partitionierte Tabelle anlegen
CREATE TABLE BESSERDICH_PARTITIONIERT
    (  JAHR         NUMBER (4)   NOT NULL
     , ID           NUMBER (18)  NOT NULL     
     , Beschreibung VARCHAR2(1000)
     )
PARTITION BY RANGE (JAHR)
    (
    PARTITION JAHR_2012 VALUES LESS THAN ( 2013 ),
    PARTITION JAHR_2013 VALUES LESS THAN ( 2014 ),    
    PARTITION JAHR_MAX VALUES LESS THAN ( MAXVALUE )
    );

-- Local partitionierten Constraint (Primary Key) anlegen
ALTER TABLE BESSERDICH_PARTITIONIERT
ADD CONSTRAINT BP_PK PRIMARY KEY ( JAHR,ID) USING INDEX
    LOCAL 
    (
    PARTITION BTJAHR_2012 ,
    PARTITION BTJAHR_2013 ,
    PARTITION BTJAHR_MAX
    ) ;

-- Prüfung ob PK partitioniert ist - JA
Select   
  t.partitioned
, t.*
from user_indexes t
where t.index_name = 'BP_PK';

-- Primary Key Constraint ausschalten
ALTER TABLE BESSERDICH_PARTITIONIERT disable CONSTRAINT BP_PK;

--
-- Datenimport
--

-- Primary Key Constraint wieder einschalten
ALTER TABLE BESSERDICH_PARTITIONIERT enable CONSTRAINT BP_PK;

-- Prüfung ob PK partitioniert ist - NEIN!
Select   
  t.partitioned
, t.*
from user_indexes t
where t.index_name = 'BP_PK';

-- Partitionierte Tabelle anlegen

CREATE TABLE BESSERDICH_PARTITIONIERT

( JAHR NUMBER (4) NOT NULL

, ID NUMBER (18) NOT NULL

, Beschreibung VARCHAR2(1000)

)

PARTITION BY RANGE (JAHR)

(

PARTITION JAHR_2012 VALUES LESS THAN ( 2013 ),

PARTITION JAHR_2013 VALUES LESS THAN ( 2014 ),

PARTITION JAHR_MAX VALUES LESS THAN ( MAXVALUE )

);

-- Local partitionierten Constraint (Primary Key) anlegen

ALTER TABLE BESSERDICH_PARTITIONIERT

ADD CONSTRAINT BP_PK PRIMARY KEY ( JAHR,ID) USING INDEX

LOCAL

(

PARTITION BTJAHR_2012 ,

PARTITION BTJAHR_2013 ,

PARTITION BTJAHR_MAX

) ;

-- Prüfung ob PK partitioniert ist - JA

Select

t.partitioned

, t.*

from user_indexes t

where t.index_name = 'BP_PK';

-- Primary Key Constraint ausschalten

ALTER TABLE BESSERDICH_PARTITIONIERT disable CONSTRAINT BP_PK;

-- Datenimport

-- Primary Key Constraint wieder einschalten

ALTER TABLE BESSERDICH_PARTITIONIERT enable CONSTRAINT BP_PK;

-- Prüfung ob PK partitioniert ist - NEIN!

Select

t.partitioned

, t.*

from user_indexes t

where t.index_name = 'BP_PK';

Warum verhält sich die ORACLE DB so?

Auf diversen Foren im Internet konnte ich folgende Begründung finden. ORACLE löscht den bei der Erstellung des Constraints automatisch erstellten UNIQUE INDEX beim Auschalten (DISABLE) des Primary Key Constraint.
Das hat zur Folge, dass die Storageoptionen (LOCAL + Partitioninformationen) verloren gehen!

Diese Verhalten ist, wenn man es nicht weiß, extrem gefährlich und kann u.U. das Laufzeitverhalten seiner DB negativ beeinflussen. Nicht umsonst wurde im Vorfeld bewusst ein local Primary Keys Constraint angelegt.

Wie kann ich dieses Verhalten umgehen?

Leider hilft hier nur den Primary Key Constraint zu löschen und diesen dann nach dem Datenimport wieder neu zu erstellen.

-- Primary Key Constraint löschen
ALTER TABLE BESSERDICH_PARTITIONIERT DROP CONSTRAINT BP_PK;

--
-- Datenimport
--

-- Primary Key Constraint erneut anlegen
ALTER TABLE BESSERDICH_PARTITIONIERT
ADD CONSTRAINT BP_PK PRIMARY KEY ( JAHR,ID) USING INDEX
    LOCAL 
    (
    PARTITION BTJAHR_2012 ,
    PARTITION BTJAHR_2013 ,
    PARTITION BTJAHR_MAX
    ) ;

-- Primary Key Constraint löschen

ALTER TABLE BESSERDICH_PARTITIONIERT DROP CONSTRAINT BP_PK;