Solange Mikros nur als Einplatzcomputer verwendet werden, müssen sich Datenbanken nicht um die Probleme des Concurrent Access kümmern. Sobald man aber ein (lokales) Netz schaltet, in dem mehrere Anwender Zugriff zu denselben Daten erhalten sollen, kommt die Problematik der Mehrbenutzerfähigkeit voll zum Tragen. Der Beitrag will das Problem strukturieren, verdeutlichen und mögliche Lösungen aufzeigen.
Am Anfang wurden die Mikros nur als Arbeitsplatzrechner für genau eine Person gesehen und eingesetzt. Dementsprechend zeigt die Mehrzahl der Datenbanken der ersten Stunden keine Mechanismen zur Bewältigung des gemeinsamen gleichzeitigen Zugriffs auf einen Datenbestand durch mehrere Benutzer.
Grundsätzlich unterscheiden sich bei diesem Sujet zwei Risiken. Zum einen, daß bei Verwendung der Datenbank der Benutzer falsche Daten erhält, zum zweiten das Risiko, daß die Datenbank durch die Mehrfachbenutzung in sich widersprüchlich (inkonsistent) wird. Das zweite Risiko kann bis zur Zerstörung der Datenbank führen.
Schnelle Antwort verfälscht zeitkritische Daten
Die Gefahr, falsche Auskünfte zu erhalten, muß man sehr relativiert sehen: Kann man den möglichen Fehler nur hinlänglich genau beschreiben und ist sich der Nutzer seiner bewußt, so wird er ihn oft billigend in Kauf nehmen. Das ist vielleicht verwunderlich, aber ein Beispiel möge dies erläutern: In einem Reisebüro läßt sich ein Kunde für alle möglichen Flüge die Reservierungs(...)e ermitteln. Dabei wird der Angestellte des Reisebüros darauf verzichten, alle befragten Flüge zu "locken". Das heißt, noch während der Kunde nachdenkt, kann es passieren, daß die Grundlage seines Nachdenkens falsch wird: In der Zwischenzeit haben andere Buchungen die Wahrheit verändert.
Solche in Kauf genommenen Fehler sind meistens Fehleinschätzungen in der Zeit. Bei der Verwendung der Datenbank wird akzeptiert, daß die Daten implizit einen gewissen Zeitstempel tragen und nach dieser Uhrzeit falsch werden können. Und das, obwohl dies durch entsprechende Sicherungsmechanismen verhindert werden könnte. Der Vorteil, den man aus dieser Ungenauigkeit gewinnt, besteht zumeist in der schnelleren Antwortzeit aus der Datenbank und - ein soziales Argument - aus der Tatsache, daß durch den Verzicht auf Sperren die Verfügbarkeit der Datenbank für die Allgemeinheit ansteigt.
Das zweite Risiko der Inkonsistenz ist meist schwerwiegender. Zwar gibt es Mechanismen, um gewisse Arten von Inkonsistenzen aufzufinden und zu beheben. Diese enden aber dort, wo die Tatsache der Datenkonsistenz nicht mehr aus den Daten selbst ableitbar ist, sondern nur aus dem Wissen um den Anwendungszusammenhang, das bei den Nutzern liegt. Haben sich solche Inkonsistenzen erst einmal eingeschlichen, ist es bis zum Punkt, an dem der Datenbestand wertlos wird, nicht mehr weit. Versucht zum Beispiel ein Nutzer in einer Adressendatenbank eine Adreßänderung einzubringen, während ein anderer gerade den gesamten Datenbestand reorganisiert, so können Verwüstungen jeder Art die Folge sein.
Schutzsysteme bannen die Gefahr
Um die Risiken zu bannen, existieren verschiedene Schutzmechanismen, die vom Sperren der gesamten Datenbank während eines Zugriffs bis zum Sperren lediglich des betroffenen Satzes reichen.
In Mikrocomputernetzen können die Sperrungen entweder von der Netzsoftware, vom Betriebssystem oder vom Anwenderprogramm vorgenommen werden. Dabei ist die letzte Methode die umständlichste und Software-architektonisch am wenigsten befriedigende. Dennoch ist sie zur Zeit noch sehr in Mode, ganz einfach deswegen, weil zum Beispiel MS-DOS (noch) keine Locking-Mechanismen anbietet (es ist eben als Einzelbenutzer-Betriebssystem erfunden worden) und weil viele Netze ebenfalls die Verwaltung des Concurrent Access dem Nutzer überlassen. Wenn die Netzsoftware dem Anwender einen Semaphormechanismus mit einer Programmschnittstelle anbietet, so handelt es sich um eine Zwischenlösung, in der das Netz zwar Funktionen zum Sperren offeriert, sich selbst aber um deren Verwendung nicht kümmert.
Das Sperren der gesamten Datenbank scheint zwar eine Holzhammermethode zu sein, es erfüllt aber in manchen Fällen durchaus seinen Zweck.
Betrachten wir ein Electronic-Mailing-System als Datenbank von Nachrichten. Hier ist es ausreichend, wenn die Datenbank nur für den Moment des Schreibens einer Nachricht gesperrt wird (um im Directory Ordnung zu halten). Während des Lesens einer Nachricht oder während des Editierens kann man auf die Sperre verzichten.
Die Folgerung: Kann man die Zeiträume für die Sperre sehr stark eingrenzen, so bietet sich das Sperren der gesamten Datenbank für diese kurzen Zeiträume an. Wobei "Sperren" hier nur heißt, daß während der Sperre kein zweiter schreibender Zugriff über die gesamte Datenbank möglich ist.
Eine Zwischenlösung ist das Sperren einer Datei innerhalb des Datenbestandes. Das Sperren eines Satzes schließlich führt zur "Hohen Schule" der Datenbankverwendung. Es existieren inzwischen File-Server für lokale Netze, die Record-Locking als Service mit anbieten. Damit ist die Basis für eine echte Multi-User-Datenbank geschaffen.
Locking im Anwenderprogramm ist eine Notlösung
Grundsätzlich ist es vorzuziehen, wenn der Sperrmechanismus möglichst weit unten im System implementiert ist, also in der Netzsoftware oder im Betriebssystem. Das Locking im Anwenderprogramm ist eine Notlösung.
Wo gesperrt und entsperrt wird, können auch Deadlocks auftreten. Darum muß man bei der Evaluation einer mehrbenutzerfähigen Datenbank gerade auf diesen Punkt achten: Was passiert, wenn ein Nutzer einen Zugriff beginnt, diesen aber nicht zu Ende führt, zum Beispiel, weil sein Arbeitsplatzrechner vom Stromnetz abgetrennt wird. Wann werden die von ihm gesetzten Sperren entdeckt, und wie werden sie wieder aufgelöst?
Hieraus ergibt sich die Frage, was für den Mikro-Anwender zu beachten ist.
Zuerst muß sich der Interessent darüber im klaren sein, daß die "normalen" Datenbanken für PCs nicht für einen Concurrent Access gedacht sind. Als nächstes muß er sich die Frage beantworten, ob er mit diesem Nachteil leben kann, das heißt, ob er durch organisatorische Regelungen den automatischen Schutz durch die Software ersetzen kann. Selbst wenn die Antwort auf diese Frage "Ja" ist, muß doch sichergestellt werden, daß die Datenbank netzfähig ist.
Viel Disziplin schützt vor bösen Überraschungen
In lokalen Netzen wird in der Regel eine Mehrbenutzerdatenbank gefordert sein. Inzwischen sind einige Punkte auf dem Markt (Dataflex, Datastore), die über MS-DOS Concurrent Access zulassen. Auf der Systems wurde ein File-Server gesehen, der selbst unter Unix lief und der sich MS-DOS-Rechnern (unter anderem) als Datenbank anbot (Banyon).
Wer die Wahl hat, sollte auf jeden Fall das Zeitverhalten bei Inanspruchnahme der Locking-Mechanismen mit etwas größeren Datenbeständen testen und überprüfen, wie Absturzsituationen gemeistert werden.
Ein Appell zum Schluß: Die Multi-User-Datenbank sollte mit viel Disziplin gesichert werden, am besten täglich. So ist man vor allzu unschönen Überraschungen sicher, auch wenn tatsächlich mal mehr schiefgeht, als eigentlich zu erwarten und zu akzeptieren wäre.
*Dr. Herbert Neumaier ist Geschäftsführer der Interface Concilium GmbH, München.