Defekte Interbase Datenbank erzeugen.
Holger Dickel-Herling
Ich brauche zu Testzwecken (Test von gfix) einen defekte Interbase
Datenbank. Wie bekomme ich das hin?
mfg
Holger Dickel-Herling
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Konrad Brandlhuber
> Datenbank. Wie bekomme ich das hin?
Wird schwierig:
Vorschlag 1;-)
Nimm Paradox die geht nach ein paar Tagen von selber kaputt.
Vorschlag 2;-)
Saug dir aus dem Internet einen Virus.
Vorschlag 3:-)
Nimm einen Hexeditor und ändere in der gdb ein paar Byte.
Im Ernst:
Mir ist mit Firebird und früher mit Interbase 6 noch keine Datenbank
kaputt gegangen (obwohl die meisten unter win98 oder XP Home laufen).
MfG
Brandlhuber
Holger Klemt
mit jedem hexeditor lässt sich die Datenbank zerschiessen, ist aber evtl.
dann auch mit gfix nicht mehr reparierbar.
was ist denn der Grund für den Test?
--
IBExpert - The most Expert for InterBase and Firebird --- www.ibexpert.com
HK Software - Holger Klemt - Huntestrasse 15 - D-26135 Oldenburg
Telefon Telefax +49 700 IBEXPERT (42397378) www.h-k.de
Schulungen - Projektunterstützung - Delphi - InterBase - AS/400
Marian Aldenhoevel
> Ich brauche zu Testzwecken (Test von gfix) einen defekte Interbase
> Datenbank. Wie bekomme ich das hin?
Realistisch? Kaum :-).
Ich habe in ein paar Jahren keine kaputtbekommen, weder im Betrieb
noch bei absichtlichen Stress-Tests.
Unrealistisch?
Schreibe ein Programm, das zufällig einen oder mehrere Bereiche der
GDB-Datei auswählt und mit Müll überschreibt. Lass' es laufen.
Teste die angeschossene Datenbank und suche den Fehler. Lässt sie
sich noch öffnen? Kann man alle Tabellen lesen? Funktioniert die
Client-Anwendung? Hauptproblem hier: Wie stellt man sicher, daß
man valide Tests hat?
Wiederhole diesen Vorgang auf einer sauberen GDB bis Du einen
"interessanten" Fehler erzeugt hast. Sichere diese unter einem
nicht weniger interessanten Namen. Jetzt kannst Du gfix drauf
loslassen.
Meine Meinung dazu? Warte auf den Ernstfall. Sicher, dann kann es
zu spät sein, aber das wäre es dann auf jeden Fall...
Ciao, MM
Andreas Schmidt
"Konrad Brandlhuber" <Em...@Kobrasoft.de> schrieb im Newsbeitrag
news:bccau6$hrg5m$1...@ID-12828.news.dfncis.de...
> > Ich brauche zu Testzwecken (Test von gfix) einen defekte Interbase
> > Datenbank. Wie bekomme ich das hin?
>
> Wird schwierig:
> Vorschlag 1;-)
> Nimm Paradox die geht nach ein paar Tagen von selber kaputt.
>
> Vorschlag 2;-)
> Saug dir aus dem Internet einen Virus.
>
> Vorschlag 3:-)
> Nimm einen Hexeditor und ändere in der gdb ein paar Byte.
>
Vorschlag 4:
Schreib ein Script, dass viele Daten einfügt und/oder verändert
und schalte dem Rechner mittendrin den Saft aus.
Andreas
Steve Rasch
"Andreas Schmidt" <a_j_s...@rocketmail.com> wrote:
>> > Ich brauche zu Testzwecken (Test von gfix) einen defekte Interbase
>> > Datenbank. Wie bekomme ich das hin?
>>
>Schreib ein Script, dass viele Daten einfügt und/oder verändert
>und schalte dem Rechner mittendrin den Saft aus.
Das wird nicht funktionieren, da daß in einer Transaktion läuft, ergo
nichts geschrieben wird...
Bye,
Steve
Christian Gütter
> >Schreib ein Script, dass viele Daten einfügt und/oder verändert
> >und schalte dem Rechner mittendrin den Saft aus.
>
> Das wird nicht funktionieren, da daß in einer Transaktion läuft, ergo
> nichts geschrieben wird...
Wenn Du einem Client den Strom wegnimmst, so stimmt Deine Aussage
zumindest zum Teil - der Server wird für die Transaktion einen Rollback
ausführen.
Nimmst Du allerdings dem Server den Strom, kann dadurch die Datenbank
durchaus beschädigt werden. Gerade auch dann, wenn viele Benutzer
gleichzeitig aktiv mit der Datenbank arbeiten.
Außerdem schreibt der Server sehr wohl auch bei laufenden Transaktionen
in die Datenbank. Starte mal ein aufwändiges Skript - wenn Du FORCED
WRITES nicht ausgeschaltet hast, wirst Du auf jeden Fall sofort
Plattenzugriffe verzeichnen können.
Gruß,
Christian
Steve Rasch
Wenn ich mich nicht irre, schreibt er aber nicht direkt in die
Datenbank, sondern erst mal in einen Cache. Er kann ja die Daten noch
nicht schreiben, weil sie wieder zurückgenommen werden können.
Außerdem ist der Interbase Server dafür ausgelegt, daß er öfter mal
neustartet - oder wofür braucht er den Guardian? Wir hatten durchaus
schon den einen oder anderen Stromausfall des Servers _ohne_ Probleme
an der Datenbank. Was viel leichter zu defekten Dateien führt, ist das
Sichern der Datenbank per Kopieren der physischen Datei. Viel mehr zu
dem Thema könnte aber sicher Holger Klemt schreiben...
Bye,
Steve
Mario Rothacher
> Nimmst Du allerdings dem Server den Strom, kann dadurch die Datenbank
> durchaus beschädigt werden. Gerade auch dann, wenn viele Benutzer
> gleichzeitig aktiv mit der Datenbank arbeiten.
Ein richtiger DB-Server (wo ich Interbase dazu zähle) sollte auch nach
einem Stromausfall beim aufstarten wieder einen konsistenten Zustand
haben. Egal wann der Strom weggezogen wird.
> Außerdem schreibt der Server sehr wohl auch bei laufenden Transaktionen
> in die Datenbank. Starte mal ein aufwändiges Skript - wenn Du FORCED
> WRITES nicht ausgeschaltet hast, wirst Du auf jeden Fall sofort
> Plattenzugriffe verzeichnen können.
Der Stromausfall während dem schreiben auf Platte sollte da auch
berücksichtigt sein. Das sind ganz normale Crash-Szenarios...
cu
Mario
Holger Klemt
> dem Thema könnte aber sicher Holger Klemt schreiben...
danke ;-)
Knackpunkt bei der Geschichte ist die Reihenfolge, in der geschrieben wird.
Ganz grob läuft das so:
Der Client holt sich eine neue Transaktions ID, diese wir vom Server in der
TransaktionsinventoryPage (TIP) als aktiv vermerkt.
Der Client macht ein Update, d.h es wird obwohl es eine Update ist, eine
neue Recordversion erzeugt, d.h. diese steht auch im Speicher in der
zugehörigen Datenpage. An jeder Recordversion steht auch die
Transaktionsnummer, von der diese Version erzeugt wurde.
Was passiert wenn der Client ein Commit macht? üblicherweise wird
dann die TIP im Speicher geändert und die Transaktion mit der Nummer n
bekommt den Status Commited. Auf die Platte werden aber
zunächst alle Datenpages zurückgeschrieben, dann erst die TIP.
Wenn genau zu diesem Zeitpunkt der Strom ausfällt, dann startet irgendwann
der Datenbankserver erneut. Was macht der beim ersten Öffnen der Datenbank?
Einfach erst mal alle Transaktionen, die aktiv sind, auf Rollback setzen
(kann
ja nicht sein, wenn der Server mit dem ersten neuen User auf die Datenbank
geht).
Es gibt keine grosse Reorganisation oder sonstiges.
Nun kommt der erste Select auf der Tabelle. Die Datenpage war zwar schon
geschrieben, aber die Recordversion ist Rollback, also unwichtig. Die Daten
sind also konsistent.
Die TIP hat in etwa folgenden Aufbau: Auf einer Page von z.B. 4k (je nach
Pagegröße der Datenbank) werden nach einem Header mit diversen Detailinfos
je 2Bit pro Transaktion. d.h. die Transaktionen 1-4 belegen nur ein Byte
usw. Die
Bitkombination bedeutet dann Commit, Aktiv, Rollback oder einen 4. Zustand
den ich hier nicht erklären möchte. In der 4k Page passen also ungefähr
16000
Transaktionen. alle geänderten TIP Pages (können also mehrere sein werden
"von vorne nach hinten" geschrieben, wenn also die letzten nicht mehr
geschrieben
werden können, dann werden deren Zustände halt beim nächsten Öffnen
Rollback.
Was ist so wichtig an Forced Writes? erstens wird dann bei jedem Commit auch
wirklich alles aus dem Speicher, was geändert wurde, in die Datei
geschrieben.
Zweitens (und eigentlich viel wichtiger): Die Pages werden in der
Reihenfolge
geschrieben, wie der IBServer das für sinnvoll hält, egal ob dabei in der
Datei
von hinten wieder nach vorne gesprungen wird.
Ohne Forced Writes haben die diversen Windoofs Versionen manchmal die
unerklärliche Angewohnheit, die Reihenfolge immer "von vorne
nach hinten" zu schreiben. Das kann dazu führen, das zum Beispiel bereits
"vorne" neue Datenpages in der Datenbank (Page Inventory
Page PIP) eingetragen wurden, obwohl die durch den Absturz gar nicht mehr
geschrieben werden konnten. Das führt zu hässlichen ... EOF Meldungen beim
Öffnen der Datenbank, die sich nur mit sehr viel Glück reparieren lassen.
Das erklärt auch die Probleme beim Kopieren der GDB im laufenden Betrieb,
denn auch hier können hinten ggf. Pages mit kopiert werden, die vorne laut
PIP gar nicht existieren (auch sehr ekelige Fehler, also so was immer
via backup/restore machen). Dort können nämlich ggf. auch neue TIP Pages
enstehen und die sollten auf jeden Fall konsistent sein.
Wie sagte schon Ann Harrison: Wenn man eine defekten IB Datenbank reparieren
möchte ist das manchmal ähnlich aufwändig, wie aus einem Haufen Hamburgern
wieder eine Kuh zu machen.
Fazit: bei aktiviertem Forced Writes ist es sehr schwierig eine Situation
herzustellen, bei der die Datenbank durch Stromausfall zerstört wird.
Diverse lokale Formate haben da mehr Probleme, weil nicht ein Prozess
die Schreibvorgänge kontrolliert wie beim IBServer sondern jeder Client
frei in der Datei oder sogar mehreren Dateien herumwurschteln kann und
da gibt es wesentlich mehr Möglichkeiten, etwas zu zerstören.
Die meisten anderen Datenbankserver machen beim Neustart nach
Ausfall zunächst mal eine Reorganistation und sind während dieser Zeit
im allgemeinen nicht für den Client erreichbar. Bei großen Datenbanken
und hohem Transaktionsaufkommen kann das schon recht lange dauern.
Der IBServer schriebt halt nur alle TIP Pages mit den ehemals aktiven
Transaktionen jetzt im Zustand Rollback neu auf die Platte. Dann kann
die Arbeit umgehend weitergehen :-)
Christian Gütter
> Wenn ich mich nicht irre, schreibt er aber nicht direkt in die
> Datenbank, sondern erst mal in einen Cache. Er kann ja die Daten noch
> nicht schreiben, weil sie wieder zurückgenommen werden können.
Das ist natürlich richtig - "Datenbank" meinte ich eher in einem
generelleren Sinne. Ich hatte mich dabei auf Deine Aussage bezogen,
dass "ergo nichts geschrieben wird". Das klang etwas mißverständlich.
> Außerdem ist der Interbase Server dafür ausgelegt, daß er öfter mal
> neustartet - oder wofür braucht er den Guardian?
Toi, toi, toi ...
Bei mir in der Firma läuft der Server 24x7 bei tagsüber etwa 20
gleichzeitig arbeitenden Benutzern, und der Guardian musste seit
Ende 1999 noch nie den Server neu starten. Da hab ich wohl entweder
Glück gehabt oder IB ist doch recht robust. Da ich aber nur diese
eine größere Installation habe, will ich mir kein Urteil anmaßen ...
> Wir hatten durchaus
> schon den einen oder anderen Stromausfall des Servers ohne Probleme
> an der Datenbank.
Kann ich mir durchaus vorstellen.
Meine Firma hat ziemlich umfangreiche Tests durchgeführt, bevor dort
IB in der Produktion eingesetzt wurde. Dazu gehörten auch Stromausfall-
szenarien, wenn der Server hoher Last stand.
Wir haben folgende Erfahrungen gemacht:
Mit Forced Writes hatten wir nur in sehr seltenen Fällen kleinere
Fehler, die sich aber mit GFIX ohne Probleme reparieren ließen.
Ohne Forced Writes gab es auch selten kleinere Fehler, aber zweimal war
die Datenbank so stark beschädigt, dass mit GFIX keine
Reparatur mehr möglich war. Ein Nebeneffekt war auch, dass ohne Forced
Writes immer ganze Massen von Daten verloren gingen, weil die Windows-
Version von IB/FB beim Schreiben der Daten recht träge war.
Erfreulicherweise soll dies in der neuen Firebird-Version behoben worden
sein.
Also wir setzen seit Jahren IB mit eingeschalteten Forced Writes und
einer USV ein und sind wie gesagt ganz glücklich damit ;-)
> Was viel leichter zu defekten Dateien führt, ist das
> Sichern der Datenbank per Kopieren der physischen Datei.
Das stimmt.
> Viel mehr zu
> dem Thema könnte aber sicher Holger Klemt schreiben...
Hat er schon.
War mal wieder sehr interessant :-)
Gruß,
Christian
Christian Gütter
> Ein richtiger DB-Server (wo ich Interbase dazu zähle) sollte auch
> nach einem Stromausfall beim aufstarten wieder einen konsistenten
> Zustand haben. Egal wann der Strom weggezogen wird.
[schnipp mein Zeugs]
> Der Stromausfall während dem schreiben auf Platte sollte da auch
> berücksichtigt sein. Das sind ganz normale Crash-Szenarios...
Meiner Erfahrung nach (siehe mein vorheriges Posting) kann es in
seltenen Fällen zu Problemen kommen. Holgers Erfahrungen klangen
ja so ähnlich.
Aber wie gesagt: mit eingeschalteten Forced Writes und einer USV
schläft man gut und wird ein IB/FB-Fan :-)
Gute Nacht,
Christian