Erst mal meine Entschuldigung für den Titel - eine brauchbare Übersetzung für "unusable indexes" ist mir nicht eingefallen (und über "direct path inserts" mache ich mir nicht einmal mehr Gedanken). Dann zum Thema: im OTN Forum wurde heute die Frage diskutiert, in welchen Fällen man Indizes vor einem Massenladevorgang UNUSABLE setzen und nach der Ladeoperation wieder neu aufbauen lassen kann, worauf die Antwort lautet, dass das Verfahren mit bitmap und non-unique B*Tree-Indizes problemlos funktioniert, mit einem unique B*Tree-Index aber zu Fehlern führt ("ORA-26026: unique index ... initially in unusable state" für direct path inserts und "ORA-01502: index ... or partition of such index is in unusable state" für conventional path inserts). Dieses Verhalten kann man unter Umständen als Argument dafür sehen, Primary Key Constraints durch non-unique Indizes zu unterstützen. Im Thread hat Randolf Geist allerdings auf einen ziemlich hässlichen Fehler hingewiesen, den er vor mehreren Jahren in seinem Blog beschrieben hatte: in eine Tabelle mit aktivem PK und einem diesen Constraint unterstützenden und auf UNUSABLE gesetzten non-unique Index kann man via direct path Daten einfügen, die dem Constraint widersprechen, und anschließend den Index neu aufbauen - und das ohne irgendeine Fehlermeldung: der Constraint ist VALIDATED und ENABLED, aber die Daten entsprechen ihm nicht. Bei Verwendung von conventional path loads trat der Fehler nicht auf. Dieser - recht dramatische - Bug existierte mindestens seit 11.1.0.6 und wurde offenbar in 12.1 behoben - und diese Behebung gelangte als Backport auch nach 11.2.0.4. Seltsam ist bei der Behebung übrigens noch, dass das direct path insert auch in diesem Fall "ORA-26026: unique index ... initially in unusable state" liefert, obwohl der Index offensichtlich nicht UNIQUE ist - aber das eigentliche Problem ist beseitigt. Code-Beispiele zum Verhalten spare ich mir diesmal, da sie im Thread zu finden sind.
Keine Kommentare:
Kommentar veröffentlichen