InterBase- und Firebird-Wiederherstellungsleitfaden

NOTICE: Dieses Dokument ist ein Kapitel aus dem Buch “The InterBase World”, das von Alexey Kovyazin und Serg Vostrikov geschrieben wurde.

Das Kapitel aus dem Buch “The InterBase World”, das der Datenbankreparatur gewidmet ist.

1. Die Geschichte dieses Leitfadens

Das russische Buch “The InterBase World” wurde im September 2002 veröffentlicht.

Seine Auflage betrug 3000 Exemplare. Nach 3 Monaten war es ausverkauft und die zweite, verbesserte Auflage wurde im April 2003 mit einer Auflage von 5000 Exemplaren veröffentlicht.

Jetzt steht es an der Spitze der größten russischen Online-Buchhandlungen und wir gehen davon aus, dass es sehr bald ausverkauft sein wird.

Die Autoren des Buches sind Alexey Kovyazin, Entwickler von IBSurgeon und

bekannter russischer InterBase-Spezialist, sowie Serg Vostrikov, CEO von Devrace

Firma www.devrace.com

Es ist eine merkwürdige Sache, dass kein einziges Buch, das InterBase gewidmet ist, auf Englisch veröffentlicht wurde!

Tausende und Abertausende von Entwicklern nutzen InterBase und Firebird, diskutieren das

Thema in verschiedenen Konferenzen (schauen Sie hier: Links).

Die Gemeinschaft der InterBase-Entwickler umfasst durchschnittlich Zehntausende von

Menschen. Die starke Nachfrage nach InterBase-Büchern in verschiedenen Ländern beweist, dass die InterBase-Gemeinschaft wirklich groß ist.

Wir können darauf wetten, dass eine Auflage von 10000 Exemplaren innerhalb eines Monats von Amazon.com weggefegt würde. Aber die Leute in den Verlagsfirmen

“wissen alles” und sind sicher, dass niemand ein Buch über InterBase kauft. Das ist wirklich schade.

Hier möchten wir Ihnen den Entwurf eines Kapitels dieses Buches anbieten, das der Wiederherstellung von InterBase/Firebird-Datenbanken gewidmet ist.

2. Wie man eine InterBase/Firebird-Datenbank wiederherstellt

2.1. Überblick über die Hauptursachen für Datenbankkorruption

Leider besteht immer die Wahrscheinlichkeit, dass ein beliebiger Informationsspeicher

korrumpiert wird und einige Informationen daraus verloren gehen. Eine Datenbank ist keine Ausnahme von dieser Regel. In diesem Kapitel werden wir die Hauptursachen betrachten, die zu InterBase-Datenbankkorruption führen, einige Methoden zur Reparatur von Datenbanken und zur Extraktion von Informationen aus ihnen. Außerdem werden wir die Empfehlungen und Vorsichtsmaßnahmen kennenlernen, die die Wahrscheinlichkeit eines Informationsverlusts aus der Datenbank minimieren.

Zunächst sollten wir, wenn wir über Datenbankreparatur sprechen, den Begriff

“Datenbankkorruption” klären. Eine Datenbank wird normalerweise als beschädigt bezeichnet, wenn beim Versuch, einige Informationen zu extrahieren oder zu modifizieren, Fehler auftreten und/oder die extrahierten Informationen sich als verloren, unvollständig oder völlig falsch herausstellen. Es gibt Fälle, in denen Datenbankkorruptionen verborgen sind und nur durch Tests mit speziellen Werkzeugen gefunden werden, aber es gibt auch echte Datenbankkorruptionen, bei denen es unmöglich ist, sich mit der Datenbank zu verbinden, bei denen angepasste Client-Programme seltsame Fehler zeigen (wenn keine Manipulationen an der Datenbank durchgeführt wurden), oder bei denen es unmöglich ist, die Datenbank aus einer Sicherungskopie wiederherzustellen.

2.2. Hauptursachen für Datenbankkorruption sind:

Unnormaler Abbruch des Servercomputers, insbesondere Stromunterbrechung. Für die IT-Branche ist das eine echte Geißel, und deshalb hoffen wir, dass es nicht nötig ist, Sie noch einmal an die Notwendigkeit einer unterbrechungsfreien Stromversorgung auf dem Server zu erinnern.
Defekte und Fehler des Servercomputers, insbesondere der Festplatte (HDD), der Festplattencontroller, des Hauptspeichers des Computers und des Cache-Speichers von RAID-Controllern.
Eine nicht korrekte Verbindungszeichenfolge mit einer Multi-Client-Datenbank von einem oder mehreren Benutzern (in Versionen vor 6.x). Bei der Verbindung über TCP/IP muss der Pfad zur Datenbank als Servername: Laufwerk:/Pfad/Datenbankname /für Server auf UNIX-Plattform Servername: /Pfad/Datenbankname / angegeben werden, gemäß dem NETBEUI-Protokoll \\Servername\\Laufwerk:\\Pfad\\Datenbankname. Auch wenn Sie sich von dem Computer aus mit der Datenbank verbinden, auf dem sich die Datenbank befindet und der Server läuft, sollten Sie dieselbe Zeile verwenden und den Servernamen durch localhost ersetzen. Man darf kein zugeordnetes Laufwerk in der Verbindungszeile verwenden. Wenn Sie eine dieser Regeln brechen, geht der Server davon aus, dass er mit verschiedenen Datenbanken arbeitet, und Datenbankkorruption ist garantiert.
Dateikopie oder anderer Dateizugriff auf die Datenbank, während der Server läuft. Die Ausführung des Befehls “shut-down” oder das Trennen der Benutzer auf übliche Weise ist keine Garantie dafür, dass der Server nichts mit der Datenbank macht, wenn das Sweep-Intervall nicht auf “0” gesetzt ist, kann Garbage Collection ausgeführt werden. Im Allgemeinen wird die Garbage Collection unmittelbar nach der Trennung des letzten Benutzers von der Datenbank ausgeführt. Normalerweise dauert das einige Sekunden, aber wenn zuvor viele DELETE- oder UPDATE-Operationen committet wurden, kann der Prozess länger dauern.
Verwendung instabiler InterBase-Serverversionen 5.1-.5.5. Die Firma Borland hat offiziell zugegeben, dass es in diesen Servern mehrere Fehler gab, und ein stabiles Upgrade auf 5.6 wurde erst nach der Veröffentlichung des zertifizierten InterBase 6 im Free-Running-Modus für alle Kunden der Server 5.1-5.5 auf ihrer Website entfernt.
Überschreitung der Größenbeschränkung der Datenbankdatei (nicht einer Datenbank!). Für Pre-InterBase-6-Versionen und einige InterBase-6-Beta-Versionen beträgt das Datenbankdateilimit 4 GB, für InterBase 6.5 und alle Firebird-Versionen (1.0, 1.5, 2.0, 2.1) - 32 TB. Wenn sich die Datenbankgröße einem Grenzwert nähert, muss eine zusätzliche Datei erstellt werden.
Erschöpfung des freien Speicherplatzes bei der Arbeit mit der Datenbank.
Für Borland InterBase-Serverversionen unter 6.0.1.6 - Überschreitung der Beschränkung für die Anzahl der Generatoren, die von Borland InterBase R & D wie folgt definiert wurde (siehe Tabelle 1).


