Was passiert eigentlich wenn eine DB während oder kurz nach
einem Commit hart crashed (im Sinne Stromausfall) ?
Sind die Daten auf Platte dann in jedem Fall noch Konsistent ?
bei oracle ist es so, dass alle schreibzugriffe direkt in datafile vorgenommen werden, der alte inhalt wird dabei ins sogenannte rollback-segment kopiert. zusätzlich werden alle ausgeführten befehle in einem sogenannten redo-logfile gesichert (stand oracle 8 - bei neueren versionen heisst das ev. anders, dürfte intern aber ähnlich funktionieren).
wenn also genau während eines commits ein stromausfall passiert, steht der neue wert bereits im datafile. oracle erkennt aber, dass das letzte statement noch nicht korrekt commited wurde. es muss also „recovern“ - dabei wird der letzte als konsistent angenommen bestand hergenommen und alle änderungen, die seitdem passiert sind und auch commited wurden (aus dem redo-logfile) angewendet. das ganze dauert zwar manchmal eine weile, führt aber zu einem aus datenbanksicht konsistenten zustand.
Welche Protokolle werden auf den Platten angewand um dies zu
garantieren ?
hat mit der platte nix zu tun
Geht das nicht unheimlich zu Lasten der Performance ?
natürlich. aber das ist der preis für sicheres arbeiten. in unternehmenskritischen anwendungen kostet eine inkonsistenz aufgrund eines stromausfalls weitaus mehr als der verwaltungs-overhead für die datenkonsistenz. für spielzeug-anwendungen gibt es spielzeug-datenbanken, die schön performant sind.
Bei verteilten DB’s stell ich mir das ganze noch wesentlich
härter vor, gilt da auch in jedem Fall Konsistenz
(vorrausgesetzt alle Daten aller beteiligter Server sind nach
dem Hochfahren wieder da) ?
ist es auch - verteilte commits werden nach den sogenannten two-phase-commit-verfahren durchgeführt. dabei stellt die datenbank zu fast 100% sicher, dass die daten konsistent bleiben. in einigen fällen kann es aber dazu kommen, dass der status von transaktionen zweifelhaft ist (transaction in doubt). dann muss der administrator eingreifen und die transaktion manuell abbrechen. sobald alle beteiligten datenbanken wieder verfügbar sind, wird automatisch auf einen konsistenten zustand recovered. ist natürlich ebenfalls eine höllischer aufwand. nur gleiche argumentation wie oben: in unternehmenskritischen anwendungen muss konsistenz vor performance kommen (ausser die performance ist das unternehmenskritische daran).
aber performance kann mit intensiven hardware-einsatz erschlagen. schlechtes db-design führt zu inkonsistenzen, die keiner mehr reparieren kann. der aufwand ist damit gerechtfertigt.
erwin
