Es gibt einige Tricks, mit denen Sie die Sicherung beschleunigen können.Die erste besteht darin, zu verhindern, dass die Speicherbereinigung ausgeführt wird, während die Sicherung ausgeführt wird.Durch die Speicherbereinigung werden alte Datensatzversionen gelöscht, die nicht mehr benötigt werden. Dies wird normalerweise durch einen manuellen oder automatischen Sweep oder durch einen vollständigen Tabellenscan aller betroffenen Tabellen abgedeckt.Wenn gbak auf alle Zeilen in den zu sichernden Tabellen zugreift, wird auch die Speicherbereinigung ausgelöst und kann bei einer großen Anzahl von Aktualisierungen die Sicherung verlangsamen.Verwenden Sie die Option -g[arbage_collect], um die Speicherbereinigung während der Sicherung zu verhindern.

Die zweite Option besteht darin, die Datenbank mit der Option -se[rvice] zu sichern.Obwohl dies zur Durchführung von Remote-Sicherungen verwendet wird, kann es auch lokal verwendet werden.Mit dieser Option können Sie Ihre Backups beschleunigen.Es wird einfach vermieden, dass die Daten über das TCP-Netzwerk kopiert werden, was die Aktionen der Sicherung verlangsamen kann.

Im obigen Beispiel wird die Mitarbeiterdatenbank auf dem Tux-Server mithilfe des Service-Managers "remote" gesichert.Auf dem Tux-Server wird der Befehl natürlich ausgeführt, sodass er überhaupt nicht remote ausgeführt wird.

Sie können natürlich die Optionen -g[arbage_collect] und -se[rvice] kombinieren.

Sollte eine Datenbank wiederhergestellt oder ersetzt werden?Das Wiederherstellen einer Datenbank ist der Vorgang, bei dem Sie die vorhandene Datei übernehmen und löschen, bevor Sie sie auf der Festplatte durch eine Sicherungskopie ersetzen.gbak tut dies, wenn Sie den Schalter -r[ecreate_database] o[verwrite] oder den Schalter -rep[lace_database] angeben.Was ist der Unterschied?

Wenn eine Datenbank auf der Festplatte vorhanden ist und Sie gbak auffordern, diese mit einem der beiden oben genannten Schalter wiederherzustellen, können Sie die Datenbank beschädigen, insbesondere wenn die Datenbank verwendet wird und nicht mit gfix heruntergefahren wurde.Wenn Sie die Wiederherstellung einer Datenbank nur teilweise abgeschlossen haben und einige Benutzer entscheiden, ob sie sich anmelden können, ist die Datenbank möglicherweise beschädigt.

Wenn der Wiederherstellungsprozess feststellt, dass die Speicherauszugsdatei beschädigt ist, schlägt die Wiederherstellung fehl und Ihre zuvor funktionierende Datenbank ist für immer verschwunden.

Es ist ersichtlich, dass das Wiederherstellen einer Datenbank eine schwierige Erfahrung sein kann.

Erstellen Sie aus Sicherheitsgründen die Datenbank immer unter einem neuen Namen — einem Klon — und aktualisieren Sie die Datei aliases.conf, und referenzieren Sie die Datenbank hier.Auf diese Weise verweisen Sie Ihre Benutzer unabhängig vom tatsächlichen Dateinamen auf dem Server immer über den Alias ​​auf die Datenbank.

Während eines Wiederherstellungsvorgangs, höchstwahrscheinlich beim Wiederherstellen einer Sicherung, die mit einer älteren gbak-Version erstellt wurde, können in der Ausgabe von gbak Fehlermeldungen angezeigt werden, die auf fehlerhafte Unicode-Zeichenfolgen hinweisen.Der Grund, warum diese auftreten können, ist wie von Helen Borrie erklärt:

Die Wiederherstellung einer Datenbank aus einer Sicherung kann schneller ausgeführt werden, wenn die Option -se[rvice] verwendet wird.Obwohl dies für Remote-Wiederherstellungen verwendet wird, kann es auch lokal verwendet werden.Es wird einfach vermieden, dass die Daten über das TCP-Netzwerk kopiert werden, was die Aktionen der Wiederherstellung verlangsamen kann.

