Vermeidung von Datenverlust

<< Arbeiten mit Datenbanken | Firebird 2 Schnellanleitung | Wie bekomme ich Hilfe >>

Vermeidung von Datenverlust

Sicherung

Firebird kommt mit zwei Tools für das Sichern und Wiederherstellen Ihrer Datenbanken: gbak und nbackup. Beide Tools befinden sich im bin Unterverzeichnis Ihrer Firebird Installation. Firebird Datenbanken können, während Benutzer damit verbunden sind, gesichert werden. Die Sicherung der Datenbank wird von einem Snapshot zum Zeitpunkt des Starts der Sicherung erstellt.

Periodische Sicherungen und gelegentliche Wiederherstellungen (Restore) sollten Teil Ihrer Datenbankmanagementaktivitäten sein.

Warnung: Ausgenommen in Backup's Lockmodus sollten Sie keine externen, proprietären Sicherungs- oder Dateikopiertools wie WinZip, tar, copy, xcopy, usw. auf Datenbanken, die in Verwendung sind, anwenden. Nicht nur dass die Sicherung unzuverlässig sein kann, so kann durch die Sperren auf Dateiebene dieser Tools auch Ihre laufende Datenbank beschädigt werden.

Wichtig: Lesen Sie die Warnungen im nächsten Abschnitt über Datenbankaktivitäten während einer Wiederherstellung aufmerksam durch!

Nähere Informationen über gbak können in The Firebird Book oder Using Firebird Guide (eine nicht so aktuelle Version ist via IBPhoenix verfügbar und eine aktualisierte Fassung wird bald auf der Firebird Website veröffentlicht werden) oder in den InterBase® 6.0 Handbüchern in Kombination mit den Firebird 1.5 und 2.0 Release Notes, nachgeschlagen werden. Die Links hierfür sind in Wie bekomme ich Hilfe angeführt.

Die Anleitung zu nbackup ist hier verfügbar (HTML und PDF Version mit dem selben Inhalt):

http://www.firebirdsql.org/manual/de/nbackup-de.html
http://www.firebirdsql.org/pdfmanual/de/Firebird-nbackup-de.pdf

Wie man eine Datenbank beschädigt

Der folgende Abschnitt stellt eine Zusammenfassung der Punkte dar, die man nicht machen sollte, wenn Sie Ihre Firebird Datenbank in guter Gesundheit erhalten wollen.

Manuelle Änderungen der Systemtabellen

Firebird speichert und verwaltet alle Metadaten in speziellen Tabellen, genannt Systemtabellen, die ebenfalls in der Datenbank abgelegt sind. Die Bezeichner für diese Tabellen, dessen Felder und einigen anderen Systemobjekttypen beginnen mit der Zeichenfolge RDB$.

Da es sich hierbei um normale Datenbankobjekte handelt, können diese, so wie jede andere benutzerdefinierte Tabelle, abgefragt und geändert werden. Nichtsdestotrotz, nur weil Sie das können, heißt das nicht, dass Sie das tun sollen. Die Firebird Engine implementiert hierfür eine höher angesiedelte Teilmenge von SQL genannt DDL, um die Definition und die Arbeit mit Metadatenobjekten zu ermöglichen. Typischerweise handelt es sich hier um CREATE, ALTER und DROP Anweisungen.

Es kann nicht streng genug darauf hingewiesen werden, dass Sie DDL und nicht direkte SQL Operationen auf Systemtabellen verwenden sollen, wann immer Sie Metadaten ändern oder entfernen. Verschieben Sie daher die "Hot Fix" Aktivitäten bis Sie fit in SQL und Ihr Wissen über die Firebird Engine entsprechend groß ist. Eine zerstörte Datenbanken ist weder hilfreich, noch günstig zu reparieren.

Deaktivieren von Forced Writes unter Windows

Firebird wird per Default mit Forced Writes (Synchrones Schreiben) installiert. Geänderte und neue Daten werden hiermit sofort auf die Festplatte geschrieben.