Version	Seitengröße=1024	Seitengröße=2048	Seitengröße=4096	Seitengröße=8192
Vor 6	248	504	1016	2040
6.0.x	124	257	508	102

Tabelle 1: Kritische Anzahl von Generatoren in frühen InterBase-Versionen

• Für alle Borland InterBase-Server - Überschreitung der zulässigen Anzahl von

Transaktionen ohne Durchführung von Backup/Restore. Die Anzahl der Transaktionen, die in der Datenbank seit der letzten Erstellung stattgefunden haben, kann man durch Aufruf des Dienstprogramms gstat mit dem Schlüssel - h erfahren - der Parameter NEXT TRANSACTION ID ist die gewünschte Anzahl von Transaktionen. Laut Ann W. Harrison hängt die kritische Anzahl von Transaktionen von der Seitengröße ab und hat die folgenden Werte (siehe Tabelle 2):


Datenbank-Seitengröße	Kritische Anzahl von Transaktionen
1024 Byte	131 596 287
2048 Byte	265 814 016
4096 Byte	534 249 472
8192 Byte	1 071 120 384

Tabelle 2: Kritische Anzahl von Transaktionen in Borland InterBase-Servern

Die oben aufgeführten Einschränkungen der Borland InterBase-Server gelten nicht für

Firebird-Server, mit Ausnahme der frühesten Versionen 0.x., deren Existenz bereits Geschichte ist. Wenn Sie die endgültige Version Firebird 1.0 oder InterBase 6.5-7.x verwenden, müssen Sie sich keine Sorgen um die Punkte 5, 6, 8 und 9 machen und sollten sich auf andere Ursachen konzentrieren. Nun werden wir die häufigsten davon im Detail betrachten.

2.3. Stromausfall

Beim Abschalten der Stromversorgung auf dem Server werden alle Aktivitäten der Datenverarbeitung an den unerwartetsten und (nach Murphy’s Gesetz) gefährlichsten Stellen unterbrochen. Infolgedessen können die Informationen in der Datenbank verzerrt oder verloren gehen. Der einfachste Fall ist, dass alle nicht committeten Daten von Client-Anwendungen infolge eines Notabschaltens des Servers verloren gehen. Nach einem Stromausfall-Neustart analysiert der Server die Daten, bemerkt unvollständige Transaktionen, die zu keinem der Clients gehören, und bricht alle Änderungen ab, die im Rahmen dieser “toten” Transaktionen vorgenommen wurden. Tatsächlich ist ein solches Verhalten normal und von den InterBase-Entwicklern von Anfang an vorgesehen.

Eine Stromunterbrechung führt jedoch nicht immer nur zu solch unbedeutenden Verlusten. Wenn der Server im Moment der Stromunterbrechung gerade die Datenbank erweiterte, besteht eine hohe Wahrscheinlichkeit für verwaiste Seiten in der Datenbankdatei (Seiten, die physisch zugewiesen und auf der Seiteninventarseite (PIP) registriert sind, auf die aber kein Datenschreiben möglich ist). Wenn Sie mehr über verwaiste Seiten erfahren möchten, schauen Sie in das Kapitel “Die Struktur der InterBase-Datenbank”.

Nur das Werkzeug zur Reparatur und Modifikation gfix (wir werden es unten betrachten) kann gegen verwaiste Seiten in der Datenbankdatei kämpfen. Tatsächlich führen verwaiste Seiten zu unnötigem Verbrauch von Speicherplatz und sind als solche nicht die Ursache für Datenverlust oder Korruption.

Stromausfall führt zu schwerwiegenderen Schäden. Zum Beispiel kann nach dem Abschalten der Stromversorgung und einem Neustart eine große Menge an Daten, einschließlich committeter, verloren gehen (nach dem Hinzufügen oder Modifizieren, für die ein Befehl “commit transaction” ausgeführt wurde). Dies geschieht, weil bestätigte Daten nicht direkt in die Datenbankdatei auf der Festplatte geschrieben werden. Und der Dateicache des Betriebssystems (OS) wird für diesen Zweck verwendet. Der Serverprozess gab dem Betriebssystem den Befehl zum Datenschreiben. Dann versicherte das Betriebssystem dem Server, dass alle Daten auf der Festplatte gespeichert wurden, und in Wirklichkeit wurden die Daten im Dateicache gespeichert. Das Betriebssystem beeilt sich nicht, diese Daten auf die Festplatte zu schreiben, weil es der Meinung ist, dass noch viel Hauptspeicher übrig ist, und verschiebt die langsamen Schreiboperationen auf die Festplatte, bis der Hauptspeicher gefüllt ist.

