Mailinglist Archive: opensuse-de (5973 mails)

[Jan.Trippler@xxxxxxxxxxx (Jan Trippler)]

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@xxxxxxxx
For additional commands, e-mail: suse-linux-help@xxxxxxxx