Locale Datenspeicherung bei SQL Server Ausfall

[Loewentier]

Habe ein generelles Problem wo Ihr mir vielleicht helfen könnt :gruebel:
Suche nach einer einfachen Lösung Daten die sich normalerweise auf einem Server befinden lokal speichern können, wenn jemand am Client den Netzwerkstecker zieht, bzw der Server ausfällt.

Schema:
Normalzustand: Client schreibt auf den Server
Netzwerkausfall: Software erkennt den Ausfall und speichert lokal zwischen
Netzwerk wieder da: Lokale Daten werden auf den Sever übertragen...
Alles läuft normal weiter :(

Will wenn möglich die Daten auch Lokal in eine Datenbank schreiben (Stichwort: Datensicherheit!) so dass auch bei einem Absturz keine Daten verloren gehen.
Eine parralele Installation von SQL Server und MSDE mit Datenabgleich derselben währe vielleicht ne Lösung...
Suche aber etwas einfach zu Installierends.

Über Anregungen und Ideen würde ich mich freuen

[Bernhard Geyer]

Zitat:

Zitat von Loewentier

Habe ein generelles Problem wo Ihr mir vielleicht helfen könnt :gruebel:
Suche nach einer einfachen Lösung Daten die sich normalerweise auf einem Server befinden lokal speichern können, wenn jemand am Client den Netzwerkstecker zieht, bzw der Server ausfällt.

Schema:
Normalzustand: Client schreibt auf den Server
Netzwerkausfall: Software erkennt den Ausfall und speichert lokal zwischen
Netzwerk wieder da: Lokale Daten werden auf den Sever übertragen...
Alles läuft normal weiter :(

Will wenn möglich die Daten auch Lokal in eine Datenbank schreiben (Stichwort: Datensicherheit!) so dass auch bei einem Absturz keine Daten verloren gehen.
Eine parralele Installation von SQL Server und MSDE mit Datenabgleich derselben währe vielleicht ne Lösung...
Suche aber etwas einfach zu Installierends.

Über Anregungen und Ideen würde ich mich freuen

Eine Idee wäre mit ClientDatasets zu arbeiten und im Batch-Betrieb die Daten zu synchronisieren. Aber damit habe ich noch nie gearbeitet.

Die alternative wäre das jeder Client einen SQL-Server (gleicher Typ wie Server) und dann die Anwendung nur mit diesen Arbeitet und mittels Synchronisationsmechanismen der Datenbank der Abgleich mit den Hauptdaten erfolgt.

Aber für ein normales Netzwerk/LAN ist das m.E. zu viel Aufwand. Das Netzwerk/SQL-Server muss genauso verfügbar sein wie Strom. Und wenn der nicht da wäre geht auch fast nichts. Für einen Außerhaus-Einsatz wären aber die o.g. Möglichkeiten vorhanden. Aber unterschätze den Aufwand nicht.

[marabu]

Hallo,

der vom MSSQL Server angebotene Replikationsmechanismus erfordert fast ausschließlich administrativen Aufwand und würde sogar mit MS Access als Publisher funktionieren. Eine verteilte Datenbank durch Replikation an einer zentralen Stelle zu aggregieren ist durchaus ein klassisches Szenario, aber wenn die Motivation für eine dezentrale Transaktionsdatenbank die miese uptime des zentralen SQL Servers sein sollte, dann geht die Forderung nach "Hochverfügbarkeit" auf den dezentralen Server über. Bernhard hat Recht - ohne hochverfügbaren DB-Server ist die Anwendung nicht viel wert.

Freundliche Grüße

[Loewentier]

Also erstmal vielen Dank für die Anregungen

Das Problem bei meiner Software ist, das es hier um typischerweise 2-24 h Stunden Tests in Pharmazeutischen Großindustrie geht.
(D.h. etwa alle XXX Sekunden mussen Daten über Tabletten gespeichert werden)
Kommt es zu einem Ausfall müsste der komplette Test wiederholt werden was für die Anwender Kosten von ~1000 € verursacht!
Natürlich sollte das Netzwerk performant sein...
Dieses Steckertest Kriterium ist aber neuerdings ein K.O. Kriterium für den Einsatz der Software!

[shmia]

Zitat:

Zitat von Loewentier

... etwa alle XXX Sekunden mussen Daten über Tabletten gespeichert werden

Dann müssen alle Daten zuerst in eine lokale Datei geschrieben werden. (Prozess A)
Ein zweiter Prozess (Prozess B) liest die Daten aus der Datei und bucht in die Datenbank.
Selbst wenn Prozess B wegen fehlender Datenbankverb. nicht weiterarbeiten kann, kann Prozess A doch weitermachen.
Anstelle einer lokalen Datei kann auch eine lokale Datenbank (z.B. Jet-Engine) verwendet werden.

[alzaimar]

Ich habe soetwas Ähnliches, aber mit SAP als Server. Nun ist SAP ja nicht immer verfügbar, zumindest nicht in dem Betrieb. Manchmal gehts, manchmal nicht.

Die Daten (Lieferergebnisse) werden an eine Text-Datei angehängt.

Der Prozess in SAP liest immer eine Zeile von der TExt-Datei und schiebt sie in SAP. Wenns klappt, wird die Zeile gelöscht. Wenn nicht, dann nicht. Das Ganze natürlich über Synchronisationsmechanismen und einigermaßen performant: Wenn SAP schon mal da ist, kann man ja gleich 1000 Zeilen auf einmal rüberblasen: Ist nach der 900.ten mal wieder Schicht-Im-Schacht, schreibe ich die nicht losgewordenen restlichen Daten einfach wieder zurück. Blöd, klappt aber.

[Loewentier]

Denke auch das das die Lösung ist...

Wenn möglich würde ich etwas eleganteres als eine Text Datei benutzen...
Aber wichtig ist mir vor allem das das ganze Zuverlässig und ohne eine spezielle Konfiguration
(Konnektion Einrichten über Jet Engine etc.) funktioniert.

PS: Habt Ihr schon mal was von SQL-Lite gehört?
Jemand gab mir den Tip das zu benutzen....
Denke aber das bringt nichts :roll:

[alzaimar]

Elegant ist die Textdatei sicherlich nicht, dafür hat sie den Vorteil, das keine lokale DB wegschmieren kann. Von Access würde ich die Finger lassen: Das ist nur im Einzelplatzbetrieb wirklich sicher...

Ein weiterer Vorteil der oberflächlich uneleganten Text-Lösung: Man kann ohne spezielle Software auf die Daten zugreifen und sie ..äh... den Bedürfnissen eines modernen Betriebes anpassen ..äh.. wenn Du verstehst, was ich meine (Auf Deutsch: Mauscheln!) Das war eine Forderung vom Kunden :mrgreen:

Alternativ kann man natürlich diese eine Datei durch jeweils eigene Dateien (eine pro Messung) ersetzen. SAP löscht einfach die Dateien, die vollständig und fehlerfrei importiert werden konnten.

Man sollte die 'DB' NTFS nicht unterschätzen.

[Loewentier]

DANKE für eure Hilfe!!!

Werde es mit der NTFS Datenbank :-D versuchen...
Denke auch das ist der einfachste und stabilste Weg
Melde mich wenn es was neues gibt