Es ist jedoch möglich, eine Firebird Datenbank so zu konfigurieren, dass ein asynchrones Schreiben verwendet wird, wo Änderungen und neue Daten vorerst im Cache gehalten werden, um diese dann durch das I/O Subsystem des Betriebssystems, periodisch auf die Festplatte zu schreiben. Die allgemeine Bezeichnung für diese Konfiguration ist Forced Writes Off (= deaktiviert). Auf diese Konfiguration wird manchmal zurückgegriffen, um große Batch-Operationen zu beschleunigen.

Die große Warnung ist nun: Deaktivieren Sie Forced Writes auf einem Windows Server nicht. Es wurde beobachtet, dass auf Windows Server Plattformen der Schreibcache nicht auf die Festplatte geschrieben wird, bis der Firebird Dienst gestoppt wird. Neben Stromausfällen gibt es einfach zu viele Situationen auf einem Windows Server, die schief gehen können. Bei einem Absturz bekommt das I/O System keine Möglichkeit die Änderungen noch auf die Festplatte zu schreiben und somit sind diese Änderungen bei einem Neustart verloren.

Anmerkung: Windows 9x und ME unterstützen keine verzögerten Schreiboperationen!

Deaktivieren von Forced Writes auf einem Linux Server

Linux Server sind diesbezüglich sicherer, wenn eine Operationen mit vorübergehend deaktiviertem Forced Writes ausgeführt werden soll. Trotzdem, lassen Sie Forced Writes nicht deaktiviert, nachdem die Batch-Operationen beendet wurde, solange Sie nicht über ein robustes Notstromsystem verfügen.

Wiederherstellen einer Sicherung über eine laufende Datenbank

Eine der Wiederherstellungsoptionen des gbak Tools (gbak -rep[lace_database]) erlaubt Ihnen eine Wiederherstellung einer gbak Datei über eine existierende Datenbank. Für diese Art der Wiederherstellung ist es möglich, dass der Wiederherstellungsprozess ohne Warnungen durchgeführt wird, obwohl Benutzer mit der Datenbank verbunden sind. Mit großer Sicherheit kann dies eine beschädigte Datenbank als Ergebnis haben.

Anmerkung: Beachten Sie, dass die kürzeste Form dieses Kommandos nun gbak -rep und nicht mehr gbak -r ist, wie das in früheren Firebird Versionen der Fall war. Was passierte mit gbak -r? Dies ist nun eine Kurzform für gbak -recreate_database, das die selbe Funktionalität wie gbak - c[reate] anbietet, und einen Fehler wirft, falls die angegebene Datenbank bereits existiert. Durch Angabe des o[verwrite] Flags kann jedoch das Überschreiben einer existierenden Datenbank erzwungen werden. Dieses Flag wird nur mit gbak -r und nicht mit gbak -c unterstützt.

Der Grund für diese Änderungen war, dass viele Benutzer der Meinung waren, dass der -r Schalter Restore anstatt von Replace bedeutet, und sie diesen Unterschied erst dann herausfanden, als es schon zu spät war.

Warnung: Stellen Sie sicher, dass Sie Ihre Administrationstools und Wiederherstellungsprozeduren dahingehend ändern, dass Sie sicherstellen, dass keine Wiederherstellung über eine existierende Datenbank erfolgt, wenn Benutzer mit der Datenbank verbunden sind.

Besser ist es, wenn Sie das Restore unter Verwendung der gbak -c[reate] Option auf einer Festplatte mit genügend freien Speicherplatz durchführen, und im Anschluß die wiederhergestellte Datenbank mit isql oder Ihrem bevorzugten Administrationstool testen. Falls die wiederhergestellte Datenbank in Ordnung ist, stoppen Sie den Firebird Server. Erstellen Sie danach eine Kopie der alten Datenbank auf Dateisystemebene und kopieren Sie die wiederhergestellte(n) Datenbankdatei(en) über die existierende(n) Datenbankdatei(en).

Benutzern das Einloggen während eines Restores erlauben

Falls Sie den Zugriff für Benutzer während einer Wiederherstellung unter Verwendung von gbak -rep[lace_database] nicht unterbinden, kann dies ebenfalls zur Folge haben, dass dies in einer beschädigten Datenbank endet.

zurück zum Seitenanfang
<< Arbeiten mit Datenbanken | Firebird 2 Schnellanleitung | Wie bekomme ich Hilfe >>