On Mit, Okt 25, 2000 at 09:15:01 +0200, Erhard Schwenk wrote:
On 24-Oct-00 Jan Trippler wrote:
Das ist so nicht ganz korrekt. Informix-SE z. B. arbeitet mit normalen C-ISAM-Dateien und beherrscht Transaktions-Logging! Es funktioniert auch, frag mich jetzt aber nicht, wie genau das läuft.
Da würde ich Dir mal einen Blick ins Informix-Handbuch empfehlen, dort steht ausdrücklich geschrieben, daß sich das TA-Logging bei Ablage der DB in Dateien zwar aktivieren läßt, aber für die Zuverlässigkeit ausdrücklich nicht garantiert werden kann, weil die Plattenpuffer die Konsistenz des Logs gefährden. Zumindest beim Dynamic Server steht das drin, und das dürfte bei SE nicht viel anders sein.
Tja, jetzt könnte ich kontern: Da hättest Du mal im Handbuch weiterlesen sollen, ich tue es aber nicht ;-) Der Dynamic Server arbeitet mit einer eigenen Verwaltung der HD-Zugriffe am Betriebssystem vorbei und ist demzufolge in Raw-Devices besser aufgehoben. Wenn man ihn in einer Datei einrichtet, dann sollte man das nur in Test- oder Notfällen tun, da er eben darauf nicht eingerichtet ist. SE (= Standard Engine) arbeitet mit den normalen Dateizugriffen des Systems in einer C-ISAM-Struktur und kann gar nicht in einem Raw-Device geparkt werden. Es IST also bei SE definitiv anders als bei ODS. Das war im übrigen auch der Grund, warum Informix die SE wesentlich schneller als ODS (= Online Dynamic Server) auf Linux portiert hatte.
Kann auch gar nicht anders gehen. Die DB-Engine ist darauf angewiesen, daß im Crash-file das physikalisch auf der Platte liegende Transaction Log genau den ebenfalls physikalisch auf der Platte liegenden Tablespaces entspricht. Das kann gar nicht funktionieren, wenn da ein vom OS gesteuerter transparenter Puffer dazwischen hängt, wie er üblicherweise bei Filesystemen (und auch bei den Linux Block Devices) verwendet wird.
Du verwechselst offensichtlich die Themen Datensicherheit und Transaktionskontrolle miteinander. TA-Kontrolle hat nicht die Aufgabe, Datenverluste zu vermeiden, sie soll die Konsistenz der Daten gewährleisten. Und das ist ohne weiteres auch mit gepufferten Zugriffen auf die HD zu realisieren. 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? Das kann doch die DB-Engine verwalten. Schlimmstenfalls werden die geänderten Sätze erst beim nächsten Neustart oder sync in die Tabellen geschrieben. 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. Jan P.S.: Bitte kein CC: ich lese die Liste mit. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com