![]() |
Datenbank: Firebird • Version: 2.0 • Zugriff über: Gbak/Gfix
Firebird: Datenbank defekt - Wie reparieren?
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:
Danach mit Gbak ein Backup machen:
C:\JT\Testdaten>gfix -mend -full -ignore datenbank.gdb
Summary of validation errors Number of index page errors : 6
Code:
Das resultiert leider immer wieder in
C:\JT\Testdaten>gbak -backup -v -ignore Datebank.gdb Datenbank.bak
Code:
Kann mir jemand sagen, wie ich weiter vorgehen kann, um diese Datenbank wieder gerade zu biegen?
gbak: ERROR:message length error (encountered 2204, expected 2180)
gbak: ERROR: gds_$receive failed gbak:Exiting before completion due to errors Danke! Jens |
Re: Firebird: Datenbank defekt - Wie reparieren?
Wenn man noch auf die Datenbank zugreifen kann könnte man versuchen diese in ein SQL-Skript auzulagern.
Sonst bleiben nur Tools wie ![]() |
Re: Firebird: Datenbank defekt - Wie reparieren?
Zitat:
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: ![]() |
Re: Firebird: Datenbank defekt - Wie reparieren?
Zitat:
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 |
Re: Firebird: Datenbank defekt - Wie reparieren?
Zitat:
* 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... |
Re: Firebird: Datenbank defekt - Wie reparieren?
Wenn man den Export aus IBExpert heraus macht, wird die Reihenfolge der Tabellen so gewählt, das Abhängigkeiten rekonstruiert werden.
|
Re: Firebird: Datenbank defekt - Wie reparieren?
Zitat:
[Edit] Hat sich erledigt: Nützliches -> Extrahiere Metadaten Danke, Jens |
Re: Firebird: Datenbank defekt - Wie reparieren?
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:
So umgeht man das Problem der Reihenfolge. Gruß, Jens |
Re: Firebird: Datenbank defekt - Wie reparieren?
Jepp, Holger ist ja nicht blöd :zwinker:
|
Re: Firebird: Datenbank defekt - Wie reparieren?
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.
![]() 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. |
AW: Firebird: Datenbank defekt - Wie reparieren?
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? |
Alle Zeitangaben in WEZ +1. Es ist jetzt 16:44 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz