FB1.5, forces writes on, blauer Bildschirm, DB futsch

[hoika]

Hallo #,

gestern beim Kunden.

Terminal-Server (Win 2003 32bit), Raid 5 usw
also ein "richtiger Server" ;)

Plötzlich stürzt das Teil mit blauem Bildschirm ab,
ich war aber gerade im Haus unterwegs (ich wars nicht ...).
Meldung: Igendwas mit memory parity error (blabla)

Nach Neustart lief alles, sogar mein Programm ...

Nur:
Backup brachte Fehler (error in 2 data pages)

Zum Glück liess sich das wieder reparieren (gfix) -> Puh, wieder ein paar graue Haare mehr


Nun die Frage:
Kann ich das irgendwie verhindern ?
Ich dachte "forces writes" sind dazu ausreichend,
aber wenn das Dateisystem mit abstürzt (blue screen), wohl nicht ?

Das Backup des letzten Tages einspielen ist keine Lösung.

Ich spiele mit dem Gedanken, per "geplante Vorgänge" vielleicht 3mal am Tag eine Sicherung zu machen.


Heiko

[WoGe]

Hallo,

hab es selber zwar noch nie getestet, aber da gibt es in FBdie Möglichkeit "Shadows" anzulegen:

Hier schauen
Das sollte gegen Dateisystem Fehler hilfreich sein

Gruss
wo

[hoika]

Hallo,

*erinner*
Was, wenn aber das shadow auch noch nicht geschrieben wurde
vor dem Absturz ?

Das shadow kann man zwar auf eine andere Platte (des gleiche Rechners) legen,
falls die Platte kaputt geht.
Aber der ganze Server war ja weg.


Heiko

[Bernhard Geyer]

Welche Art von Speicher steckt im Server? Speicher mit Fehlerkorrektur (Fehlermeldung: "Igendwas mit memory parity error" legt das nahe) oder 0815 DDR-Ram?

Bei 0815 RAM ohne Fehlerkorrektur und Erkennung kann dir leicht über Wochen fehlerhafte Daten gespeichert werden und irgendwann die DB explodieren.

[WoGe]

Zitat:

Zitat von hoika

Das shadow kann man zwar auf eine andere Platte (des gleiche Rechners) legen,
falls die Platte kaputt geht.
Aber der ganze Server war ja weg.

Scheint mir aber trotzdem eine Zeitnähere Kopie der DB zu sein, als 3mal tägliches Backup
Wobei das aber zusätzlich sinnvoll sein kann

Gruss
wo

[hoika]

Hallo,

< RAM >
Neh, ist kein RAM von der Stange (sagte zumindestens der Admin).
Lief ja auch die ganze Seit (seit Nov.) ohne Probleme.

< shadow >
ah so, im Vergleich zum Backup.
Stimmt, da ist shadow eine gute Alternative/Ersatz.


Heiko

[Blup]

Da der Server den Speicherfehler erkannt hat, dürfte es sich wohl auch um Speicher mit Parity handeln.
Der Fehler kann aber auch bei der Übertragung vom Speicher aufgetreten sein, da einfache Bitfehler normalerweise von entsprechend teureren Speicherchips erkannt und automatisch korrigiert werden.
Da die genaue Fehlermeldung nicht bekannt ist, könnte es sich auch um einen Fehler im Prozessor oder dessen Cache handeln.

Im Wiederholungsfall hilft eigentlich nur die Hardware zu ersetzen.

[Bernhard Geyer]

Zitat:

Zitat von hoika

Neh, ist ein RAM von der Stange (sagte zumindestens der Admin).

Wenn du Pech hast, hast du einen Supergau das schon über wochen die Datenbank aufgrund von RAM-Fehlern immer mehr korrupte Daten gespeicher. Lass mal einen RAM-Stresstest laufen (Diverse c't-CD's ist sowas drauf).

Zitat:

Zitat von hoika

Lief ja auch die ganze Seit (seit Nov.) ohne Probleme.

Und? Evtl. ist es bisher noch nicht aufgefallen und irgendein Windows-Update sorgt jetzt dafür das Windows die defekten RAM-Zellen jetzt öfters verwendet.

[hoika]

Hallo,

kann sowas von Software (nicht Windows selbst) erzeugt werden ?

Es lief da ein Test-Programm (als Admin gestartet, kein Dienst),
was per tcp-ip Daten aus einem externen Gerät im Netzwerk ausgelesen hat.


Heiko

[hoika]

Hallo,

die DB habe ich mir kopiert (als Original bei angehaltenem FB).
Backup -> Restore hat ja geklappt nach dem Reparieren.

Prüfen werde ich das trotzdem auf jeden Fall.

Mal den Admin ne Info mailen ...
Das mit dem "nach Windows-Update ..." klingt interessant,
weil logisch.
So viel läuft auf dem Server nicht, dass der RAM voll benutzt wird.

Ist ja kein Vista ;)


Danke


Heiko

[TBx]

Moin,

Du schreibst was von Raid.
Da greift das Forced writes nicht durch. Das Raid cached trotzdem selbständig und könnte im fehlerfall Teile der DB noch nicht geschrieben haben. Daher könnte der Fehler kommen.
Gruß

[hoika]

Hallo,

hat das Raid nicht so eine Einstellung, vorm Runterfahren die Daten zu schreiben ?
Ich hatte mal sowas gesehen.

OK, der Rechner ist nicht langsam runtergefahren, sondern schnell ... ;)

Aber die Raid-Hardware "lief" ja noch, Strom war drin ...
ausserdem hat der ne USV.

Ich werde mal alles hier Sammeln und dem Admin schicken.

Ich glaube aber, gerade das Deaktivieren des Raid-Schreib-Caches macht die Kiste sehr langsam, oder ?


Heiko

[TBx]

Zitat:

Zitat von hoika

Ich glaube aber, gerade das Deaktivieren des Raid-Schreib-Caches macht die Kiste sehr langsam, oder ?

Wird sich sicherlich deutlich bemerkbar machen.
Je nachdem, wieviel Datenverlust man ertragen kann, ist die von Dir gedachte Möglichkeit der Datensicherung ein guter Weg. Vergiss bitte nicht, die Backups auch zu prüfen, es hat schon des öfteren Fälle gegeben, in denen das Backup einwandfrei lief, das Restore aber verweigert wurde.

Wenn hohe Sicherheit für die DB verlangt wird, würde ich die auf eine separate Platte legen. Das ist sehr performant (gut, ein Raid ist durch die Pufferung noch immer schneller, aber je nach Datenmenge, die da regelmäßig geschrieben wird, fällt das mehr oder weniger ins Gewicht) und vor allem in Verbindung mit Forced Writes sehr sicher, da dann alle abgeschlossenen Transaktionen auch sofort auf die Platte gebracht werden.