Im obigen Beispiel wird die Mitarbeiterdatenbank auf dem Tux-Server mithilfe des Service-Managers "remote" gesichert.Auf dem Tux-Server wird der Befehl natürlich ausgeführt, sodass er überhaupt nicht remote ausgeführt wird.

Sie können natürlich die Optionen -g[arbage_collect] und -se[rvice] kombinieren.

Wenn Sie eine geöffnete und laufende Datenbank ersetzen, besteht eine gute Chance, dass Sie sie beschädigen.Um optimale Ergebnisse und eine minimale Wahrscheinlichkeit einer Beschädigung einer Datenbank zu erzielen, sollten Sie diese schließen, bevor Sie sie ersetzen.Verwenden Sie zum Schließen einer Datenbank gfix wie folgt:

Das obige Beispiel verhindert, dass eine neue Transaktion gestartet wird, wodurch verhindert wird, dass neue Abfragen ausgeführt werden oder neue Sitzungen mit der Datenbank verbunden werden.Es dauert bis zu 60 Sekunden, bis sich alle abgemeldet haben und alle aktuellen Transaktionen abgeschlossen sind, bevor die Datenbank heruntergefahren wird.Wenn Transaktionen mit langer Laufzeit bis zum Ende von 60 Sekunden noch nicht abgeschlossen sind, tritt beim Herunterfahren eine Zeitüberschreitung auf und die Datenbank bleibt geöffnet.

An Datenbanken können bei normaler Verwendung Schattendateien angehängt werden.gbak sichert diese glücklicherweise mit und stellt sie ebenfalls wieder her. Bei normaler Verwendung werden Schattendateien neu erstellt.Wenn Sie nur die Datenbank wiederherstellen und die Schatten ignorieren möchten, kann gbak dies für Sie tun, wie das folgende Beispiel zeigt.

Das Dienstprogramm gbak von Firebird kann Backups einer entfernten Datenbank erstellen.Dazu müssen Sie eine Verbindung zum Service Manager herstellen, der auf dem Remote-Server ausgeführt wird. Dies wird normalerweise als service_mgr bezeichnet.Das folgende Beispiel zeigt, wie die Firebird-Mitarbeiterdatenbank auf dem Server tuxrep vom Server tux gesichert wird.Die Sicherung wird auf den Remote-Server geschrieben, dh die Sicherungsdatei wird auf dem Server tuxrep und nicht auf dem Server tux erstellt.Das verwendete Netzwerkprotokoll ist TCP.

Die Sicherungsdatei hat denselben Eigentümer und dieselbe Gruppe wie der Firebird-Datenbankserver — zumindest auf Unix-Systemen.

Es ist auch möglich, eine entfernte Datenbank auf diese Weise wiederherzustellen, und gbak erlaubt dies.

Wie immer wird empfohlen, sich vor dem Ersetzen einer Datenbank zu hüten, falls während der Wiederherstellung Probleme auftreten.Im obigen Beispiel wird die vorhandene Datenbank im schreibgeschützten Modus neu erstellt. Dies muss jedoch nicht immer der Fall sein.

Eine Remote-Sicherung kann auch auf dem Datenbankserver selbst ausgeführt werden!Unter Windows macht dies keinen Unterschied, aber auf Unix-Systemen reduziert diese lokal-entfernte Methode zum Sichern und Wiederherstellen den Netzwerkverkehr.Der 'Remote'-Server ist in diesem Fall nicht wirklich entfernt. Es ist nur die Methode zum Ausführen der Sicherung — herstellen einer Verbindung zum Service Manager --, die die Entfernung impliziert.

Entsprechende Wiederherstellungen können auch 'remote' ausgeführt werden:

Das Format des Parameters, der für den service-Schalter verwendet wird, unterscheidet sich je nach Art des verwendeten Netzwerkprotokolls:

Wie oben gezeigt, können Sie die speziellen Dateinamen stdin und stdout verwenden, um eine Datenbank in einer separaten Datenbank auf demselben Server zu sichern und wiederherzustellen.Sie können jedoch auch dieselben Tools über eine SSH-Verbindung zu einem Remoteserver verwenden und die Sicherung einer Datenbank direkt an eine Wiederherstellung einer separaten Datenbank übergeben.

Im ersten Beispiel wird eine lokale Datenbank auf einen Remote-Server kopiert, auf dem Firebird ausgeführt wird und die Umgebung des Firebird-Benutzers so eingerichtet ist, dass sich das gbak-Tool bei der Anmeldung standardmäßig auf $PATH befindet.

Wenn das oben Gesagte ausgeführt wird, werden Sie aufgefordert, ein Kennwort für den Remote-Firebird-Benutzer auf dem Server tuxrep einzugeben, vorausgesetzt, Sie haben noch kein ordnungsgemäßes SSH-Schlüsselpaar eingerichtet und sind aktiv.Der Befehl ersetzt die lokale Datenbank gemäß dem Aliasnamen emptest. Sie können jedoch bei Bedarf vollständige Pfadnamen für die Datenbanken angeben.Das Folgende zeigt ein Beispiel für die Ausführung des oben genannten Vorgangs.

Wie Sie sehen, steht der Ausgabe nicht viel im Wege, aber Sie können eine Remoteverbindung herstellen und Folgendes überprüfen:

Das nächste Beispiel zeigt eine Remote-Datenbank, die auf ähnliche Weise in einer lokalen Datenbank gesichert wird.

Sie können sehen, dass eine neue Datenbank tuxrep_emptest.fdb erstellt wurde.Funktioniert sie?Die Überprüfung mit isql zeigt, dass dies der Fall ist.

Das letzte Beispiel zeigt, wie eine entfernte Datenbank auf einem Server in einer entfernten Datenbank auf einem anderen Server gesichert wird.

gbak und nbackup sind die besten Tools zum Sichern und / oder Wiederherstellen von Firebird-Datenbanken.Sie wurden ausgiebig getestet und kennen die Interna der Datenbank und deren Funktionsweise. Daher ist die Wahrscheinlichkeit, dass diese Tools Ihre wertvollen Daten beschädigen, sehr gering.Einige Datenbankadministratoren verwenden jedoch weiterhin gerne externe Tools (die nicht mit Firebird geliefert werden), um aus irgendeinem Grund Backups zu erstellen.

Da externe Tools anhand des Aliasnamens nicht wissen können, wo sich eine Datenbank befindet, müssen der Skriptschreiber und / oder der Datenbankadministrator explizit den korrekten Speicherort der Datenbankdatei(en) ermitteln und diese an die externe Datei weitergeben Werkzeug.Um dies für Skriptautoren zu vereinfachen, verwendet meine eigene Installation einen Standard in meiner Datei "aliases.conf" wie folgt:

Die letzte Regel gilt nur für meine Installation und bedeutet, dass das folgende einfache Sicherungsskript funktioniert.Wenn mehrere Dateidatenbanken verwendet würden, wäre mehr Code erforderlich, um eine Sicherung mit externen Tools durchzuführen.

Im Folgenden wird die Verwendung des Dienstprogramms "gzip" auf einem Linux-Server zum Erstellen und Komprimieren einer Sicherung einer laufenden Datenbank gezeigt.Folgendes wird als Root-Benutzer ausgeführt, da gfix ausgeführt werden muss, um die Datenbank herunterzufahren.

Der Wiederherstellungsprozess für diese Datenbank wäre umgekehrt.Wieder läuft das Folgende als root.

In diesem Beispiel wird eine Sicherung erstellt und die ursprüngliche Datenbank mit der neuen Sicherung sofort überschrieben.Dies ist normalerweise keine gute Idee, da die erste Aktion einer Wiederherstellung darin besteht, die Datenbank zu löschen.

