Größenlimit bei GBAK?

[idefix]

Hallo zusammen,

ich hab hier ein echtes Problem.
Ich soll eine "Uralt-Datenbank" wieder schüssig machen und stosse dabei auf ein Problem. Zum Verständnis mal die Vorgeschichte:
Es handelt sich ursprünglich um eine Interbase-Datenbank auf einem Windows-Server. Folglich ist die Dateiendung .gdb. Diese wird nun unter Firebird 2.01 angesprochen. Nach meinen Infos wurde noch nie (bitte keine Kommentare dazu - ich selbst kann es auch nicht nachvollziehen) ein Backup/Restore durchgeführt. Und genau das habe ich jetzt vor.
Die Datenbank hat sich mittlerweile auf etwas über 10GB aufgebläht und mit gfix finden sich doch einige Fehler.
Wenn ich nun jedoch ein Backup durchführen will, nachdem ich gfix mit dem Schalter -mend ausgeführt habe, läuft dieses Backup zwar sauber an, bleibt dann aber irgendwann einfach ohne Fehlermeldung hängen. Ich hab das ganze Tags zuvor angestossen und über Nacht laufen lassen - am nächsten Tag war gbak noch genau an der gleichen Stelle, wie bereits Abends vorher.
Ich hab das jetzt schon mehrere male durchgespielt. Das Backup bleibt nicht etwa immer am selben Eintrag hängen sondern scheinbar beliebig. Die einzige Gemeinsamkeit ist die: Die Backupdatei hat dann etwa eine Größe von 3 GB.
Hat jemand eine Idee was da los sein kann? Gibt es bei GBAK eine Größenbeschränkung für das Backupfile? Wenn ja, kann man die irgendwie umgehen?

Hier mal die Befehle, die ich auf die DB anwende - wie gesagt: gbak macht irgenwann einfach nicht mehr weiter:

gfix -v -full Pfad\Datenbankgdb -user Username -pass Passwort
gfix -mend Pfad\Datenbankgdb -user Username -pass Passwort
gbak -b -v -ig localhost:Pfad\Datenbank.gdb Pfad\backup.gbk -user Username -pass Passwort

[Markus Kinzler]

Versuch mal die Datei zu splitten
gbak [options] <database> <target file 1> <size 1> <target file 2> <size 2> ... <target file n>

[idefix]

Genau das habe ich heute Nacht versucht - mit jeweils 2GB großen Teildateien. Aber das Backup bleibt wieder hängen.
Interessant ist, dass der Firebird-Server bis zum Anschlag ausgelastet ist - soll heissen, er nimmt sich die gesamten Ressourcen des Prozzesorkerns, auf dem ich ihn konfiguriert habe. Die Anzeige in der Systemleistung des Taskmanagers ist kontinuierlich am Anschlag. Ich muss den Prozess dann schon mit "taskkill" töten, denn auf "net stop" reagiert der Dienst dann nicht mehr.

[Thomas Steinmaurer]

Hallo,

der Server wird hier vermutlich mit dem Garbage Collection in der Quell-Datenbank beschäftigt sein. Versuch mal gbak zusätzlich mit dem -g Schalter zu starten. Hiermit wird die Garbage Collection in der Quell-Datenbank unterdrückt.


Thomas

[idefix]

Hört sich logisch an - werde es gleich mal so anstossen.
Bleibt die Frage wie ich die Garbage Collection dann noch hinbekomme. Ich gehe nämlich davon aus, dass sie überfällig ist. Hat da vielleicht jemand eine Idee?

[Thomas Steinmaurer]

Hallo,

es besteht immer die Möglichkeit, ein manuelles Sweep anzustoßen (z.B. mit gfix oder einem Tool deiner Wahl).

Wenn aber ein Restore des Backups die Originaldatenbank ersetzen soll, dann besteht nicht wirklich die Notwendigkeit ein Sweep in der Original-DB zu machen.


Thomas

[idefix]

Das hört sich doch mal gut an!
Ich werd jetzt erst mal das Backup ohne Garbage Collection abwarten und mich dann wieder melden, wie des geklappt hat.
Danke erst mal !

[idefix]

Volltreffer!
Mit dem -g hat es nun einwandfrei geklappt und die Datenbank ist nach dem Restore bis auf die Hälfte geschrumpft.

Mann, mann, mann! Wie man eine Datenbank so lange vor sich hin dümpeln lassen kann...

Danke nochmal!!