Korruption in Firebird-DB (Indizes?)

[urs.liska]

Hallo Leute,

ich habe ein Problem mit einer anscheinend korrupten Firebird-(1.5)-DB. Und da ich den (sträflichen) Fehler gemacht habe, gleichzeitig Daten einzugeben und an der Struktur rumzumachen, wäre es schon ziemlich gut, wenn ich die Original-DB wiederherstellen könnte (und nicht ein Backup, von dem ich nicht abschätzen kann, was denn eigentlich fehlt).

Also: Die DB macht kein Backup mehr. An immer verschiedenen Punkten (aber im Kontext der gleichen zwei Tabellen), bricht das Backup mit der Fehlermeldung

Code:

Arithmetic overflow or division by zero has occurred.
arithmetic exception, numeric overflow, or string truncation.

ab. Wenn ich es mehrmals nacheinander versuche, kann auch mal folgende Meldeung kommen:

Code:

Unsuccessful execution caused by a system error that precludes successful execution of subsequent statements.
internal error.
gds_$start_request failed.

.
Mir scheint, das Problem liegt a) nicht nur an der DB-Struktur, sondern auch an den Daten und b) möglicherweise an den Indizes, da der Abbruch immer während der Erstellung der Indizes erfolgt.

Der Abbruch erfolgt immer nach einem unterschiedlichen Index, aber immer im Zusammenhang mit einer von zwei Interselektionstabellen.

Wenn ich mir von IBExpert die Metadaten exportieren lasse und daraus anschließend eine neue, leere DB erzeuge, kann ich diese problemlos "backupen" und wieder "restoren" (wie sagt man sowas auf "neudeutsch"?). Daraus schließe ich, dass es irgendwie mit den eingegebenen Daten zu tun haben muss

Wenn ich mir von IBExpert die Metadaten inkl. Tabelleninhalt exportieren lasse, bricht der Versuch der Neuerstellung mit dem Verweis auf eine "Foreign Key violation" ab.

Wenn ich nun versuchshalber bei den betroffenen Tabellen Indizes und Schlüssel deaktiviere bzw. lösche (keine Angst, ich bin der einzige User der DB, es kann also niemand in der Zwischenzeit ungültige Daten eingeben), bricht das Backup an immer anderen Stellen ab.

Hat jemand eine Idee, woran genau ein solcher Fehler liegen kann bzw. wie ich da wieder raus komme?
Gibt es eine Möglichkeit, alle Indizes (einschließlich der in Schlüsseln verwendeten) neu aufzubauen?

Und falls alles nichts hilft: wie bekomme ich mit dem geringsten Frust die Daten in eine leere Kopie der DB
(Erschwerend kommt hinzu, dass es ein paar Tabellen gibt, die per Foreign Key auf sich selbst verweisen; dabei ist es möglich, dass ein Datensatz auf einen späteren verweist, was beim Übertragen natürlich eine Foreign Key Violation hervorrufen kann)

Bin über jeden Tipp sehr dankbar.
Urs


-----
WinXP
Firebird 1.5
IBExpert 2004.01.22

[Lemmy]

Hi,

wenn eine neue DB funktioniert, dann exportiere doch die Daten und spiele die in eine neue Datenbank ein.

WEnn das nicht geht:

Du kannst hergehen und die Indizes löschen:

drop index <IndexName>;

Wenn Du alle eigenen Relationen gelöscht hast, dann schau was:

Select * from rdb$relation_Constraints;

zurück liefert. Dort sind alle Constraints (Primärschlüssel, Fremdschlüssel) drin. Dann kannst Du die einzelnen Fremd- und Primärschlüssel löschen bzw. deren Index.

Lemmy

[CenBells]

Hi,

du kannst probieren das kleine tool gfix.exe (Im firebird\bin Verzeichniss auf die db anzuwenden)

Gruß
Ken

[urs.liska]

Hi,

danke für die Tipps.

gfix hat leider nichts gefunden.

Nachdem ich alle Fremd- und Hauptschlüssel sowie sämtliche Indizes gelöscht habe (ich freu mich schon darauf, sie alle wieder einzurichten), brach das Backup immer noch ab, allerdings an einer anderen Stelle.

Nun bin ich eher zufällig auf eine Inkonsistenz gestoßen (als ich eine zum Glück leere Tabelle nicht mehr anzeigen konnte):
Für eine Tabelle zeigte mir IBExpert keine Abhängigkeiten an, obwohl ein Trigger für die Tabelle definiert und auch aktiv war.
Ich habe die Tabelle neu erstellt und den Trigger neu eingerichtet - und siehe da, es geht.

Es gibt schon komische Sachen. Ich habe mit Sicherheit nichts selbst an den Systemtabellen manipuliert.

Hat vielleicht jemand eine Idee, wie so etwas zu Stande kommen kann (und wie man es evtl. vermeiden kann)

Gruß
Urs

[DelphiDeveloper]

vermutlich hat du bei der aenderung der metadaten ein feld kleiner gemacht als es ursrspünglich war.

ich würde folgendes versuchen

1. versuchen die aenderung erst mal wieder rückgängug machen
dann dafür sorgen, das vor der erneuten aenderung die Daten der neuen Feldgroeße vorher angepaßt werden (update befehle)
2. wenns nichs bringt versuchen die Daten mit IBExpert in insert script exportieren (notfalls ohne defekte spalte)
dann metadaten der tabelle speichern, tabelle dropen, und tabelle neu anlegen.
anschließen insert script laufen lassen.
evtl. mußt du halt dabei trigger deaktivieren und abhaengigkeiten kurzzeitig eliminieren

mfg
DD

[urs.liska]

Danke für den Tipp.

Wie ich aber geschrieben habe, war die Tabelle ja zum Glück noch leer, daher konnte ich sei einfach neu erstellen und das Problem ist hoffentlich erledigt.
Etwas beunruhigend finde ich aber doch, dass ich die korrupte Tabelle nur durch Zufall gefunden habe. Die Abbruchstelle des Backup hatte nichts mit dieser Tabelle zu tun...

Urs