Es ist möglich, gbak zu verwenden, um eine leere Datenbank neu zu erstellen, die nur die verschiedenen Domains, Tabellen, Indizes usw. der ursprünglichen Datenbank enthält, jedoch keine der Daten.Dies kann hilfreich sein, wenn Sie Ihre Anwendung in einer Testumgebung geprüft haben und das System beispielsweise in eine Produktionsumgebung migrieren möchten, aber ohne Ihre Testdaten neu beginnen möchten.

Wenn die obige Dump-Datei auf dem Produktionsserver wiederhergestellt wird, sind nur die Metadaten vorhanden.

Es gibt eine andere Möglichkeit, eine Datenbank ohne Daten und nur mit den Metadaten zu erstellen.Stellen Sie einfach aus einem vorhandenen Speicherauszug wieder her, der die Daten enthält, und geben Sie den Schalter -m[eta_data] in die Wiederherstellungsbefehlszeile ein.Die Datenbank wird wiederhergestellt, aber keine der Originaldaten sind vorhanden.

Der Schalter -m[eta_data] kann entweder für eine Sicherung oder eine Wiederherstellung verwendet werden, um die Erstellung einer Klondatenbank (oder das Überschreiben einer vorhandenen) ohne tatsächliche Daten zu erleichtern.

Die in einem eigenen Handbuch dokumentierte Filteranwendung gsplit funktioniert nicht mehr.Dieser Filter wurde mit alten Versionen von InterBase und Firebird geliefert, damit große Datenbanksicherungen auf mehrere Dateien aufgeteilt werden können, damit die Dateisystemgrenzen eingehalten werden können.Solche Beschränkungen können die Größe einer CD sein, die Beschränkung auf 2 GB für einzelne Dateigrößen auf einer DVD, wobei einige Unix-Dateisysteme eine Beschränkung auf 2 GB usw. haben.

Mit gbak können die Speicherauszugsdateien in verschiedene Größen (mit mindestens 2048 Byte) aufgeteilt werden, und es werden nur die benötigten Dateien erstellt.

Die Größen nach jedem Dateinamen geben an, wie groß diese bestimmte Datei sein darf.Die Standardgröße ist Byte, aber Sie können ein Suffix von k, m oder g angeben, um Einheiten von Kilo, Mega oder Gigabyte zu verwenden.

Wenn der Speicherauszug abgeschlossen ist, bevor in einige Dateien geschrieben wird, werden diese Dateien nicht erstellt.Eine Dump-Datei wird immer nur erstellt, wenn dies erforderlich ist.

Die Größe der endgültigen Speicherauszugsdatei wird stillschweigend ignoriert, wenn die Datenbank zu groß geworden ist, um eine abgeschnittene Sicherung abzuschließen.Wenn im obigen Beispiel die Sicherung insgesamt 1500MB benötigt, wird die letzte Datei auf eine endgültige Größe von 900m anstatt der angegebenen 600m geschrieben.

Um eine solche Sicherung mit mehreren Dateien wiederherzustellen, müssen Sie alle Dateinamen im Speicherauszug und in der richtigen Reihenfolge angeben.Das folgende Beispiel zeigt, wie die oben genannte Mitarbeiterdatenbank aus den beiden oben gespeicherten Dateien wiederhergestellt wird:

Normalerweise ist das verwendete ODS dasjenige, welches von der wiederherstellenden Firebird-Version verwendet wird.Die obigen Beispiele ändern also tatsächlich den ODS, wenn die Datenbank wiederhergestellt wird.Die Sicherung sollte mit dem Dienstprogramm gbak durchgeführt werden, das von der alten ODS-Version von InterBase oder Firebird bereitgestellt wird.Die Wiederherstellung sollte mit gbak aus der neueren Version von Firebird durchgeführt werden.

Danach wurde die alte 2.0 Firebird-Datenbank als Firebird 2.1-Datenbank mit dem entsprechenden Upgrade auf das ODS von 11.0 auf 11.1 neu erstellt — und die alte Datenbank gelöscht.