2.4. Forced Writes - ein zweischneidiges Schwert

Um die Situation zu beeinflussen, ist in InterBase 6 die Einstellung des Daten-Schreibmodus vorgesehen. Dieser Parameter heißt forced writes (FW) und hat 2 Modi - ON (synchron) und OFF (asynchron). FW-Modi definieren, wie InterBase mit der Festplatte kommuniziert. Wenn FW eingeschaltet ist, wird die Einstellung für synchrones Schreiben auf die Festplatte aktiviert, bei der bestätigte Daten direkt nach dem Commit-Befehl auf die Festplatte geschrieben werden, der Server wartet auf den Abschluss des Schreibens und setzt dann erst die Verarbeitung fort. Wenn FW ausgeschaltet ist, beeilt sich InterBase nicht, Daten nach dem Befehl des Transaktions-Commits auf die Festplatte zu schreiben, und delegiert diese Aufgabe an einen parallelen Thread, während der Haupt-Thread die Datenverarbeitung fortsetzt, ohne auf das Abschließen der Schreibvorgänge auf die Festplatte zu warten. Der synchrone Schreibmodus ist einer der sorgfältigsten und minimiert jeden möglichen Datenverlust, kann jedoch einen gewissen Leistungsverlust verursachen. Der asynchrone Schreibmodus erhöht die Wahrscheinlichkeit des Verlusts einer großen Datenmenge. Um maximale Leistung zu erzielen, wird normalerweise der FW-Off-Modus eingestellt. Aber als Folge einer Stromunterbrechung geht beim asynchronen Schreiben viel mehr Datenmenge verloren als beim synchronen. Bei der Einstellung des Schreibmodus sollten Sie entscheiden, ob ein paar Prozent Leistung bedeutender sind als ein paar Stunden Arbeit, wenn unerwartet eine Stromunterbrechung auftritt.

Sehr oft sind Benutzer nachlässig mit InterBase. Kleine Organisationen sparen an jeder Kleinigkeit, oft am Computer-Server, auf dem auch der DBMS-Server und verschiedene Serverprogramme (und nicht nur Server) installiert sind. Wenn sie hängen, drücken die Leute, ohne lange nachzudenken, RESET (das passiert mehrmals am Tag). Obwohl InterBase im Vergleich zu anderen DBMS sehr stabil gegenüber solchen Aktivitäten ist und es erlaubt, direkt nach einem Not-Neustart mit der Datenbank zu arbeiten, ist eine solche Nutzung nicht wünschenswert. Die Anzahl der verwaisten Seiten nimmt zu und Daten verlieren durch fehlerhafte Neustarts die Verbindung untereinander.

Das kann lange so weitergehen, aber früher oder später wird es ein Ende haben. Wenn beschädigte Seiten unter den PIP- oder Generatorseiten auftauchen oder wenn die Datenbank-Header-Seite korrupt ist, kann die Datenbank möglicherweise nie wieder geöffnet werden und wird zu einem großen Stück separater Daten, aus dem man kein einziges Byte nützlicher Informationen extrahieren kann.

2.5. Korruption der Festplatte

Festplattenkorruptionen führen zum Fehlen wichtiger Systemseiten der Datenbank und/oder zur Korruption von Verbindungen zwischen den verbleibenden Seiten. Solche Korruptionen gehören zu den schwierigsten Fällen, weil sie fast immer einen Eingriff auf niedriger Ebene erfordern, um die Datenbank wiederherzustellen.

2.6. Fehler beim Datenbankdesign

Es ist notwendig, dass Sie über einige Fehler von Datenbankentwicklern Bescheid wissen, die zur Unmöglichkeit der Datenbankwiederherstellung aus einer Sicherungskopie (*.gbk-Dateien, die vom gbak-Programm erstellt wurden) führen können. In erster Linie ist dies eine sorglose Verwendung von Einschränkungen auf Datenbankebene. Ein typisches Beispiel sind NOT NULL-Einschränkungen. Nehmen wir an, wir haben eine Tabelle, die mit einer Anzahl von Datensätzen gefüllt ist. Nun fügen wir dieser Tabelle mit dem Befehl ALTER TABLE eine weitere Spalte hinzu und geben an, dass sie keine undefinierten Werte NULL enthalten darf. So etwas wie:

ALTER TABLE sometable Field/INTEGER NOT NULL

Und in diesem Fall wird es keinen Serverfehler geben, wie man es erwarten könnte. Diese

Metadatenänderung wird committet und wir erhalten keine Fehler- oder Warnmeldung, was eine Illusion von Normalität dieser Situation erzeugt.

Wenn wir jedoch die Datenbank sichern und versuchen, sie aus einer Sicherungskopie wiederherzustellen, erhalten

