Primary Key nicht im Plan ???

[Lutz Bodes]

Hallo zusammen,

ich habe folgendes Problem.

Alle betroffenen Tabellen haben einen Primärschlüssel und Foreign Key Constraints.

Z.B. create table t1 (
f1 integer not null primary key,
f2 varchar(100) ...
);

Ein
select f1 from t1 where f1 = 1234

führt trotz vorhandenem
Primärschlüssel RDB$PRIMARY421 "nach frischem Recover" zu einem
NATURAL SCAN im PLAN.

Wenn ich den in RDB$INDICES vorhandenen Primärschlüssel suche, wird
er gefunden und trotzdem kommt es zu einer Fehlermeldung
"Der Index RDB$PRIMARY421 ...kann für die Tabelle T1 nicht gefunden werden"
wenn ein PLAN mitgegeben wird

select f1 from t1 where f1 = 1234
PLAN SORT (T1 ORDER RDB$PRIMARY421)

Lege ich jetzt einen neuen Index IX1 auf F1

create index IX1 on T1(F1);

nimmt der Optimizer sofort den neuen Index im Plan auf.

Auch ein

select f1 from t1 where f1 = 1234
PLAN SORT (T1 ORDER IX1)

funktioniert richtig.

Warum wird der Primärschlüssel (oder auch Foreign Key Indices in anderen Tabellen) nicht verwendet ??? Kennt jemand das Problem, das Firebird
seine Primär-/Fremdschlüssel vergisst ?

Weiterhin habe ich festgestellt, das nach dem Recover auch die Trigger
extrem langsam laufen. Nach dem ACTIVE/INACTIVE-Setzen der normalerweise
im PLAN des Optimizers vorhandenen Indices werden diese auch wieder verwendet.

Bin für jede Info dankbar.

Gruß
Lutz Bodes

[Thomas Steinmaurer]

Hallo Lutz,<br><br>
klingt doch alles etwas seltsam. Ich hab mir mal eine Tabelle mit einem Primary Key angelegt und 2 Datensätze eingefügt, committed und danach eine Abfrage auf diese Tabelle mit einer WHERE Bedingung auf die PrimaryKey Spalte. Der PrimaryKey wird verwendet. Ich habe hier eigentlich nur 1 Vermutung. Wenn bei Dir 'Recover' gleichbedeutend mit einem Firebird 'Restore' ist, dann wurde vielleicht das Restore mit der Option, dass Indizes deaktiviert sein sollen, durchgeführt.<br><br>
Gruss,<br>
Thomas Steinmaurer<br>
IB LogManager 2.0 - The Logging/Auditing Tool for InterBase and Firebird<br>
http://www.iblogmanager.com<br&gt

[Lutz Bodes]

Hallo Thomas,
restore war natürlich gemeint.

Die Indices sind definitiv vorhanden.
Ich vermute, das Indexpage-Fehler aufgetreten sind,
die nicht korrekt "repair"ed wurden.
Die DB zeigt keine Fehler und die Indices sind in
RDB$INDICES auch vorhanden aber sie werden definitiv
nicht mehr verwendet. Es bleibt unklar warum.

Gruß
Lut

[Thomas Steinmaurer]

Hallo Lutz,<br><br>
es geht nicht nur darum, dass die Indizes vorhanden sind, sondern dass sie auch aktiv sind. Beim Restore kann man angegeben, ob mit deaktivierten Indizes zurückgesichert werden soll.<br><br>
Führ mal folgendes Statement aus:<br><br>
select * from rdb$indices where rdb$index_inactive = 1<br><br>
Das gibt Dir alle deaktivierten Indizes zurück.<br><br>
Gruss,<br>
Thoma

[Lutz Bodes]

Hallo Thomas,

die Indices sind aktiv, das hatte ich überprüft.

Ich habe testweise, obwohl in der SQL-Referenz steht, das dies
eigentlich nicht geht UNIQUE,PRIMARY und FOREIGN KEYS deaktiviert
und versucht sie wieder zu aktivieren. Dabei kommt es zu einer
internen Fehlermeldung beim Aktivieren. Deaktivieren ging.

"Internal GDS-Software Error ...(Can't continue after bug check)"

Ich muß die DB wohl neu aufbauen.

Danke für den Tip

Lutz Bode