Das Skript setenv_firebird wird nicht mit Firebird geliefert und setzt einfach PATH usw., um die richtige Version von Firebird gemäß dem angegebenen Parameter zu verwenden.

Der Standard-Datenbank-Cache wird beim Erstellen der Datenbank oder anschließend mit gfix erstellt.gbak kann eine Datenbank wiederherstellen und auch die Standard-Cache-Größe zurücksetzen.Der Prozess ist wie folgt:

Die Standard-Cache-Größe wird verwendet, wenn die Anzahl der Puffer Null ist, wie im ersten Beispiel oben.Mit gbak kann dies bei Bedarf geändert werden.gbak kann die Cache-Größe jedoch nicht auf Null zurücksetzen.Sie müssen dazu gfix verwenden.

Ähnlich wie im obigen Beispiel zum Ändern der Standardgröße des Datenbankcaches kann die Größe der Datenbankseite auch mit gbak geändert werden.

Manchmal möchten Sie nicht, dass Ihre Berichtersteller intensive Abfragen für Ihre Produktionsdatenbank ausführen.Zu diesem Zweck können Sie ganz einfach täglich einen Klon Ihrer Produktionsdatenbank erstellen und schreibschützen.Auf diese Weise kann das Berichtsteam so viele intensive Berichte erstellen, wie es möchte, ohne dass dies negative Auswirkungen auf die Produktionsdatenbank hat, und es wird verhindert, dass versehentlich Änderungen vorgenommen werden.

Das folgende Beispiel zeigt die Produktionsmitarbeiterdatenbank, die auf dem Linux-Server tux ausgeführt wird und auf den Linux-Server tuxrep des Berichtsteams geklont wird.Zuerst auf dem Produktionsserver:

Dann auf dem tuxrep-Server des Berichtsteams:

Sie können gbak verwenden, um einen Klon einer Datenbank auf demselben Server zu erstellen, ohne eine potenziell große Dump-Datei erstellen zu müssen.Zu diesem Zweck leiten Sie die Ausgabe einer gbak-Sicherung wie folgt direkt an die Eingabe einer gbak-Wiederherstellung weiter.

Sie werden feststellen, dass der Name der Ausgabedatei für die Sicherung stdout und der Name der Eingabedatei für die Wiederherstellung stdin lautet.Durch diese Möglichkeit, die Standardausgabe eines Prozesses an die Standardeingabe eines anderen Prozesses weiterzuleiten, können Sie vermeiden, dass eine Zwischen-Dump-Datei erstellt wird.Die obigen Befehle setzen voraus, dass geeignete Aliasnamen sowohl für emptest als auch für emptest_2 eingerichtet sind.Wenn nicht, müssen Sie den vollständigen Pfad zu den beiden Datenbanken und nicht den Alias ​​angeben.

Die Option -replace beim Wiederherstellungsprozess überschreibt den angegebenen Datenbanknamen — als Alias ​​oder als vollständigen Pfad --, falls vorhanden, und erstellt ihn neu, wenn dies nicht der Fall ist.Alternativ können Sie auch die Option recreate overwrite verwenden.Beide haben das gleiche Ergebnis.

Wenn Sie keine vorhandenen Datenbanken überschreiben möchten, verwenden Sie -create. Dadurch wird eine Datenbank nur erstellt, wenn sie noch nicht vorhanden ist, und wenn dies der Fall ist, wird sie mit einem Fehler beendet.In POSIX-kompatiblen Systemen ist der Fehlercode in $? In diesem Fall 1.

Weitere Beispiele für das Sichern und Wiederherstellen von Remote-Datenbanken über ssh unter Verwendung der Dateinamen stdin und stdout finden Sie unten.

Wenn Sie keinen Modusschalter wie -b[ackup] oder -c[reate] usw. angeben, führt gbak eine Sicherung durch, als ob der Schalter -b[ackup] angegeben worden wäre — vorausgesetzt, die anderen angegebenen Schalter sind für eine Sicherung korrekt.

