On 25-Oct-00 Jan Trippler wrote:
Du verwechselst offensichtlich die Themen Datensicherheit und Transaktionskontrolle miteinander.
Nein, tu ich nicht, glaubs mir.
TA-Kontrolle hat nicht die Aufgabe, Datenverluste zu vermeiden, sie soll die Konsistenz der Daten gewährleisten.
Spweot richtig.
Und das ist ohne weiteres auch mit gepufferten Zugriffen auf die HD zu realisieren.
Das allerdings ist definitiv falsch.
Dazu werden für jede Transaktion der Start, die Before Images, Änderungen und der Commit gespeichert.
Wo steht denn, dass diese Änderungen unbedingt und in jedem Fall auch gleich im Tablespace landen müssen?
Ganz einfach. Folgendes Szenario: Die Änderung landet im Tablespace, die Before Image stehen aber noch im Plattenpuffer. Dann Stromausfall. Im Tablespace ist die TA nicht committed --> inkonsistente Datenbank. Im TA-Log steht aber nicht das Before Image --> Rollback nicht möglich.
Das kann doch die DB-Engine verwalten.
Nein, kann sie nicht. Weil sie nicht wissen kann, wann die Daten, die sie in eine gepufferte Datei schreibt, auch auf dem Datenträger landen. Das ist aber die wichtigste Voraussetzung für funktionierendes TA-Logging. Ich empfehle dir dazu mal einen Blick auf comp.os.databases.* bzw. die Archive davon, dort wird das immer wieder mit genau diesem Ergebnis diskutiert (und genau so wird es auch bei Informix Dynamic Server begründet). Deshalb empfiehlt Informix auch SE auf keinen Fall für Mission Critical Anwendungen. Und genau deshalb haben externe Cache Controller auch batteriegepufferten Cache.
Schlimmstenfalls werden die geänderten Sätze erst beim nächsten Neustart oder sync in die Tabellen geschrieben.
Wie denn, wenn der Rechner weg war? Sie stehen in keinen Tabellen, der sync konnte nicht ausgeführt werden. Die DB könnte natürlcih nach jedem Eintrag ins TA-Log einen sync ausführen, aber das würde die ganze Angelegenheit bis zur Unendlichkeit bremsen und den Plattenpuffer obsolet machen.
Wenn Du mit Deinen Ausführungen das Thema Datensicherheit / Recovery meinst - da stimme ich Dir zu. Das geht nur mit vollständiger Kontrolle des DBMS über die Festplattenzugriffe (was ist da eigentlich mit den Controller-Caches?). Ungepuffert läuft da allerdings auch nichts.
Nope, ich meine konkret die Konsistenzsicherung. Die wird durch einen transparenten Plattencache definitiv ausgehebelt. Kannst Du jeden fähigen DB-Prof fragen (wenn er denn fähig ist, auch da hab ich schon so einiges gesehen, wo mir schlecht wurde, daß man solche Leute auf Studenten losläßt). -- =========================================================== Erhard Schwenk - alias Bitrunner =)B==o) =========================================================== No Spam replies please. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com