Announcement

**Andreas Wohlmuth** · 08.03.2002, 10:34

Hallo Frank,

das Problem habe ich auch, bzw man muß scheinbar das Backupfile manuell auf den entsprechenden Rechner kopieren wo man restoren will und dann Lokal Restoren.
So ein RemoteRestore wäre wirklich gut,hab ich aber noch nicht hinbekommen, vielleicht können uns ja erfahrenere Restorler helfe

**Andreas Tengicki** · 08.03.2002, 12:32

IB5 sichert das gbk File auf dem Client von wo das gbak aufgerufen wird.

IB6 sichert lokal am Server, da er es selbst tut.

Das zweite ist meist der bessere Weg, da der Server dann auch im Rahmen seiner Band-Sicherung das gbk File sichern kann.

Es hilft derzeit nur das nachträgliche Kopieren via gemapptes Laufwerk oder ftp oder .

**Frank Link** · 08.03.2002, 13:40

Hallo, 
ich habe sowohl den Remotezugriff als auch den lokalen Zugriff versucht. In beiden Fällen wird das Restore nur dann sauber ausgeführt, wenn es sich um die gleichen DB handelt. 
D.h. die Sicherung des Server A kann ich bei Server A auch restoren, aber bei Server B nicht. Dies weder lokal noch remote. 
Ich bin im Augenblick ratlos. Da ich die Vorgehensweise auch zur Replikation und zur Fehlersuche benutzen wollte habe ich jetzt ein kleines Problem. Hinweis: Mein LINUX-Rechner ist ein ROOT-Server bei Puretec. Damit habe ich natürlich nur die Möglichkeit Remote zu arbeiten. Gibt es eigentlich mittlerweile eine vernüftige Möglichkeit DBs vollständig zu replizieren?
Gruss 
Fran

**Andreas Tengicki** · 08.03.2002, 15:05

was bekommst Du denn für eine Fehlermeldung bei folgender Vorgehensweise a) kopieren der unter Win erzeugten gbk auf die Unix Kiste b) restore dieser kopierten Datei unter linux

Wie lautet den Kommando für den Restore unter linux. Ggf telnet und gbak verwenden

was heißt vernünftig und was heißt vollständig im Sinne einer Replikation?

Es gibt das Tool von Synertics damit kann man einfach was zusammen klickern und das tut dann oder auch nicht, je nachdem. Und es gibt ein Tool von uns, da kann man sehr spezielle Einstellungen treffen, müßten aber das Zusammenspiel mit Linux noch testen. Die ganze Konifguration ist da nicht trivial, aber Replikationen sind wenn notwendig und funktionieren sollen, eigentlich nie trivial. Mehr zum Thema auf unsere Homepage

**Frank Link** · 08.03.2002, 17:15

Hallo Andreas, 
mit gbak habe ich es noch gar nicht versucht. Ich bin immer über den Umweg IBConsole bzw. IBExpert gegangen.
Den Weg werden ich nachher probieren. 
Was die Replikation angeht, habe ich eine DB im Netzstehen, die von Annwendern zu Recherche verwendet werden kann (s. www.vmodell-wissen.de). Zur Zeit ist das übrigends noch MYSQL. Da ich aber ständig neue Dokumente in das System einpflege, bzw. das System auch pflege, benötige ich eine einfache Möglichkeit, bestimmte Datensätze auf die LINUX-DB zu übertragen. 
Hier ist das Backup mit Sicherheit eine Sache, es ist aber eigentlich nur eine Notlösung und nicht, das was ich wirklich will. 
Was ich benötige, ist die Möglichkeit zu einem beliebigen Zeitpunkt das Delta (Differenz zwischen LINUX und WINDOWS DB) auf die LINUX-DB zu schieben. D.h. es müssen alle Tabellen, die einer Änderung unterliegen vollautomatisch abgeglichen werden. Meine DB ist im Auslieferungszustand ca. 256MB gross. Sie wächst dann mit jedem Dokument, welches dort archiviert und indiziert wird drastisch an. Das bedeutet, im Backupfall stundenlanges uploaden der gbk. 
Ideal wäre, wenn ich nur das Delta publizieren muss. Könnte ich jetzt selber programmieren, bringt mich aber nicht wirklich weiter, da ich das natürlich nur über SQL-Abfragen händeln könnte.
Wenn Du eine alterative hast,...
Gruss 
Fran

**Andreas Tengicki** · 08.03.2002, 17:46

> Ideal wäre, wenn ich nur das Delta publizieren muss. Könnte ich jetzt selber programmieren, bringt mich aber nicht wirklich weiter, da ich das natürlich nur über SQL-Abfragen händeln könnte.

Wie willst Du es sonst als über SQL machen? Die zwei angesprochenen Replikatoren sorgen auch nur dafür das/die Delta zu kennen und übertragen dann mittels SQL von A nach B und/oder zurück. Was sonst

**Frank Link** · 08.03.2002, 21:42

Hallo Andreas, 
natürlich mit SQL, die Kunst ist es, das Delta zu erkennen. Die Datenankserver mit denen ich mich bisher auseinandersetzen musste, hatten mehr oder weniger geniale Ansätze wärend einer Transaktion die tatsächlichen Änderungen zu protokollieren und diese an die Replikanten zu propagieren. Einen solchen Ansatz habe ich bisher für Interbase noch nicht gefunden. Wie sieht denn euer Ansatz aus, um das Delta möglichst effizient zu erkennen. In welchen Zyklen könnt Ihr Veränderungen propagieren?
Gruss 
Fran

**Thomas Steinmaurer** · 09.03.2002, 13:24

Hallo Frank, 
ich denke gegen etwas Werbung ist nichts einzuwenden. Wenn Du einen verlässlichen Mechanismus zum Protokollieren von geänderten Daten benötigst, dann sieh Dir IB LogManager 2.0 einmal an. http://www.iblogmanager.com 
Beste Grüße 
Thomas Steinmaurer 
http://www.iblogmanager.co

**Andreas Tengicki** · 09.03.2002, 17:30

Der Thomas soll mich korrigieren wenn ich mich irre. Da aber InterBase kein Transaktionslogfile hat und auf Grund der Multi-Generationsarchitektur auch keines braucht, ist der einzige Weg für ein Protokoll Trigger.

Wenn jetzt das aufstöhnen wegen der Performance kommt, bitte gleich wieder beruhigen. In InterBase sind Trigger nachgewisenerweise schnell

**Thomas Steinmaurer** · 10.03.2002, 15:35

Hallo Andreas, 
richtig, Interbase/Firebird benötigt kein Transaktionslog wegen der von Dir angesprochenen MGA (Multi-Generationsarchitektur). D.h. ein zentraler, in der Datenbank integrierter Logging-Mechanismus muss durch Trigger auf Tabellen, die überwacht werden sollen, realisiert werden. Das funktioniert meinen Erfahrungen nach, sehr zuverlässig! 
Thomas Steinmaurer 
http://www.iblogmanager.co

Announcement

BACKUP / RESTORE FÜR INTERBASE

BACKUP / RESTORE FÜR INTERBASE

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment