Hi, zuerst noch mal die eindringliche Bitte (unten hattest Du sie anscheinend übersehen): Lass das CC: weg. Diese Doppelmails nerven! On Don, Okt 26, 2000 at 09:40:07 +0200, Erhard Schwenk wrote:
On 25-Oct-00 Jan Trippler wrote:
[...]
Und das ist ohne weiteres auch mit gepufferten Zugriffen auf die HD zu realisieren.
Das allerdings ist definitiv falsch.
Siehe unten.
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.
Nochmal: Meine Frage war gerade, wo geschrieben steht, dass jede Änderung gleich im Tablespace landet - Du schreibst, _wenn_ sie da landet, dann gibt es Ärger - hmm. Das genau war _nicht_ meine Frage. Ich will doch gerade, dass Änderungen _nicht_ im Tablespace landen - zumindest nicht gleich den ursprünglichen Datensatz überschreiben. Also von mir auch ein Scenario (das ist Theorie, wie schon gesagt - ich weiss nicht, wie z. B. Informix das nun tatsächlich macht): Der zu ändernde Datensatz wird als *dirty* markiert -> der geänderte Datensatz wird _neu_ in den Tablespace (oder ins TA-Log) geschrieben mit der Verkettung *ich bin jetzt aktuell* -> das Before Image wird in das TA-Log geschrieben -> die Änderungen werden in das TA-Log geschrieben -> der Abschluss der Transaktion wird in das TA-Log geschrieben. Alle Schreibvorgänge laufen üblicherweise mit einem Timestamp ab. Jetzt kannst Du an jeder Stelle des Vorgangs den Stecker ziehen - Du kriegst immer den Zustand vor dem Beginn der Transaktion wieder hin. Du kannst auch die Reihenfolge der Writes von Log und Datensatz austauschen - es gibt für jede denkbare Kombination einen konsistenten Zustand. Selbst wenn das Dirty-Flag erst nach dem Schreiben des neuen Datensatzes auf der Platte landet (was ziemlich unwahrscheinlich ist), dann kann man das über die Existenz eines jüngeren Datensatzes abfangen. Mir fällt zumindest kein Fall ein, wo es nicht funktioniert. Und der *Dirty Page*-Mechanismus ist ein allgemein genutzter (z. B. in Caches, oder?)
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.
Doch, kann sie. Siehe oben.
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).
Für den ODS stimme ich Dir ja auch zu - seine Architektur setzt nun mal auf Raw-Devices auf. Das ist hier auch nicht das Thema, ich setze keine DBMS in einem Live-System unter Bedingungen ein, für die sie nicht gemacht sind.
Deshalb empfiehlt Informix auch SE auf keinen Fall für Mission Critical Anwendungen. Und genau deshalb haben externe Cache Controller auch batteriegepufferten Cache.
Über den Grund, SE nicht für diese Anwendungen einzusetzen kann man jetzt wirklich streiten. Nach meiner Erinnerung werden vor allem 2 Gründe genannt: - Performance. - Datensicherheit. Der ODS verfügt über einen fast recovery Mechanismus, und man kann anhand eines Backups und der Logical Logs nach einem Plattencrash der Zustand bis zum letzten auf Backup-Device gesicherten Log (bzw. der letzten darauf als abgeschlossen gekennzeichneten Transaktion) wiederherstellen. Das kann SE natürlich nicht - dort ist man auf das letzte Backup angewiesen.
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.
Auch hier wieder: Du bist exakt um 180 Grad an meiner Fragestellung vorbeigeschossen - ich meinte nicht das Schreiben von RAM nach HD, sondern das Aktualisieren des Satzes einer Tabelle durch seinen aktuellen Vertreter (siehe mein Scenario oben), also das Zurücksetzen des Dirty-Flags durch Überschreiben mit dem aktuellen Satz. Um auch noch einmal die ursprüngliche Fragestellung zu rekapitulieren: Deine Behauptung, dass eine Transaktionskontrolle bei DBMS, die auf Betriebssystem-Funktionalitäten (also Buffer) zurückgreifen, sinnlos ist, ist schlicht und einfach falsch: 1. Wie ich gezeigt habe, ist mit etwas Aufwand auch bei gepuffertem I/O die Konsistenz der Daten zu gewährleisten. 2. Transaktionssicherung bedeutet _auch_, aber bei Weitem nicht vorrangig den Schutz vor Systemausfällen. Viel häufiger sind folgende Fälle anzutreffen: - anwendungsbedingte Fehler, die ein Rollback verlangen (Absturz eines W*-Clients während einer Transaktion, Abbruch einer Verbindung zum Host bei Zahlungen im Internet ...) - den gewollten Rollback, weil Bedingungen zum Abschluss einer Transaktion nicht erfüllt sind (Konto-Abbuchung bei fehlender Deckung, matschige Daten, ...) - Timeouts durch Deadlocks - ...? Wie gesagt, diese Fälle treten wesentlich häufiger als Systemausfälle auf und rechtfertigen schon weitgehend die Existenz von Transaktionen in *gepufferten* DBMS. Ein Systemausfall ist Thema der Datensicherheit. TA-Logs können diese unterstützen, aber das ist nicht ihr Haupt-Existenzgrund. Wie ich auch schon geschrieben hatte: Ich widerspreche nicht dem Fakt, dass DBMS besser auf den Komfort des OS verzichten sollten und eigene IO mitbringen sollten. Nur sind meine Begründungen dafür andere. Jan P.S.: Falls Du es oben überlesen hast ;-) - lass die CC:'s weg - ich brauche Deine Mails nicht doppelt. P.P.S.: Wenn kein Widerspruch aus der Liste kommt, sollten wir das Thema vielleicht auf PM verlagern - mit Linux und SuSE hat das eigentlich nix mehr zu tun, auch wenn es interessant ist. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com