Firebird: Datenbank defekt - Wie reparieren?

[Nersgatt]

Hallo,

ich habe hier eine defekte Datenbank eines Kunden, von der ich mit GBAK kein Backup mehr machen kann.
Ich habe versucht, mit GFix es zu beheben:

Code:

C:\JT\Testdaten>gfix -mend -full -ignore datenbank.gdb
Summary of validation errors
        Number of index page errors     : 6

Danach mit Gbak ein Backup machen:

Code:

C:\JT\Testdaten>gbak -backup -v -ignore Datebank.gdb Datenbank.bak

Das resultiert leider immer wieder in

Code:

gbak: ERROR:message length error (encountered 2204, expected 2180)
gbak: ERROR: gds_$receive failed
gbak:Exiting before completion due to errors

Kann mir jemand sagen, wie ich weiter vorgehen kann, um diese Datenbank wieder gerade zu biegen?

Danke!
Jens

[mkinzler]

Wenn man noch auf die Datenbank zugreifen kann könnte man versuchen diese in ein SQL-Skript auzulagern.
Sonst bleiben nur Tools wie IBSurgeon o.ä.

[mjustin]

Zitat:

Zitat von Nersgatt

Hallo,

ich habe hier eine defekte Datenbank eines Kunden, von der ich mit GBAK kein Backup mehr machen kann.
Ich habe versucht, mit GFix es zu beheben:

Code:

C:\JT\Testdaten>gfix -mend -full -ignore datenbank.gdb
Summary of validation errors
        Number of index page errors     : 6

Danach mit Gbak ein Backup machen:

Code:

C:\JT\Testdaten>gbak -backup -v -ignore Datebank.gdb Datenbank.bak

Das resultiert leider immer wieder in

Code:

gbak: ERROR:message length error (encountered 2204, expected 2180)
gbak: ERROR: gds_$receive failed
gbak:Exiting before completion due to errors

Kann mir jemand sagen, wie ich weiter vorgehen kann, um diese Datenbank wieder gerade zu biegen?

Danke!
Jens

Man könnte die Datenbank neu (leer) anlegen (wenn man die Metadaten noch hat oder wiederherstellen kann).
Anschliessend werden dann alle Tabellen der defekten DB als SQL INSERT Skripte exportiert, und diese dann auf der neuen DB ausgeführt. Dazu kann man z.B. IBExpert verwenden.

Alternativ gibt es Tools und Services wie IBSuergeon, aber mit denen habe ich keine Erfahrung:


http://www.ibsurgeon.com/

[Nersgatt]

Zitat:

Zitat von mkinzler

Wenn man noch auf die Datenbank zugreifen kann könnte man versuchen diese in ein SQL-Skript auzulagern.

Das wäre eine Möglichkeit, auf die Datenbank kann ich noch zugreifen. Das Problem dabei ist, dass ich ja die Reihenfolge der Tabelle beachten muss, damit die Referetielle Integrität nicht verletzt wird.
Gibt es einen Mechanismus, um das vielleicht temporär ausser Kraft zu setzen, damit ich die Daten einfach ohne Rücksicht auf Verluste in die neue Datenbank pumpen kann?

Gruß,
Jens

[mjustin]

Zitat:

Zitat von Nersgatt

Zitat:

Zitat von mkinzler

Wenn man noch auf die Datenbank zugreifen kann könnte man versuchen diese in ein SQL-Skript auzulagern.

Das wäre eine Möglichkeit, auf die Datenbank kann ich noch zugreifen. Das Problem dabei ist, dass ich ja die Reihenfolge der Tabelle beachten muss, damit die Referetielle Integrität nicht verletzt wird.
Gibt es einen Mechanismus, um das vielleicht temporär ausser Kraft zu setzen, damit ich die Daten einfach ohne Rücksicht auf Verluste in die neue Datenbank pumpen kann?

Gruß,
Jens

* Foreign Keys (Fremdschlüssel) kann man nicht deaktivieren, nur löschen
* Trigger, die eventuell auch FK-Prüfungen machen, kann man deaktivieren
* Indexdateien kann man, damit der Daten-Import schneller geht, auch deaktivieren

Wenn man das Datenmodell gut kennt, sollte man die richtige Importreihenfolge aber leicht herausfinden können.

IBExpert würde ich mir auf jeden Fall mal anschauen, da sind so viele Werkzeuge enthalten, zum Beispiel falls auch BLOBs oder Unicodeinhalte extrahiert werden müssen, und einige Serviceprogramme die optional installierbar sind...

[mkinzler]

Wenn man den Export aus IBExpert heraus macht, wird die Reihenfolge der Tabellen so gewählt, das Abhängigkeiten rekonstruiert werden.

[Nersgatt]

Zitat:

Zitat von mkinzler

Wenn man den Export aus IBExpert heraus macht, wird die Reihenfolge der Tabellen so gewählt, das Abhängigkeiten rekonstruiert werden.

Ich muss blind sein, ich finde die Funktion einfach nicht. Wenn ich in einer Tabelle bin, kann ich "Tabelle -> Exportiere Daten in Skript" wählen. Dabei wird ja aber nur eine Tabelle exportiert. Wo kann ich denn alle Tabellen exportieren?

[Edit] Hat sich erledigt: Nützliches -> Extrahiere Metadaten

Danke,
Jens

[Nersgatt]

Nur um es zu Abschluss zu bringen. Mit dem Export in ein Script (mit IBExpert) und damit eine neue DB erstellen -> Datenbank funktioniert wieder.

Zitat:

Zitat von mkinzler

Wenn man den Export aus IBExpert heraus macht, wird die Reihenfolge der Tabellen so gewählt, das Abhängigkeiten rekonstruiert werden.

IBExpert exportiert erst die Tabellenbeschreibungen, dann die Daten als INSERT-Statements und erst am Ende des Scriptes werden die Schlüssel, Trigger und Prozeduren erstellen.
So umgeht man das Problem der Reihenfolge.

Gruß,
Jens

[DeddyH]

Jepp, Holger ist ja nicht blöd :zwinker:

[Roland1967]

Würde auch IBExpert empfehlen dafür. Ich kann mich an ein Video von einem Seminar von Holger Klemt erinnern (müsste 2007 gewesen sein), wo Datenbankreparaturen vorgeführt wurden. Die Videos waren unter z.B. Google-Video veröffentlich. http://video.google.de/videoplay?doc...vBQ&q=ibexpert

Von einem Seminar im Herst 2008 in Leipzig gibt es auf der IBExpert-Seite ein von der Qualität besseres Video, da ich aber noch nicht alles geschafft habe, weiß ich nicht ob dort zu Datenbankrepearaturen was gesagt wurde.

[mquadrat]

Ich muss mal diesen alten Beitrag wiederbeleben.

In letzter Zeit sterben bei Kunden immer häufiger Firebird Datenbanken (2.1) mit eben diesem Fehler. Das komplette extrahieren von Daten und neu erstellen von Datenbanken ist bei DBs mit ca. 1GB nur begrenzt zu empfehlen.

Das Löschen und Einfügen der defekten Tabellen macht auch nur begrenzt Spaß, da oft die Haupttabelle der Anwendung betroffen zu sein scheint.

Hat jemand eine Idee, warum das in letzter Zeit häufiger passiert bzw. was überhaupt die Ursache für den Message Length Fehler ist?