Nur der SYSDBA oder der Eigentümer einer Datenbank kann eine Sicherung der Datenbank erstellen. Jeder authentifizierte Benutzer kann jedoch eine Datenbanksicherung mit dem Schalter -c[reate] wiederherstellen.Dies bedeutet, dass Sie sicherstellen müssen, dass Ihre Sicherungsdateien nicht in die falschen Hände geraten, da nichts dann Unbefugte daran hindert, Ihre Daten zu sehen, indem Sie einfach Ihre Sicherungen auf Ihrem Server wiederherstellen.

Die Datenbankwiederherstellung schlägt natürlich fehl, wenn der Benutzer, der sie ausführt, nicht der Datenbankeigentümer ist und bereits eine Datenbank mit demselben Dateinamen vorhanden ist.

Der Schalter -y suppress_output unterdrückt jegliche Ausgaben.Ähnlich wie beim Ausführen mit -v[erify] nicht angegeben.Es scheint jedoch nur zu bewirken, dass die Ausgabe (gemäß der Schaltereinstellung -v[erify]) in eine Datei mit dem Namen suppress_output geschrieben wird. Dies funktioniert jedoch nur einmal, da der nächste Durchlauf von gbak mit -y suppress_output fehlschlägt, da die Datei suppr_output bereits vorhanden ist.

Es ist möglich, dass dieses Problem in Version 2 für Firebird eingeführt wurde, da sowohl die 2.0- als auch die 2.1-Version tatsächlich den Schalter -y suppress anstelle von -y suppress_output verwenden.Die Verwendung dieser (kürzeren) Option funktioniert wie beabsichtigt und die Ausgabe wird tatsächlich unterdrückt.

Wenn Sie mit dem Schalter -y <Protokolldatei> einen Protokolldateinamen angeben und die Datei bereits vorhanden ist, kann gbak sie nicht überschreiben, obwohl der Firebird-Benutzer die Datei besitzt und über Schreibberechtigungen verfügt.Sie müssen immer den Namen einer Protokolldatei angeben, die nicht vorhanden ist.Auf Linux-Systemen kann Folgendes hilfreich sein:

Dies ist insofern sehr nützlich, als es Sie daran hindert, frühere Sicherungen zu überschreiben, die möglicherweise erforderlich sind.Der Nachteil ist, dass Sie jetzt ein Reinigungssystem einführen müssen, um alte, unerwünschte Sicherungen zu beseitigen und zu verhindern, dass sich Ihr Sicherungsbereich füllt.

gbak erkennt die Literalzeichenfolgen 'stdin' und 'stdout' als Quell- oder Zieldateinamen.In POSIX-Systemen ist es bei Verwendung der Standardeingabe- und / oder Standardausgangskanäle nicht zulässig, Suchoperationen auf diesen Kanälen auszuführen.Wenn Sie 'stdin' oder 'stdout' als Dateinamen mit gbak verwenden, wird 'gbak' gezwungen, eine Verarbeitung zu verwenden, die nicht auf den Eingangs- oder Ausgangskanälen sucht, sodass sie für die Verwendung in Pipes geeignet sind — wie in den Beispielen in den Rezepten angegeben Abschnitt oben.

Diese Dateinamen scheinen zwar POSIX-Namen zu sein, sind aber definitiv keine Synonyme für /dev/stdin oder /dev/stdout. Sie sind einfach Literale, nach denen gbak bei der Verarbeitung seiner Parameter sucht.Versuchen Sie nicht, die Namen /dev/stdin oder /dev/stdout in einem Pipeline-Prozess zu verwenden, da dies höchstwahrscheinlich fehlschlagen wird.

Wenn Sie eine Dump-Datei mit dem Namen stdin oder stdout erstellen möchten, sollten Sie den Dateinamen als vollständigen oder relativen Pfadnamen wie ./stdin oder ./stdout angeben, wodurch "gbak" ausgelöst wird Behandeln Sie sie als wörtlichen Dateinamen und nicht als speziellen Dateinamen, der sich von der normalen Verarbeitung während des Dump- oder Wiederherstellungsprozesses unterscheidet.