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.