wir eine Fehlermeldung in der Wiederherstellungsphase (weil NULL-Werte in die Spalte mit der NOT NULL-Einschränkung eingefügt werden und der Wiederherstellungsprozess unterbrochen wird. (Wichtiger Hinweis von Craig Stuntz - bei Version InterBase 7.1 werden Einschränkungen standardmäßig während der Wiederherstellung ignoriert (dies kann über einen Befehlszeilenschalter gesteuert werden) und fast jede nicht beschädigte Sicherung kann wiederhergestellt werden. Es ist immer eine gute Idee, nach der Erstellung einer Sicherung eine Testwiederherstellung durchzuführen, aber dieses Problem sollte in Version 7.1 weitgehend verschwinden.) Diese Sicherungskopie kann nicht wiederhergestellt werden. Wenn die Wiederherstellung auf eine Datei mit demselben Namen wie die vorhandene Datenbank gerichtet war (während der Wiederherstellung wurde die Arbeitsdatei der vorhandenen Datenbank überschrieben), verlieren wir die gesamten Informationen.

Dies hängt damit zusammen, dass NOT NULL-Einschränkungen durch Systemtrigger implementiert werden, die nur eingehende Daten prüfen. Während der Wiederherstellung werden die Daten aus der Sicherungskopie in die leeren, gerade erstellten Tabellen eingefügt - hier können unzulässige NULL-Werte in der Spalte mit der NOT NULL-Einschränkung gefunden werden.

Einige Entwickler halten ein solches InterBase-Verhalten für falsch, aber andere werden nicht in der Lage sein, ein Feld mit NOT NULL-Einschränkung zur Datenbanktabelle hinzuzufügen.

Eine Frage über den erforderlichen Standardwert und das Auffüllen damit im Moment der

Erstellung wurde von Firebird-Architekten ausführlich diskutiert, wurde aber nicht akzeptiert, weil der Programmierer ihn offensichtlich nach einem ziemlich komplexen und möglicherweise iterativen Algorithmus ausfüllen wird. Es gibt jedoch keine Garantie, ob er die von der vorherigen Iteration ignorierten Datensätze von nicht ausgefüllten Datensätzen unterscheiden kann oder nicht.

Ein ähnliches Problem kann durch einen Garbage-Collection-Fehler verursacht werden, weil beim Verbindungsaufbau ein falscher Pfad zur Datenbank gesetzt wurde (Ursache der Korruption 3) und beim Dateizugriff auf Datenbankdateien, während der Server damit arbeitet (Ursache der Korruption 4), und vollständig mit NULL gefüllte Datensätze können in einigen Tabellen erscheinen. Es ist sehr schwierig, diese Datensätze zu erkennen, weil sie nicht den Integritätskontrollbeschränkungen entsprechen und der Operator SELECT sie einfach nicht sieht, obwohl sie in die Sicherungskopie gelangen. Wenn eine Wiederherstellung aus diesem Grund unmöglich ist, sollte man das Programm gfix ausführen (siehe unten), diese Datensätze finden und mit nicht indizierten Feldern als Suchbedingungen löschen, danach erneut eine Sicherungskopie erstellen und die Datenbank daraus wiederherstellen. Zusammenfassend können wir sagen, dass es eine große Anzahl von Ursachen für Datenbankkorruption gibt und man immer auf das Schlimmste vorbereitet sein sollte - dass die Datenbank aus dem einen oder anderen Grund beschädigt wird. Man muss auch bereit sein, wertvolle Informationen wiederherzustellen und zu retten. Und jetzt betrachten wir Vorsichtsmaßnahmen, die die Sicherheit der InterBase-Datenbank garantieren, sowie Methoden zur Reparatur beschädigter Datenbanken.

2.7. Vorsichtsmaßnahmen gegen InterBase-Datenbankkorruption

Um Datenbankkorruption zu verhindern, sollte man immer Sicherungskopien erstellen (wenn Sie mehr über Sicherung erfahren möchten, sehen Sie sich das Kapitel „Sicherung und Wiederherstellung“ an). Es ist der vertrauenswürdigste Weg gegen Datenbankkorruption. Nur die Sicherung gibt eine 100%ige Garantie für die Datenbanksicherheit. Wie oben beschrieben, können wir als Ergebnis der Sicherung eine unbrauchbare Kopie erhalten (eine Kopie, die nicht wiederhergestellt werden kann), deshalb darf die Wiederherstellung einer Datenbank aus der Kopie nicht durch Überschreiben des Skripts erfolgen, und die Sicherung muss nach bestimmten Regeln durchgeführt werden. Erstens muss die Sicherung so oft wie möglich ausgeführt werden, zweitens muss sie seriell sein und drittens müssen Sicherungskopien auf Wiederherstellbarkeit geprüft werden.

Oft bedeutet Sicherung, dass es notwendig ist, ziemlich oft eine Sicherungskopie zu erstellen, zum Beispiel einmal in vierundzwanzig Stunden. Je kürzer der Datenzeitraum zwischen den Datenbanksicherungen ist, desto weniger Daten gehen als Folge eines Fehlers verloren. Sequenz der Sicherung bedeutet, dass die Anzahl der Sicherungen zunehmen und mindestens eine Woche aufbewahrt werden muss. Wenn möglich, ist es notwendig, Sicherungen auf spezielle Geräte wie Streamer zu schreiben, wenn nicht - kopieren Sie sie einfach auf einen anderen Computer. Die Historie der Sicherungskopien hilft, versteckte Korruptionen zu entdecken und mit Fehlern fertig zu werden, die vor langer Zeit entstanden sind und unerwartet auftraten. Man muss prüfen, ob es möglich ist, die erhaltene Sicherung ohne Fehler wiederherzustellen oder nicht. Dies kann nur auf eine Weise geprüft werden - durch den Testwiederherstellungsprozess. Es sollte gesagt werden, dass der Wiederherstellungsprozess dreimal mehr Zeit in Anspruch nimmt als die Sicherung, und es ist schwierig, die Wiederherstellungsvalidierung täglich für große Datenbanken durchzuführen, weil sie die Arbeit der Benutzer für einige Stunden unterbrechen kann (die Nachtpause könnte nicht ausreichen).

Es wäre besser, wenn große Organisationen nicht an „Streichhölzern“ sparen würden und einen Computer für diese Zwecke übrig ließen.

In diesem Fall, wenn der Server 24 Stunden 7 Tage die Woche unter ernsthafter Last arbeiten muss, können wir den SHADOW-Mechanismus verwenden, um Snapshots von der Datenbank zu erstellen und weitere Sicherungsoperationen von der unmittelbaren Kopie durchzuführen. Der Sicherungsprozess und die Datenbankwiederherstellung werden im Kapitel „Sicherung und Wiederherstellung“ ausführlich beschrieben. Beim Erstellen einer Sicherung und anschließendem Wiederherstellen der Datenbank daraus wird eine Neuerstellung aller Daten in der Datenbank durchgeführt. Dieser Prozess (Sicherung/Wiederherstellung oder S/W) trägt zur Korrektur der meisten nicht tödlichen Fehler in der Datenbank bei, die mit Festplattenkorruptionen verbunden sind, erkennt Integritätsprobleme in der Datenbank, bereinigt die Datenbank von Müll (alte Versionen und Fragmente von Datensätzen, unvollständige Transaktionen) und verringert die Datenbankgröße erheblich.

Regelmäßiges S/W ist eine Garantie für die Sicherheit der InterBase-Datenbank. Wenn die Datenbank funktioniert, wird empfohlen, S/W jede Woche durchzuführen. Um die Wahrheit zu sagen, gibt es einige Beispiele für InterBase-Datenbanken, die über Jahre hinweg intensiv ohne Sicherung/Wiederherstellung genutzt werden.

Dennoch ist es zur Sicherheit wünschenswert, dieses Verfahren durchzuführen, besonders da es leicht automatisiert werden kann (siehe Kapitel „Sicherung“).

Wenn es aus bestimmten Gründen unmöglich ist, die Sicherung/Wiederherstellung oft durchzuführen, kann man das Werkzeug gfix zum Prüfen und Wiederherstellen der Datenbank verwenden. gfix ermöglicht es, viele Fehler ohne S/W zu prüfen und zu beheben.

2.8. Befehlszeilenwerkzeug gfix

Das Befehlszeilenwerkzeug gfix wird zum Prüfen und Wiederherstellen der Datenbank verwendet. Außerdem kann gfix auch verschiedene Aktivitäten der Datenbanksteuerung ausführen: Ändern des Datenbankdialekts, Setzen und Aufheben des Modus „Nur-Lesen“, Setzen der Cache-Größe für eine konkrete Datenbank sowie einige wichtige Funktionen (Sie können darüber im InterBase 6 Operations Guide [4.) erfahren. gfix wird im Befehlszeilenmodus ausgeführt und hat die folgende Syntax:

Gfix [Optionen] db-Name

Optionen - ist eine Reihe von Optionen zur Ausführung von gfix, db-Name ist der Name der Datenbank, über die Operationen durchgeführt werden, definiert durch die Reihe von Optionen. Tabelle 3 stellt die Optionen von gfix im Zusammenhang mit der Datenbankreparatur dar:


Option	Beschreibung
-f[ull]	Diese Option wird in Kombination mit -v verwendet und bedeutet, dass es Zeit ist, alle Fragmente von Datensätzen zu prüfen
-i[gnore]	Option lässt gfix Prüfsummenfehler ignorieren zum Zeitpunkt der Validierung oder Datenbankbereinigung
-m[end]	Markiert beschädigte Datensätze als nicht verfügbar, als Ergebnis werden sie während der folgenden Sicherung/Wiederherstellung gelöscht. Option wird zum Zeitpunkt der Vorbereitung der beschädigten Datenbank für S/W verwendet.
-n[o_update]	Option wird in Kombination mit -v für Nur-Lese-Datenbankvalidierung ohne Korrektur von Korruptionen verwendet
-pas[swort]	Option ermöglicht es, das Passwort beim Verbinden mit der Datenbank zu setzen. (Beachten Sie, dass es ein Fehler in der InterBase-Dokumentation ist -pa[sswort], aber die Abkürzung „-pa“ funktioniert nicht - verwenden Sie „-pas“)
-user	Option ermöglicht es, den Benutzernamen beim Verbinden mit der Datenbank zu setzen
-v[alidate]	Option zur Voreinstellung der Datenbankvalidierung, auf deren Weise Fehler entdeckt werden
-m[ode]	Option zum Setzen des Schreibmodus für die Datenbank - für Nur-Lesen oder Lesen/Schreiben. Dieser Parameter kann 2 Werte annehmen - read write oder read only.
-w[rite] {sync \| async}	Option, die den Modus synchron/asynchron erzwungener Schreibvorgänge in die Datenbank ein- und ausschaltet. sync - zum Einschalten synchroner Schreibvorgänge (FW ON); async - zum Einschalten asynchroner Schreibvorgänge (FW OFF);

Tabelle 1: gfix-Werkzeugoptionen für die Datenbankwiederherstellung

Es gibt einige typische Beispiele für die Verwendung von gfix:

gfix -w sync -user SYSDBA -pass masterkey firstbase.gdb

In diesem Beispiel setzen wir für unsere Testdatenbank firstbase.gdb den synchronen Schreibmodus (FW ON). (Natürlich ist es nützlich, bevor die Korruption auftritt). Und unten ist der erste Befehl, den Sie verwenden sollten, um die Datenbank nach dem Auftreten der Korruption zu prüfen:

gfix -v -full -user SYSDBA -pass masterkey firstbase.gdb

In diesem Beispiel starten wir die Prüfung unserer Testdatenbank (Option -v) und geben an, dass auch Fragmente von Datensätzen geprüft werden müssen (Option -full). Natürlich ist es bequemer, verschiedene Optionen für den Prüf- und Wiederherstellungsprozess über eine GUI einzustellen, aber wir betrachten die Funktionen der Datenbankwiederherstellung mit Befehlszeilenwerkzeugen. Diese Werkzeuge sind in InterBase enthalten und Sie können sicher sein, dass ihr Verhalten auf allen Betriebssystemen, die InterBase ausführen, gleich ist. Es ist sehr wichtig, dass sie immer in der Nähe sind.

Außerdem verwenden die vorhandenen Werkzeuge, die die Datenbankverwaltung von einem

Client-Computer aus ermöglichen, die Services-API dafür, die von der InterBase-Server-Architektur Classic nicht unterstützt wird. Das bedeutet, Sie können Produkte von Drittanbietern mit der Server-Architektur SuperServer verwenden.

2.9. Die Reparatur einer beschädigten Datenbank

Nehmen wir an, es gibt einige Fehler in unserer Datenbank. Erstens müssen wir die Existenz dieser Fehler prüfen; zweitens müssen wir versuchen, diese Fehler zu korrigieren. Sie sollten die folgenden Anweisungen befolgen.

Sie sollten den InterBase-Server stoppen, wenn er noch arbeitet, und eine Kopie der Datei oder der Datenbankdateien erstellen. Alle Wiederherstellungsaktivitäten sollten nur mit der Datenbankkopie durchgeführt werden, weil der gewählte Weg zu einem unglücklichen Ergebnis führen kann und Sie eine Wiederherstellungsprozedur (von einem Ausgangspunkt) neu starten müssen. Nach dem Erstellen einer Kopie führen wir die gesamte Datenbankvalidierung durch (Prüfung der Fragmente von Datensätzen).

Wir sollten den folgenden Befehl dafür ausführen:

gfix -v - full corruptbase gdb -user SYSDBA - password

In diesem Fall ist corruptbase.gdb - eine Kopie der beschädigten Datenbank. Ein Befehl wird

die Datenbank auf Strukturkorruption prüfen und die Liste der ungelösten Probleme geben. Wenn solche Fehler erkannt werden, müssen wir die beschädigten Daten löschen und uns für die Sicherung/Wiederherstellung mit dem folgenden Befehl vorbereiten:

gfix -mend -user SYSDBA -password your_masterkey corruptbase gdb

Nach dem Ausführen eines Befehls sollten Sie prüfen, ob noch einige Fehler in der Datenbank vorhanden sind. Sie müssen gfix mit den Optionen -v -full dafür ausführen, und wenn der Prozess beendet ist, führen Sie die Datenbanksicherung durch:

gbak -b -v -ig -user SYSDBA -password corruptbase.gdb corruptbase.gbk

Dieser Befehl führt eine Datenbanksicherung durch (Option - b sagt dies) und wir erhalten detaillierte Informationen über die Ausführung des Sicherungsprozesses (Option -v). Fehler bezüglich Prüfsummen werden ignoriert (Option - ig). Wenn Sie mehr Informationen über die Optionen des Befehlszeilenwerkzeugs gbak wünschen, finden Sie diese im Kapitel „Sicherung und Wiederherstellung“. Wenn es einige Fehler bei der Sicherung gibt, sollten Sie sie in einer anderen Konfiguration starten:

gbak -b -v -ig -g -user SYSDBA -password corruptbase.gdb

corruptbase.gbk

Wobei Option - g die Garbage Collection während der Sicherung ausschaltet. Dies hilft oft, ein Problem mit der Sicherung zu lösen.

Es könnte auch möglich sein, eine Sicherung der Datenbank zu erstellen, wenn wir vorher die Datenbank in den Nur-Lese-Modus setzen. Dieser Modus verhindert das Schreiben von Änderungen in die Datenbank und hilft manchmal, eine Sicherung der beschädigten Datenbank durchzuführen. Zum Setzen der Datenbank in den Nur-Lese-Modus sollten Sie den folgenden Befehl verwenden: gfix -m read_only

-user SYSDBA -password masterkey Disk:\Path\file.gdb

Danach sollten Sie erneut versuchen, die Datenbanksicherung mit den oben angegebenen Parametern durchzuführen.

Wenn die Sicherung erfolgreich war, sollten Sie die Datenbank aus der Sicherungskopie wiederherstellen. Verwenden Sie dazu den folgenden Befehl:

gbak -c -user SYSDBA -password masterkey Disk:\Path\backup.gbk

Disk:\Path\newbase,gdb

Beim Wiederherstellen der Datenbank können einige Probleme auftreten, insbesondere beim Erstellen der Indizes. In diesem Fall sollten die Optionen -inactive und -one_at_a_time zum Wiederherstellungsbefehl hinzugefügt werden. Diese Optionen deaktivieren Indizes beim Erstellen aus der Datenbanksicherung und bestätigen die Daten für jede Tabelle.

2.10. Wie Sie versuchen können, Daten aus einer beschädigten Datenbank zu extrahieren

Es ist möglich, dass die oben genannten Operationen nicht zur Wiederherstellung der Datenbank führen. Das bedeutet, dass die Datenbank ernsthaft beschädigt ist oder nicht als Ganzes wiederhergestellt werden kann, oder dass große Anstrengungen für ihre Wiederherstellung unternommen werden müssen. Beispielsweise kann man eine Änderung der Systemmetadaten ausführen, nicht dokumentierte Funktionen verwenden und so weiter. Dies ist eine sehr harte, langwierige und undankbare Arbeit mit zweifelhaften Erfolgsaussichten. Und wenn es möglich ist, versuchen Sie, dies zu vermeiden und andere Methoden zu verwenden. Wenn eine beschädigte Datenbank geöffnet wird und Lese- und Änderungsoperationen mit einigen Daten ermöglicht, sollten Sie diese Möglichkeit nutzen und die Daten speichern, indem Sie sie in eine neue Datenbank kopieren und sich für immer von der alten verabschieden.

Bevor Sie also die Daten aus der alten Datenbank übertragen, ist es notwendig, eine Zieldatenbank zu erstellen. Wenn die Datenbank lange Zeit nicht geändert wurde, können Sie die alte Sicherung verwenden, aus der Metadaten für die Erstellung einer Zieldatenbank extrahiert werden können. Auf der Grundlage dieser Metadaten muss eine Zieldatenbank erstellt und mit dem Kopieren der Daten begonnen werden. Die Hauptaufgabe besteht darin, die Daten aus einer beschädigten Datenbank zu extrahieren. Dann müssen wir die Daten in einer neuen Datenbank zuweisen, aber das ist nicht sehr schwierig, selbst wenn wir die Datenbankstruktur aus dem Gedächtnis wiederherstellen müssen. Beim Extrahieren von Daten aus Tabellen sollten Sie den folgenden Algorithmus der Operationen verwenden:

Zuerst sollten Sie versuchen, SELECT* aus Tabelle N auszuführen. Wenn dies normal verlief, können Sie die erhaltenen Daten in der externen Quelle speichern. Es ist besser, Daten in einem Skript zu speichern (fast alle GUIs bieten diese Funktion), sofern die Tabelle keine BLOB-Felder enthält. Wenn die Tabelle BLOB-Felder enthält, sollten die Daten daraus von einem Clientprogramm, das als Vermittler fungiert, in eine andere Datenbank gespeichert werden. Vielleicht müssen Sie dieses triviale Programm speziell für Datenwiederherstellungszwecke schreiben.
Wenn Sie nicht alle Daten abrufen konnten, sollten Sie alle Indizes löschen und es erneut versuchen. Praktisch können Indizes von allen Tabellen von Beginn der Wiederherstellung an gelöscht werden, da sie nicht mehr benötigt werden. Wenn Sie natürlich keine Metadatenstruktur haben, die der beschädigten entspricht, ist es notwendig, ein Protokoll aller Operationen einzugeben, die Sie mit der beschädigten Datenbankquelle durchführen.
Wenn Sie es nicht schaffen, alle Daten aus der Tabelle nach dem Löschen der Indizes zu lesen, können Sie versuchen, eine Bereichsabfrage über den Primärschlüssel durchzuführen. Das bedeutet, einen bestimmten Datenbereich auszuwählen. Zum Beispiel:

SELECT * FROM table N WHERE field_PK >=0 and field_PK <=10000 Field_PK

hier ist ein Primärschlüssel. InterBase hat eine Seitenorganisation der Daten, und deshalb kann eine Bereichsabfrage von Werten ziemlich effektiv sein, obwohl es wie eine Art Schamanismus erscheint. Trotzdem funktioniert es, weil wir Daten aus beschädigten Seiten aus der Abfrage ausschließen und glücklicherweise die anderen lesen können. Sie können sich an unsere These erinnern, dass es keine definierte Reihenfolge der Speicherung von Datensätzen in SQL gibt. Wirklich, niemand garantiert, dass eine nicht geordnete Abfrage bei Neustarts die Datensätze in derselben Reihenfolge zurückgibt, aber dennoch werden physische Datensätze innerhalb der Datenbank in einer definierten internen Reihenfolge gespeichert. Es ist offensichtlich, dass der Server die Datensätze nicht nur zur Einhaltung des SQL-Standards mischen wird. Man kann versuchen, diese interne Reihenfolge beim Extrahieren von Daten aus einer beschädigten Datenbank zu nutzen (wenn Sie mehr Informationen über Datenseiten und ihre Korrelationen erfahren möchten, sehen Sie sich das Kapitel „Struktur der InterBase-Datenbank“ an).

Vitaliy Barmin, einer der erfahrenen russischen InterBase-Entwickler, berichtete, dass er auf diese Weise bis zu 98% der Informationen aus einer nicht wiederherstellbaren Datenbank wiederherstellen konnte (es gab eine große Anzahl beschädigter Seiten). Somit müssen Daten aus einer beschädigten Datenbank in eine neue Datenbank oder in externe Quellen wie SQL-Skripte verschoben werden. Wenn Sie die Daten kopieren, achten Sie auf die Generatorwerte in der beschädigten Datenbank (sie müssen gespeichert werden, um einen ordnungsgemäßen Betrieb in der neuen Datenbank neu zu starten. Wenn Sie keine vollständige Kopie der Metadaten haben, sollten Sie die Texte von gespeicherten Prozeduren, Triggern, Einschränkungen und die Definition von Indizes extrahieren.

2.11. Wiederherstellung einer hoffnungslosen Datenbank

Im Allgemeinen kann die Wiederherstellung einer Datenbank sehr mühsam und schwierig sein, und deshalb ist es besser, eine Sicherungskopie der Datenbank zu erstellen, als die beschädigten Daten wiederherzustellen, und was auch immer passiert, Sie sollten nicht verzweifeln, denn eine Lösung kann in den schwierigsten Situationen gefunden werden. Und jetzt betrachten wir 2 Fälle.

Der erste Fall (ein klassisches Problem). Eine Sicherung, die nicht wiederhergestellt werden kann, weil sie NULL-Werte in der Spalte mit der Einschränkung NOT NULL enthält (der Wiederherstellungsprozess wurde über der Arbeitsdatei ausgeführt). Die Arbeitsdatei wurde gelöscht und der Wiederherstellungsprozess wurde wegen eines Fehlers unterbrochen. Und als Ergebnis gedankenloser Handlungen erhielten wir eine große Menge nutzloser Daten (die nicht wiederhergestellt werden können) anstelle der Sicherungskopie. Aber die Lösung wurde gefunden. Der Programmierer konnte sich erinnern, welche Tabelle und welche Spalte die Einschränkung NOT NULL hatten. Die Sicherungsdatei wurde in einen Hexadezimaleditor geladen. Und eine Kombination von Bytes, die der Definition dieser Spalte entsprach, wurde dort durch Suchen gefunden. Nach unzähligen Experimenten stellte sich heraus, dass die Einschränkung NOT NULL eine 1 in der Nähe des Spaltennamens hinzufügt. Im HEX-Editor wurde diese „1“ auf „0“ korrigiert und die Sicherungskopie wurde wiederhergestellt. Nach diesem Fall merkte sich der Programmierer ein für alle Mal, wie man den Sicherungsprozess und die Wiederherstellung ausführt.

Der zweite Fall. Die Situation war katastrophal. Die Datenbank wurde in der Phase der Erweiterung wegen fehlenden Speicherplatzes beschädigt. Beim Vergrößern der Datenbankgröße erstellt der Server eine Reihe kritisch wichtiger Seiten (z. B. Transaktionsinventarseite und Seiteninventarseite, zusätzliche Seiten für die RDB$Pages-Beziehung) und schreibt sie an das Ende der Datenbank. Infolgedessen öffnete die Datenbank weder über Verwaltungsfunktionen noch über das Dienstprogramm GBAK. Und als wir versuchten, uns mit der Datenbank zu verbinden, erschien eine Fehlermeldung („Unerwartetes Dateiende“).

Als wir das Dienstprogramm gfix ausführten, geschahen seltsame Dinge: Das Programm arbeitete in einer Endlosschleife. Während gfix arbeitete, schrieb der Server Fehler mit hoher Geschwindigkeit (etwa 100 KB pro Sekunde) in das Protokoll (Datei InterBase log). Infolgedessen füllte die Protokolldatei sehr schnell den gesamten freien Speicherplatz. Wir mussten sogar ein Programm schreiben, das dieses Protokoll per Timer löschte. Dieser Prozess dauerte lange - gfix arbeitete mehr als 16 Stunden ohne Ergebnisse. Das Protokoll war mit Fehlern der folgenden Ansicht gefüllt: „Seite XXX doppelt zugewiesen“. In den Startquellen von InterBase (in der Datei val.#) gibt es eine kurze Beschreibung dieses Fehlers. Es besagt, dass dieser Fehler auftritt, wenn dieselbe Datenseite zweimal verwendet wird. Es ist offensichtlich, dass dieser Fehler eine Folge der Beschädigung kritisch wichtiger Seiten ist.

Infolgedessen wurden nach mehreren Tagen unglücklicher Experimente Versuche, die Daten auf standardmäßige Weise wiederherzustellen, aufgegeben. Und deshalb mussten wir eine Low-Level-Analyse der in der beschädigten Datenbank gespeicherten Daten verwenden.

Alexander Kozelskiy, Leiter der Abteilung Informationstechnologien bei East View Publications Inc, ist der Autor der Idee, Informationen aus ähnlichen nicht wiederherstellbaren Datenbanken zu extrahieren.

Die Methode der Wiederherstellung, die wir als Ergebnis von Forschungen erhielten, basierte auf der Tatsache, dass die Datenbank eine Seitenorganisation hat und Daten aus jeder Tabelle durch Datenseiten gesammelt werden. Jede Datenseite enthält einen Bezeichner der Tabelle, für die sie Daten speichert. Es war besonders wichtig, Daten aus mehreren kritischen Tabellen wiederherzustellen. Es gab Daten aus ähnlichen Tabellen, die aus einer alten Sicherungskopie stammten, die einwandfrei funktionierte und als Muster dienen konnte. Die Musterdatenbank wurde in den Editor für hexadezimale Quellen geladen, und dann suchten wir nach den Mustern der Daten, die uns interessierten. Diese Daten wurden im Hexadezimalformat in den Puffer kopiert, und dann wurden die Überreste der beschädigten Datenbank in den Editor geladen. Eine Sequenz von Bytes, die dem Muster entsprach, wurde in der beschädigten Datenbank gefunden, und die Seite (auf der diese Sequenz gefunden wurde) wurde analysiert.

Zuerst definierten wir die Anfangsseite, aber das war nicht schwierig, da die Größe der Datenbankdatei durch die Datenseitengröße teilbar ist. Eine Nummer des aktuellen Bytes geteilt durch die Seitengröße - 8192 Bytes, nähert das Ergebnis auf eine ganze Zahl an (und erhielt die Nummer der aktuellen Seite). Dann multiplizierte die Nummer der aktuellen Seite mit der Seitengröße und erhielt die Nummer des Bytes, das dem Anfang der aktuellen Seite entspricht. Nach der Analyse des Headers definierten wir den Seitentyp (für Seiten mit Daten ist der Typ 5 - siehe Datei ods.h aus dem Satz der Startquellen von InterBase und auch das Kapitel „Die Struktur der InterBase-Datenbank“) sowie den Bezeichner der erforderlichen Tabelle.

Dann wurde ein Programm geschrieben, das die gesamte Datenbank analysierte, alle Seiten für die erforderliche Tabelle in einem einzigen Stück sammelte und in eine Datei verschob.

Als wir also die Daten erhielten, die wir zuerst benötigten, begannen wir mit der Analyse des Inhalts ausgewählter Seiten. InterBase verwendet in großem Umfang Datenkomprimierung, um Platz zu sparen. Beispielsweise speichert eine Zeichenfolge wie VARCHAR, die die Zeichenfolge „ABC“ enthält, die folgende Sequenz von Werten: Zeichenfolgenlänge (2 Bytes), in unserem Fall 0003, und dann die Symbole selbst und dann die Prüfsumme. Wir mussten einen Analysator für Zeichenfolgen sowie andere Datenbanktypen schreiben, der Daten vom Hexadezimalformat in die normale Ansicht konvertierte. Es gelang uns, bis zu 80% der Informationen aus mehreren kritischen Tabellen mit einer „manuellen“ Methode der Analyse des Datenbankinhalts zu extrahieren. Später entwickelten Oleg Kulkov und Alexey Kovyazin, einer der Autoren dieses Buches, auf der Grundlage der Erfahrung das Dienstprogramm InterBase Surgeon, das direkten Zugriff auf die Datenbank unter Umgehung der InterBase-Engine ermöglicht und es erlaubt, Daten innerhalb einer InterBase-Datenbank direkt und ordnungsgemäß zu lesen und zu interpretieren.

Mit InterBase Surgeon gelingt es uns, Ursachen von Beschädigungen zu erkennen und bis zu 90% absolut nicht wiederherstellbarer Datenbanken wiederherzustellen, die von InterBase nicht geöffnet und mit standardmäßigen Methoden nicht wiederhergestellt werden können.

Sie können dieses Programm von der offiziellen Programmwebsite www.ib-aid.com herunterladen.

3. Danksagung

Ich möchte allen danken, die mir bei der Erstellung dieses Leitfadens geholfen haben:

Craig Stuntz, Alexander Nevsky, Konstantin Sipachev, Tatjana Sipacheva und allen anderen freundlichen und sachkundigen Menschen der InterBase- und Firebird-Community.

Wenn Sie Vorschläge oder Fragen zu diesem Kapitel haben, senden Sie bitte eine E-Mail.