DB - Recovery Verfahren

Hallo,

ich schreibe meine Frage mal am Anfang: Gibt es im Unix, Linux, Windows sogenannte Recovery und Restart Verfahren (Wiederherstellungsverfahren) für Datenbanken und Dateien??

Problemstellung:

Nehmen wir einmal an ein Programm (a) soll auf mehreren DBs (Relational, Index Sequentiell usw.) lesend zugreifen und einen Output in einer sequentiellen Datei erstellen, das von einem Folgeprogramm (b) als Input erforderlich ist.

Programm (a) erstellt dieses sequentielle File aus einer Kunden und Konto DB aller Kunden, die als Saldo ihrer Konti mehr als sagen wir € 10.000,-- Guthaben haben. Dabei handelt es sich um sagen wir 2 Millionen Kunden mit 4 Millionen Konti.
Programm (b) erstellt jetzt einen Serienbrief auf Grund dieser erzeugten Datei und wirbt darin sagen wir für einen neuen Anlagefond.

Soweit sollte das für einen Durchschnittsprogrammierer keine grosse Herausforderung sein.

Nun noch mal zu meiner Frage:

Nehmen wir an Programm (a) hat nach 1,8 Millionen bearbeiteter Kunden einen Fehler und wird nicht richtig beendet. Die zu erstellende Datei ist also unvollständig. Gibt es nun im oben genannten BS Umfeld ein Verfahren, das ein Wiederaufsetzen zum Zeitpunkt der letzten Verarbeitung ermöglicht?? Sprich: Das korrigierte Programm (a) verarbeitet nach einem "Restart" nicht mehr alle 2 Millionen Kunden, sondern nur die verbleibenden 200.000. Natürlich ist dieser Vorgang zeitnah und die Input DBs sind auf "read only" gesetzt.

Besten Dank im voraus.

nman

restart schrieb:

Nehmen wir an Programm (a) hat nach 1,8 Millionen bearbeiteter Kunden einen Fehler und wird nicht richtig beendet. Die zu erstellende Datei ist also unvollständig. Gibt es nun im oben genannten BS Umfeld ein Verfahren, das ein Wiederaufsetzen zum Zeitpunkt der letzten Verarbeitung ermöglicht??

Wozu? 2 Mio. Datensätze sollten doch in Nullkommanix abgearbeitet sein. Wenn nicht irgendwas sehr seltsam ist, dann brauche ich für das Schreiben dieses Posts zig-mal so lange wie dein DBMS um diese Daten zu exportieren.

Nein

nman

Dann machst du irgendetwas falsch.

nman schrieb:

Dann machst du irgendetwas falsch.

Das "Nein" war nicht auf deine Antwort sondern auf die Frage gemeint.

nman schrieb:

restart schrieb:

Nehmen wir an Programm (a) hat nach 1,8 Millionen bearbeiteter Kunden einen Fehler und wird nicht richtig beendet. Die zu erstellende Datei ist also unvollständig. Gibt es nun im oben genannten BS Umfeld ein Verfahren, das ein Wiederaufsetzen zum Zeitpunkt der letzten Verarbeitung ermöglicht??

Wozu? 2 Mio. Datensätze sollten doch in Nullkommanix abgearbeitet sein. Wenn nicht irgendwas sehr seltsam ist, dann brauche ich für das Schreiben dieses Posts zig-mal so lange wie dein DBMS um diese Daten zu exportieren.

Das ist richtig. Offenbar habe ich die Problematik nicht richtig formuliert. Schrauben wir die Anforderungen also mit einem weiteren Beispiel etwas höher:

Nehmen wir an, sämtliche Transaktionen, die mit einer Scheckkarte an den Kassen im Einzelhandel an einem Tag bearbeitet werden müssen, wären an so einem Programmablauffehler betroffen. Sagen wir in diesem Fall nur in Deutschland etwa 600 Millionen Transaktionen/Tag bei Aldi, Lidl und Co. Diese Transaktionen müssen dann ja schlussendlich auf den betroffenen Konten zu- bzw abgebucht werden.

Jetzt kommt dann mein obengenannter Programmablauf hinzu, der ja den Ablauf stören könnte - und ich denke, darüber sind wir uns einig - wäre es wünschenswert, den "Hauptablauf" nicht mit solchen Dingen nachhaltig zu stören.

Jetzt gehen wir weiter davon aus, dass es der Letzte des Monats ist und die Gehalts-Gutschriften ebenfalls verbucht werden müssen. Natürlich müssen auch die entsprechenden Überweisungen für Miete, Strom, Tel usw. paralell dazu verbucht werden.

Jetzt bewegen wir uns in der Grössenordnung von ein paar Milliarden Buchungen innerhalb von nicht mal 24 Stunden. Das Ganze sollte auch noch Revisionsfähig sein - also muss es journalisiert werden - und - es MUSS bei einem Programmfehler recovery- und restartfähig sein, da der nächste Tag mit den selben Datenmengen unweigerlich irgendwann beginnt. Und gleichzeitig sollten nachts ja auch die Bankautomaten noch funktionieren - oder??

Nicht mitgezählt habe ich Kreditkartentransaktionen, Börsentransaktionen, Auslandstransaktionen usw...

Jetzt nochmal meine Frage:

ich schreibe meine Frage mal am Anfang: Gibt es im Unix, Linux, Windows sogenannte Recovery und Restart Verfahren (Wiederherstellungsverfahren) für Datenbanken und Dateien??

Die Antwort von:

manni66 schrieb:

Nein

Ich frage mich jetzt ernsthaft:

Wo und wie würdet ihr euere Windows, Linux, Unix IT einordnen, wenn nicht mal das Grundlegenste vernünftig gelöst ist??

nman

Wie du an deinem konstruierten Beispiel erkennst, ist das nicht grundlegend und daher nicht OS-Funktionalität.

Implementiert jedes RDBMS für sich selbst; alles klassische DB-Recovery-Themen, die du in jeder Vorlesung zum Thema Datenbanksysteme bis zum Erbrechen wiederkäuen kannst.

hustbaer

@restart
Es gibt kein "automagisches" Ding das du über dein Programm drüberstülpen kannst, und das dann dafür sorgt dass alles so läuft wie du willst.

Es gibt aber genügend Techniken wie man "mit Hand" sowas umsetzen kann. Auch ganz ohne Hilfe des Betriebssystems. Bzw. wenn man die recht banale (aber grundlegende) Funktion "FlushFileBuffers" (bzw. wie auch immer die gleichbedeutende Funktion unter nicht-Windows Systemem heisst) als Hilfe ansieht, dann natürlich mit Hilfe des OS.

Und dann wäre da noch Transactional NTFS. Damit kann man den Aufwand das ganze selbst zu Implementieren drastisch senken, und nicht zuletzt auch die Chancen dabei verbuggten Code zu produzieren.
Mit Transactional NTFS brauchst du bloss noch dein Output-File in vernünftig grossen Blöcken zu schreiben (z.B. 10K oder 100K Records), und jeden Block als eigene Transaktion ausführen. Transactional NTFS stellt dann sicher dass eine Transaktion ganz oder gar nicht geschrieben wird. D.h. du kannst beim Restart einfach das Output-File aufmachen, den letzten Datensatz auslesen und dann quasi mit recId > letzterDatensatz.recId weitermachen.

Ähnliches gibt es u.U. auch für Linux (kommt dort vermutlich auf das verwendete Filesystem an), und mit an Sicherheit grenzender Wahrscheinlichkeit auch für Solaris (ZFS kann schliesslich Data-Journalling -- dieses Feature nicht an Usermode Programme weiterzugeben käme einem Verbrechen gleich).

Wobei es bei so massiven Datenmengen mMn. zu überlegen wäre ob es nicht besser wäre den Output sowieso in mehrere Dateien aufzuteilen. Wenn man mal irgendwas nachkontrollieren muss macht es so überhaupt keinen Spass eine >= 1GB Datei im Texteditor aufzumachen. Ctrl+F in so einem Fall ist dann auch relativ langweilig.
Und sobald du ein File pro Block machst, brauchst du eigentlich keinen speziellen Support vom OS mehr. Dann schreibst du einfach jeden Block in ein Temp-File (mit speziellem Namen, damit es nicht mit einem "fertigen" File verwechselt werden kann), machst nach der letzten Zeile des Block 1x FlushFileBuffers(), und danach renamest du es auf den endgültigen Namen. Beim Restart musst du dann bloss noch gucken was das letzte Block-File ist (und idealerweise noch ob alle Block-Files davor auch da sind), und nach diesem fortsetzen.

Beide Varianten (Transactional NTFS und "1 File pro Block") sollten bei entsprechend gewählter Blockgrösse kaum einen spürbaren Einfluss auf die Geschwindigkeit haben.

Und jetzt zum eigentlichen Knackpunkt: wenn dir das alles NICHT bereits klar war, dann spreche ich dir die Kompetenz ab beurteilen zu können was in diesem Zusammenhang "grundlegend" und "vernünftig" ist. Und WENN es dir bereits klar war, dann Frage ich mich was du eigentlich willst...?

nman

hustbaer: Auf die diversen Transactional FS Implementierungen habe ich bewusst nicht hingewiesen. Microsoft empfiehlt explizit, TxF (NTFS) nicht mehr zu verwenden, weil sie es wahrscheinlich deprecaten werden. TxOS (ext3) ist soweit ich das beurteilen kann tot, genauso wie reiser4. Und die Transaction-Groups von ZFS unter Solaris sind nicht mit TxF vergleichbar.

Soweit ich sehen kann, geht der Trend gerade wieder recht stark weg von transaktionalen FS-APIs, auch wenn das vor ein paar Jahren "die Zukunft" war.

hustbaer

Huch, danke für den Hinweis, das (mit TxF) war mir nicht bekannt.

Ich find's irgendwie schade dass MS hier wiedermal so ein Monster geschaffen hat dass es wohl nicht wirtschaftlich ist es weiter zu pflegen, bzw. dass es Entwickler abschreckt damit zu arbeiten.

Mir hätte schon die Möglichkeit gereicht mehrere WriteFile() Aufrufe auf ein einziges File atomar committen zu können (inklusive dem ggf. nötigen Meta-Data-Update wenn sich dadurch die File-Grösse ändert).