Gottfried Weiss

Transkript

1 Gottfried Weiss Zusammenfassung Datenbanken werden heute sehr weit verbreitet eingesetzt, weil sie es erlauben, einfach, nebenläufig und konsistenzerhaltend mit Daten zu arbeiten. Es gibt jedoch Anwendungsfelder, bei denen dies nicht ausreicht. Eines davon sind zeitkritische Softwaresysteme, und sie verlangen nach einer Erweiterung der Datenbankfunktionalität um Echtzeitfunktionen. Eine solche Erweiterung bedingt weitreichende Änderungen im Aufbau und in der Arbeitsweise eines Datenbankmanagementsystems. Ein kleiner Einblick in diese Problematik soll im vorliegenden Artikel gewährt werden. 1 Einleitung Ein klassisches Datenbanksystem hat die Aufgabe, die Daten zu speichern, Operationen zum Lesen, Einfügen, Verändern und Löschen der Daten korrekt durchzuführen und über diese Operationen hinweg die Daten konsistent zu halten. Dazu werden Transaktionen verwendet, und diese Transaktionen müssen die sogenannten ACID-Kriterien erfüllen. ACID ist hier ein Akronym aus den Anfangsbuchstaben der Wörter Atomicity, Consistency Preservation, Isolation und Durability. [1] Diese einfachen Anforderungen an eine Transaktion haben sich aber durch die steigende Anwendung von Datenbanksystemen in verschiedenen Problembereichen als nicht ausreichend erwiesen, weil das ACID-Konzept eine rein datenzentrierte Sicht darstellt und kein Einfluss der Anwendungsumgebung auf das Transaktionsmodell ausübbar ist. Daher existieren für die einzelnen Aufgabenstellungen aus der Anwendungswelt verschiedene Erweiterungen von Transaktionen, die mehr oder weniger große Veränderungen an Entwurf und Implementierung des Datenbankmanagementsystems bedingen. Eine dieser Anforderungen mit großem Einfluß auf das gesamte System ist der Bedarf nach zeitgerechter Antwort des Datenbanksystems auf eine Transaktion, wobei von dieser Anforderung alle vier Standardoperationen eingeschlossen werden, sodass nachprüfbar ist, ob eine Operation zeitgerecht ausgeführt wurde. Diese Antwort wird bei einer Leseoperation trivialerweise durch die erhaltenen Daten repräsentiert, beim Einfügen, Verändern und Löschen zumindest durch Statusmeldungen. Datenbanksysteme, die diese zeitlichen Bedingungen an ihre Transaktionen erfüllen, werden als Echtzeitdatenbanksysteme bezeichnet. Eine Definition dieser Echtzeitdaten- 1

2 banksysteme ist, dass sie Datenbanksysteme darstellen, in welchen Transaktionen mit Echtzeitanforderungen verbunden werden, typischerweise in der Form von Deadlines. [2] Anwendungsgebiete, in denen Echtzeitdatenbanksysteme erforderlich sind, gibt es viele. Beispielhaft seien hier vier davon genannt. Das erste ist der Handel mit Handelsgütern, die schnell veränderlichen Preisen unterliegen, genannt, wie Wertpapier- oder Produktenbörsen, oder auch Online-Auktionen. Ein weiteres bekanntes Anwendungsgebiet ist Netzwerkmanagement wie beispielsweise im Mobilfunksystem GSM, welches die Mobilität der Benutzer unterstützt. GSM ist zellulär aufgebaut und beim Übertritt eines Benutzers muss die Zellzugehörigkeit des Benutzers in der Datenbank aktualisiert werden, damit der Benutzer eingehende Daten empfangen kann. Dieses Update muss innerhalb einer gewissen Frist erfolgen, damit dieses Handover den Benutzer nicht in seiner Kommunikation stört oder die Verbindung gar abbricht. Von großer wirtschaftlicher Bedeutung ist der Einsatz von Echtzeitdatenbanken in der Prozesssteuerung, üblicherweise in der industriellen Fertigung. Durch den Siegeszug von Just-in-Time-Produktion und die damit verbundene Reduzierung von Zwischenlagern bei gleichzeitiger Umstellung auf Computersteuerung der Fertigungsanlagen besteht die Echtzeitanforderung darin, dass die Komponenten der Fertigung genau zu einem bestimmten Zeitpunkt am Platz ihrer Verarbeitung eintreffen, damit einerseits keine Anhäufung von Komponenten den Raumbedarf erhöht und andererseits - und das ist die Hauptanforderung - eine Fertigungsstraße nicht aufgrund von verspätet eintreffenden Komponenten im Arbeitsprozess angehalten werden muss und so kostenintensive Stehzeiten entstehen. Auch Steuerungs- und Überwachungssysteme besitzen oft Echtzeitanforderungen, welche die zu Grunde liegende Datenbank einhalten muss. Ein Beispiel dafür ist die Verfolgung von Verwaltungsübertretungen, die durch ein Verkehrsüberwachungssystem entdeckt werden, wie die Erkennung von Mautprellern. Um eine zeitgerechte Bestrafung zu ermöglichen, muss ein Mautüberwachungsfahrzeug einen Mautpreller aus dem fließenden Verkehr herausnehmen können, und damit muss dem Überwachungsfahrzeug die Information über das zu kontrollierende Fahrzeug rechtzeitig zugehen, damit dieses für das Überwachungsfahrzeug räumlich noch einholbar ist. Als weiteres, etwas ausführlicheres Beispiel wird am Ende dieses Artikels ein Luftraumüberwachungssystem vorgestellt. Das Thema ist somit auch außerhalb von Forschungseinrichtungen interessant. Das sollte zur Motivation reichen, um Eigenschaften von Echtzeitdatenbanken in diesem Artikel genauer zu untersuchen. Der Rest dieses Artikels gliedert sich wie folgt: Im folgenden Kapitel 2 werden Überlegungen zur Datenkonsistenz und zu Transaktionseingenschaften in Echtzeitdatenbanken angesprochen, gefolgt von Kapitel 3 über eine Betrachtung von zeitlichen Anforderungen. Hier werden auch die oft genannten Prinzipien von Hard Realtime- und Soft Realtime-Anforderungen definiert und erklärt. Nach diesen prinzipiellen Betrachtungen von Echtzeiteigenschaften folgt ein Teil mit Konzepten von Datenbanken, die diese Echtzeiteigenschaften umsetzen. Als erstes wird in Kapitel 4 die architektonische Sonderform von hauptspeicherresidenten Datenbanken betrachtet. Es folgen Kapitel 5 mit einer kurzen Abhandlung über aktive Echtzeitdatenbanken und Kapitel 6 mit einer überblicksmäßigen Beschreibung von verteilten Echtzeitdatenbanken. Kapitel 7 2

3 behandelt das Beispiel eines Luftverkehrsüberwachungssystems und beschließt damit diesen Artikel. 2 Konsistenz und Transaktion in Echtzeitdatenbanken Eine Echtzeitdatenbank muss, wie bereits in der Einleitung erwähnt, nicht nur die Konsistenz der Daten und Transaktionen sicherstellen, sie muss zusätzlich auch zeitliche Eigenschaften von Transaktionen und Konsistenz erfüllen. 2.1 Konsistenz Die Konsistenz der Daten in Echtzeitdatenbanken ist eine andere als die in konventionellen Datenbanken. In einer konventionellen Datenbank genügt es, die logische Konsistenz der Daten sicherzustellen.[3] Logische Konsistenz bedeutet, dass die Daten selbst widerspruchsfrei und damit in einem zulässigen Zustand sind. Dieser zulässige Zustand bleibt durch die Ausführung von Datenänderungen in Transaktionen über die Laufzeit der Datenbank bestehen. In einer Echtzeitdatenbank ist hingegen eine weitere Konsistenz von Bedeutung, und das ist die zeitliche Konsistenz. Diese zeitliche Konsistenz von Daten bezieht sich immer auf einen Zeitpunkt. Daten sind zu diesem Zeitpunkt zeitlich konsistent, wenn sie zu diesem Zeitpunkt gültig sind, das heißt, sie decken sich mit dem Zustand des Anwendungsfeldes. Einfacher gesagt: sie stimmen mit der Wirklichkeit überein. Weil es aber nicht möglich ist, die Datenbank zeitgleich zu jeder Veränderung der Wirklichkeit anzupassen - das würde bedeuten, dass ein Update null Zeiteinheiten benötigen würde - werden Zeitintervalle definiert, in denen die Daten der Datenbank als gültig betrachtet werden. Innerhalb dieses Zeitintervalls ist somit die zeitliche Konsistenz gegeben, nach Ablauf eines solchen Intervalls werden die Daten als zeitlich nicht konsistent betrachtet, bis die Konsistenz durch Vergleich mit dem Zustand des Anwendungsfeldes verifiziert wurde.[4] In einer konventionellen Datenbank wird die zeitliche Konsistenz nicht beachtet, Daten gelten im Allgemeinen bis ein Update erfolgt. Der Begriff der Konsistenz kann auch in interne und externe Konsistenz aufgeteilt werden. Als interne Konsistenz wird der Zustand definiert, in dem die Daten einer Datenbank alle vordefinierten Einschränkungen erfüllt. Das bedeutet auch, dass die Daten der Datenbank für sich wiederspruchsfrei sind. Im Gegensatz dazu ist die externe Konsistenz dann gegeben, wenn die Daten der Datenbank mit dem Zustand der Applikationsumgebung übereinstimmen. Die Datenbank spiegelt somit ihren Ausschnitt aus der realen Welt des Anwendungsfeldes zu einem gegebenen Zeitpunkt wieder.[2] Um die Konsistenz jedweder Ausprägung sicherzustellen, werden entsprechende Transaktionen benötigt. 3

4 2.2 Transaktionen und deren zeitliche Bedingungen Die zeitlichen Beschränkungen einer Transaktion schließen die bereits erwähnte Deadline und auch den Startzeitpunkt und den spätesten Endzeitpunkt einer Transaktion mit ein.[3] Außerdem sind auch periodisch auszuführende Transaktionen möglich.[4] Der Start- und der Endzeitpunkt müssen dann berücksichtigt werden, wenn die Ausführung einer Transaktion durch eine zeitgesteuerte Funktion wie beispielsweise einen Ablaufplan und nicht durch ein einfaches Ereignis angestoßen wird. In einem Steuerungssystem werden diese Zeitpunkte eher wichtig sein als in einem reinen Überwachungssystem. Als Beispiel für periodische Transaktionen kann Polling gelten. Dabei ist zumindest sicherzustellen, dass die Transaktion beendet wird, bevor sie erneut aufgerufen wird. Moderne Datenbanken erlauben es, dass mehrere Benutzer gleichzeitig auf die gespeicherten Daten zugreifen. Damit werden mehrere Transaktionen gleichzeitig ausgeführt, und diese Nebenläufigkeit bringt auch Synchronisisierungsprobleme mit sich. Transaktionen müssen so disponiert werden, dass sie ihre zeitlichen Bedingungen einhalten können. Gleichzeitig muss aber - wie bereits mehrfach erwähnt - die Konsistenz der Daten gewährleistet werden. Das wird durch auf die Echtzeiterfordernisse angepasstes Scheduling gewährleistet. In herkömmlichen Datenbanksystemen reicht die Serialisierbarkeit von nebenläufigen Transaktionen als Kriterium für die korrekte Abarbeitung derselben. Das heißt, dass ein nebenläufiger Ablaufplan für Transaktionen dann korrekt ist, wenn der Datenbankzustand nach Abarbeitung des Ablaufplanes derselbe ist wie der, der bei einer sequenziellen Abarbeitung der Transaktionen entsteht. Dabei wird die Serialisierbarkeit einerseits durch Blockieren und andererseits durch Abbrechen und Neustart von Transaktionen gewährleistet. Allerdings sind sowohl Blockieren als auch Abbrechen von Transaktionen in einer Echtzeitdatenbank nicht wünschenswert und daher sparsam einzusetzen. Blockieren kann eine Transaktion derart verzögern, dass sie ihre Deadline überschreitet, beispielsweise durch Prioritätsinversion, und ein Abbruch erfordert ein neuerliches Ausführen der gesamten Transaktion, wobei die bereits für diese Transaktion eingesetzten Ressourcen als verschwendet zu betrachten sind.[2] Die Scheduling-Schemata, die bei Echtzeitdatenbanksystemen eingesetzt werden, sind meist von Scheduling-Schemata für konventionelle Datenbanksysteme abgeleitet, beispielsweise von Two Phase Locking, optimistischen Scheduling-Schemata oder Multiversions- Schemata. Bei dieser Ableitung wird nicht mehr auf durchschnittliche Antwortzeit oder Durchsatz geachtet wie bei Schemata für herkömmliche Datenbanksysteme, sondern auf Reduktion der maximalen Antwortzeit und damit der Reduktion der Anzahl an Transaktionen, die ihre Deadlines überziehen. Bei abbrechenden Scheduling-Schemata ist es ein möglicher Ansatz, anstelle von Fairness oder Ressourcenverbrauch die verbleibende Zeit der Transaktion bis zum Deadlock (Kritikalität) als Scheduling-Maß zu nehmen.[5] Das damit entstehende Problem der Starvation von lang andauernden Transaktionen könnte durch Einbeziehung einer Mindestausführungszeit jeder einzelnen Transaktion gelöst werden, in dem Sinne, dass die Zeitdifferenz zwischen Deadline und Mindestausführungszeit zum Scheduling herangezogen wird. 4

5 Ein anderer Ansatz ist es, mehrere Kopien der Datenbank bereitzustellen und damit das Scheduling mehrerer Transaktionen zu erleichtern. Damit wird aber das Problem mit erkauft, dass die Daten, auf der eine Transaktion arbeitet, möglicherweise nicht mehr aktuell sind. Sie befinden sich trotzdem in konsistentem Zustand. Wenn eine Transaktion auf ihrer Datenbankkopie schreibt, müssen alle Kopien erneuert werden, zumindest innerhalb eines definierten Intervalls (siehe zeitliche Konsistenz). Der einzige verbleibende Konfliktfall sind parallele Schreiboperationen. Daher ist dieses Multiversioning besonders effizient, wenn die schreibenden Transaktionen kurz und die read-only-transaktionen besonders lang sind.[5] 3 Hard und Soft Realtime Bei der genaueren Betrachtung von Konsistenz und Transaktionen in Echtzeitdatenbanken mag aus Gründen der Einfachkeit der Eindruck entstanden sein, dass alle Echtzeitdatenbanken dieselben Anforderungen an die Transaktionen stellen. Dem ist aber nicht so. In der Literatur werden deshalb Echtzeitdatenbanken oft in zwei verschiedene Kategorien eingeteilt: in Hard Realtime- und in Soft Realtime-Systeme. Wie jeder Einteilung liegt auch dieser eine gewisse Willkür zugrunde und die entstehenden Teilmengen können oft nicht genau voneinander abgegrenzt werden. So ist es möglich, dass in einer Datenbank sowohl Hard- wie auch Soft Realtime-Transaktionen und Transaktionen ohne Echtzeitanforderungen ausgeführt werden müssen. Deshalb werden im folgenden die Charakteristika von Transaktionen und nicht von Systemen betrachtet. 3.1 Hard Realtime Transaktionen, die Hard Realtime-Bedingungen erfüllen, sind Transaktionen, deren Korrektheit allein davon abhängt, ob sie ihre Echtzeitbedingungen einhalten können. Das bedeutet, dass ein Terminieren nach der Deadline wertlos ist und die Daten, die von der Transaktion an die Anwendung zurückgegeben, von dieser nicht mehr verarbeitet werden können. Die Hard Realtime-Transaktionen unterliegen somit strengen zeitlichen Konsistenzkriterien. Durch die Eigenschaft der wertlosen verspäteten Antwort ist bei Hard Realtime-Transaktionen das Augenmerk besonders auf die Erfüllung der Echtzeitanforderungen zu legen. Das kann durch spezielle Scheduling-Schemata erfolgen, durch Abschwächung der Konsistenz oder aber durch Neudesign des Datenbankmanagementsystems. Es gibt zwei Möglichkeiten, ein Hard Realtime-Datenbanksystem durch Scheduling zu unterstützen, entweder durch präventives Scheduling oder durch On The Fly -Scheduling wie in herkömmlichen Datenbanksystemen. Präventives Scheduling kann entweder durch die Verwendung von Schedulingtabellen oder durch Beachtung der Priorität erfolgen. Der Nachteil von präventivem Scheduling ist aber seine Inflexibilität. So müssen alle Transaktionen zum Systemstart bekannt sein. [3] On The- ly -Scheduling kann in Hard Realtime- Datenbanken durch Earliest Deadline First-Scheduling oder Priority Inheritance-Scheduling durchgeführt werden.[2] 5

6 Wenn die Konsistenz der Daten abgeschwächt wird um Echtzeitanforderungen zu erfüllen, so wird auf die Einhaltung der internen Konsistenz dann verzichtet, wenn sie mit der Einhaltung der zeitlichen Anforderungen konfligieren würde. Die externe Konsistenz muss aber immer gegeben sein. Dieses Modell basiert auf der Annahme, dass für die meisten Echtzeitdatenbanksysteme eine rechtzeitige und dem Systemumfeld entsprechende Antwort wichtiger ist als eine vollkommen konsistente aber verspätete. Ein Beispiel für die Anwendung dieses Ansatzes ist ein System zur Verfolgung der Bewegung von identifizierten Objekten. Dabei ist es maßgeblich, immer den aktuellen Standort zu kennen, und alles andere kann nachgeholt werden, wenn das System weniger stark ausgelastet ist.[2] Eine andere Möglichkeit, die Anforderungen von Hard Realtime zu erfüllen, ist es, das Datenbankmanagementsystem neu zu designen, um die Performance zu optimieren. Beispiele dafür sind speicherresidente Datenbanken, also Systeme, die alle Daten im Arbeitsspeicher des Rechners halten, oder Systeme, die direkten Zugriff auf die Daten erlauben und die Kommunikation nicht als Netzwerkkommunikation unter Verwendung des IP-Protokolls abwickeln. Damit wird es zwar schwieriger, klassische One-Server-Multi-Clients-Systeme zu entwickeln, aber es spart Kommunikationsaufwand und damit Zeit. Hauptspeicherresidente Datentenbanken werden im Abschnitt 4 näher behandelt. 3.2 Soft Realtime Transaktionen, die Soft Realtime-Bedingungen erfüllen, sind Transaktionen, die - im Unterschied zu Hard Realtime-Transaktionen - wie herkömmliche Transaktionen immer vollständig ausgeführt werden, egal, ob sie die zeitlichen Bedingungen erfüllen oder nicht. Natürlich sind auch diese Transaktionen darauf ausgelegt, die Echtzeitbedingungen zu erfüllen, aber die Ausführung der Transaktion ist gleich wichtig wie die Einhaltung dieser Zeitbeschränkungen. Und die Ausführung der Soft Realtime-Transaktion ist umso erfolgreicher, je öfter die Echtzeitbedingungen eingehalten werden. Das Anwendungssystem ist jedenfalls darauf angewiesen, immer Daten von der Transaktion zurückzubekommen. Natürlich sind die Daten umso wertvoller, je seltener die Deadlocks überschritten werden.[2] Die Bezeichnung Soft Realtime verführt dazu anzunehmen, dass die zeitlichen Einschränkungen nicht besonders wichtig seien, was aber eine falsche Annahme darstellt. Deutlich wird dies dadurch, dass Soft Realtime-Transaktionen oft in Überwachungssystemen vorkommen. Dabei ist es natürlich wichtig, jeden gravierenden Fehlerfall zu melden, und die Meldung muss es dem System oder dessen Benutzer ermöglichen, rechtzeitig auf die Störung zu reagieren. Scheduling in Soft Realtime-Systemen geschieht meist in einer Anpassung von existierenden Scheduling-Systemen von konventionellen Datenbanken. Beispiele dafür sind Priority Inheritance und Priority Abort. Priority Inheritance reduziert die Zeit, die eine Transaktion maximal durch eine andere geblockt wird, weil die blockierende Transaktion mit höherer Priorität als die blockierte ausgeführt wird und damit schneller terminiert. Trotzdem ist es möglich, dass hochprioritäre Transaktionen ihre Deadlines überziehen, weil die niedrigprioritäre, aber bereits eine Sperre haltende Transaktion nur mit der höchsten Priorität der aktuellen Transaktionen ausgeführt wird. Bei Priority Abort kann eine höherprioritäre Transaktion eine sie blockierende niederprioritäre Transaktion abbrechen. Das 6

7 bedeutet aber, dass die für die Ausführung der niederprioritären Transaktion eingesetzten Ressourcen verschwendet sind. Besonders gravierend ist dies, wenn die niederprioritäre Transaktion bereits weit fortgeschritten ist.[2][3] Auch ein Redesign des Datenbankmanagementsystems kann bei Soft Realtime-Systemen helfen, die zeitlichen Anforderungen an die Transaktionsausführung einzuhalten. Diese Bemühungen um Redesign können zusammen mit geänderten Marktbedingungen bei Hardwarebausteinen bis zu neuen Designkonzepten führen, die bislang als nicht realisierbar galten. Ein prägnantes Beispiel dafür ist das Konzept der hauptspeicherresidenten Datenbanken. 4 Hauptspeicherresidente Datenbanken Konventionelle Datenbanken, auch oft Datenbanken mit Echtzeitkomponenten, halten die Daten auf der Festplatte des Rechners. In Hauptspeicherdatenbanksystemen (Main Memory Database Systems, MMDB) hingegen befinden sich die Daten permanent im physikalischen Hauptspeicher, also dem Arbeitsspeicher des Rechners. In den konventionellen Datenbanksystemen können die Daten natürlich im Arbeitsspeicher gechacht werden, um geringere Zugriffszeiten auf öfter benötigte Daten zu erlauben, und in hauptspeicherresidenten Datenbanken können die Daten auch ein Backup auf der Festplatte besitzen. Der Hauptunterschied zwischen diesen beiden Datenbanksystemen ist, dass in einer MMDB die Daten permanent im Hauptspeicher gehalten werden. Und hat wichtige Auswirkungen darauf, wie die Daten strukturiert werden und wie auf sie zugegriffen wird. Der Einsatz von Hauptspeicher zur Datenhaltung bringt nicht nur einen signifikanten Performancegewinn durch kürzere Zugriffszeiten auf die einzelnen Datensätze und daher auch durch kürzere Transaktionslaufzeiten, ein Hauptspeicher hat mehrere Eigenschaften, die sich von denen der Festplatten unterscheiden. Diese Eigenschaften werden - obwohl größtenteils bekannt - in der folgenden Aufzählung kurz behandelt: 1. Die Zugriffszeit auf den Hauptspeicher ist um Zehnerpotenzen geringer als die auf Festplattenspeicher. 2. Der Hauptspeicher ist normalerweise flüchtig, während dies Festplattenspeicher nicht ist. 3. Platten haben hohe Fixkosten für jeden Zugriff, und diese Kosten hängen nicht von der Menge der transferierten Daten ab. Daher sind Festplatten blockorientierte Speicher. Der Hauptspeicher ist nicht blockorientiert. 4. Die Anordnung der Daten ist auf einer Festplatte kritischer als im Hauptspeicher, weil ein sequentieller Zugriff bei einer Festplatte schneller ist als ein wahlfreier. Beim Zugriff auf den Hauptspeicher ist dieser Unterschied nicht feststellbar, weil sich ein sequentieller Zugriff im Arbeitsablauf gleich darstellt wie ein wahlfreier. 7

8 5. Der Hauptspeicher ist normalerweise direkt vom Prozessor aus zugreifbar, die Festplatte nicht. Daher reagieren die Daten am Hauptspeicher empfindlicher auf Softwarefehler als die Daten auf einer Festplatte. Diese unterschiedlichen Eigenschaften der beiden Speichermedien schlagen sich natürlich auf das Design des Datenbanksystems nieder, und zwar in beinahe jedem Aspekt des Datenbankmanagements. Können aber alle Daten einer Datenbank im Arbeitsspeicher gehalten werden? Das ist bei manchen Applikationen mit geringem Datenvolumen möglich, bei anderen Applikationen fällt die Möglichkeit einer Hauptspeicherdatenbank aus diesem Grund aus der Liste der Alternativen heraus. Bei manchen Echtzeitsystemen können die Deadlines nur dann eingehalten werden, wenn die Daten im Hauptspeicher liegen. Hier ist zu beachten, dass das Design der Datenfelder auf die beschränkten Ressourcen besondere Rücksicht nimmt. Denn in einem solchen Fall müssen alle Daten in den Hauptspeicher des Rechners passen. 4.1 Aufteilung der Datenbank Nicht alle Daten einer Datenbank müssen für die Erfüllung von strikten Echtzeitkriterien gleich wichtig sein. Wenn diese Situation gegeben ist, müssen die Daten in mehrere Klassen eingeteilt werden, zumindest in sogenannte heiße und kalte Daten. Die Menge der heißen Daten ist normalerweise überschaubar, auf sie wird oft zugegriffen und diese Zugriffe unterliegen strengen Echtzeitkriterien. Kältere Daten werden weniger oft benötigt und die Echtzeitkriterien ihrer Zugriffe sind weniger streng. Durch diese Partition der Daten kann auch die Datenbank in mehrere logische Teile zerlegt, und nur die heißen Daten müssen im Hauptspeicher liegen, während die kälteren Daten auf der Festplatte abgelegt werden können. Damit spielt auch ihr Umfang eine geringe Rolle. Kritische Daten sollen somit im Hauptspeicher gehalten werden. Das schaffen durch das Caching auch konventionelle auf Festplatte speichernde Datenbanksysteme, sofern der Hauptspeicher groß genug ist. Obwohl solche Systeme recht gute Performance erzielen, nützen sie die Vorteile des Hauptspeichers nicht zur Gänze aus. So sind die Datenblöcke für eine schnelle Verfügbarkeit auf der Festplatte ausgelegt. Das bedingt komplexe Datenstrukturen wie etwa B-Bäume. Der Datenzugriff erfolgt immer über den Buffer-Manager. Dabei wird immer die Speicheradresse des Blocks auf der Festplatte berechnet und danach geprüft, ob der Block sich gerade im Hauptspeicher befindet. Dieser wird dort gefunden, und der gesuchte Datensatz wird in einen Buffer gelesen, sodass er gleich zugreifbar ist wie konventionelle Daten im Hauptspeicher. Dieser Aufwand ist deshalb unnötig, weil sich die Daten bereits im Hauptspeicher befinden. Wenn die Datenbank darauf ausgelegt ist nur auf Daten zuzugreifen, die ausschließlich im Hauptspeicher liegen, reicht ein Zugriff auf die entsprechende Speicheradresse wie bei normalen Files. 8

9 4.2 Hardwarespezifische Probleme bei hauptspeicherresidenten Datenbanken Ein leicht ersichtliches Problem beim Entwurf einer hauptspeicherresidenten Datenbank stellt die Flüchtigkeit des Speichermediums dar. Wenn der Strom abgeschaltet wird, entfallen auch die Auffrischungszyklen, welche die aktuelle Ladung jeder Speicherzelle erneuert. Dadurch verschwinden die Daten des Speichers und damit auch der Datenbank. Die hardwareseitige Lösung des Problems liegt nahe: der Speicher muss kontinuierlich mit Strom versorgt werden, um bei Systemabschaltungen oder Systemabstürzen und anschließenden Neustarts nicht die gesamten Daten der Datenbank zu verlieren. Die Sicherheit dieser Maßnahmen liegt aber unter der einer Festplatte, gemäß des Grundsatzes, dass alle Komponenten eine gewisse Ausfallswahrscheinlichkeit besitzen. Eine Möglichkeit, das Problem der unterbrechungsfreien Stromversorgung zu umgehen ist der Einsatz von nichtflüchtigem Speicher wie EEPROM oder Flash. Abgesehen von den dadurch auftretenden Kosten muss erwähnt werden, dass diese Technologien eine höhere Zugriffszeit als der weit verbreitete und relativ billige Arbeitsspeicher aus RAM-Bausteinen besitzen. 4.3 Auswirkungen von hauptspeicherresidenten Daten auf Transaktionen Weil der Zugriff auf den Arbeitsspeicher so viel schneller ist als ein Zugriff auf die Festplatte, kann erwartet werden, dass Transaktionen in hauptspeicherresidenten Datenbanken entsprechend schneller terminieren. Daher werden die Sperren, die das Transaktionsmanagement vergibt, früher gelöst. Somit scheint es, dass die Verzögerungen durch solche Sperren nicht mehr so wichtig seinen. Der Einfluss der Nebenläufigkeit auf eine einzelne Transaktion scheint sich also zu minimieren. Wenn nun eine Sperre eine Transaktion anhält, so muss der Prozessor auf den Prozess einer anderen Transaktion umsteigen. Dieser Prozesswechsel verbraucht viele Kalkulationszyklen, und aufgrund der reduzierten Speicherzugriffszeiten in hauptspeicherresidenten Datenbanksystemen fallen diese Prozesswechsel umso stärker ins Gewicht. Idealerweise müsste, um den Rechner optimal auszunutzen, die Nebenläufigkeit bis auf serielle Abarbeitung reduziert werden, was aber vor allem bei lang andauernden Transaktionen wie Geschäftsprozessen nicht möglich ist. Der Vorteil feingranularem Sperrens von Daten wird in jedem Fall durch den Prozesswechsel aufgefressen. Obwohl bei hauptspeicherresidenten Datenbanken die Daten im Hauptspeicher lagern und nur ein Backup auf der Festplatte, muss ein Logfile auf einem persistenten Medium gehalten werden, da ein Logfile gerade dann benötigt wird, wenn eine Datenbank nach einem Systemausfall wiederhergestellt werden muss. Vor Beendigung jeder Transaktion muss dieses Logfile aktualisiert werden, und das bedeutet einen Festplattenzugriff, der im Fall einer Schreibsperre durch eine konkurrierende Transaktion den Vorteil einer hauptspeicherresidenten Datenbank zunichte machen kann. Um dieses Problem zu lösen, wurden mehrere Verfahren entwickelt, drei davon sollen hier kurz erwähnt werden. 9

10 1. Teilpersistenter Arbeitsspeicher: Logdaten sind verhältnismäßig klein. Daher kann es einen vertretbaren Aufwand darstellen, einen Teil des Logfiles auf schnellem persistenten Speicher wie Flash zu halten. Dieser Teil wird naturgemäß der aktuellste Teil des Logs sein, und so muss beim Commit einer Transaktion nur auf den persistenten Teil des Arbeitsspeichers geschrieben werden. Das Übertragen auf die Festplatte kann dann in Phasen niedriger Datenbankauslastung erfolgen. 2. Pre Committing: Ähnlich verhält es sich mit dem Pre-Committing. Dabei wird eine Transaktion als abgeschlossen betrachtet, wenn der entsprechende Datensatz des Logfiles auf den Hauptspeicher geschrieben wurde. Danach können alle Sperren freigegeben werden, und nachfolgende Transaktionen werden nicht verzögert. Während nun die nächste Transaktion läuft, wird das Logfile auf der Festplatte mit dem Datensatz aus dem Hauptspeicher vervollständigt. Bei diesem Ansatz wird nicht die Antwortzeit der aktuellen Transaktion verkürzt, es werden nur die Sperren früher freigegeben und damit möglicherweise die Laufzeit der nachfolgenden Transaktionen verkürzt. 3. Group Commit: Group Commit setzt wiederum die Idee des Pre Committing fort, indem nicht jeder Logeintrag sofort auf die Festplatte geschrieben wird, sondern gewartet wird, bis eine gewisse Anzahl an Logeinträgen im Hauptspeicher vorliegen, die dann in einem Festplattenzugriff persistent gemacht werden. Das hier entstehende Risiko ist natürlich, dass Transaktionen, für die das Anwendungsprogramm bereits ein Commit erhalten hat, genau dann bei einem Systemcrash verloren gehen, wenn sich ihre Logeinträge noch im Arbeitsspeicher befinden. Der Vorteil davon ist aber, dass viele Festplattenzugriffe und damit auch Rechenoperationen eingespart werden können. Die Anzahl der Rechenoperationen erhält in hauptspeicherresidenten Datenbanksystemen die Bedeutung der maßgebenden Performancekennzahl, weil die verhältnismäßig enormen Zugriffszeiten auf Festplatten wegfallen. Damit werden sämtliche Bemühungen zur Reduktion der Datenzugriffe obsolet, ebenso das Clustering und die Einführung von flachhierarchischen Datenstrukturen. Der Preis dafür ist allerdings die höhere Verletzlichkeit der Daten und die Erfordernis, dass nach einem Absturz des Datenbanksystems alle Daten aus dem Backup und dem Log wiederhergestellt und neuerlich in den Hauptspeicher geladen werden müssen. Hauptspeicherresidente Datenbanken haben den Sprung vom akademischen Konzept zu fertigen Implementierungen geschafft. Beispiele dafür sind die Systeme Coral von der University of Wisconsin-Madison als Vertreter der akademischen Projekte und IMS/VS von IBM als kommerzielles Programm. Eine teilweise Umsetzung der Konzepte findet sich im System TimesTen von Oracle.[6] [7] 10

11 5 Aktive Echtzeitdatenbanken Wenn Applikationen eine automatische Überwachung des Zustandes ihrer Systemumgebung gewährleisten müssen und auf auftretende Ereignisse effizient reagieren müssen, wird eine aktive Datenbank benötigt. Und wenn diese Reaktionen auch zeitliche Bedingungen stellen, so muss ein aktives Echtzeitdatenbanksystem mit der Verwaltung und Manipulation der Daten betraut werden. Ein kurzer Einblick in die Charakteristika eines solchen aktiven Echtzeitsystems soll in diesem Abschnitt gewährt werden.[8] Aktive Datenbanksysteme haben, wie bereits erwähnt, nicht nur die Aufgabe, Daten zu speichern, sie sollen die Daten auch verändern, wenn sie durch Veränderungen der Umwelt oder durch Verändern der gespeicherten Daten dazu angehalten werden. Diese Datenveränderungen werden mittels gespeicherter Prozeduren, den sogenannten Triggern, durchgeführt.[8] Ein erster Ansatz, einer aktiven Datenbank Echtzeitbedingungen beizubringen, war das HiPAC-Projekt [9]. Hier wurde vorgeschlagen, den einzelnen Triggern Zeitbeschränkungen mitzugeben. So wird im auszuführenden Code explizit angegeben, wie lange diese Ausführung maximal dauern darf. Eine Reaktion auf überzogene Deadlines war, von Timeout-Warnungen abgesehen, noch nicht vorgesehen. Aber die Sensibilität für das Problem der aktiven Echtzeitdatenbanken war geweckt. Veränderungen der Umwelt werden durch ein Datenbanksystem dann aktiv erkannt, wenn es periodisches Polling durchführt. Dies wird normalerweise zur Erkennung von wiederkehrenden und daher im Eintreffen voraussehbaren Umweltveränderungen eingesetzt. Durch dieses Polling wird die externe Konsistenz überwacht und gegebenenfalls wiederhergestellt. Wenn dieser Ansatz zur Überwachung der internen Konsistenz herangezogen wird, so ist zu beachten, dass sich die Datenbank zwischen zwei der periodischen Prozeduraufrufen durchaus in einem intern inkonsistenten Zustand befinden kann. Die andere Möglichkeit, Daten durch eine aktive Datenbank ändern zu lassen ist der Aufruf eines Triggers durch eine Transaktion, wobei hier der Trigger integrales Element der Transaktion ist. Die Transaktion darf also während der Laufzeit des Triggers noch nicht als ausgeführt angesehen werden. Insbesondere ist ein Commit während der Ausführung eines solchen Triggers als besonders risikoreich anzusehen. Trigger sind bei aktiven Datenbanken sehr weit verbreitet und stellen auch bei aktiven Echtzeitdatenbanken die Regel dar.[2] Überlastungen des Datenbanksystems treten bei solchen event-getriggerten Systemen weitaus häufiger auf als bei den zeitgetriggerten Polling-Systemen, bei denen die Triggerausführungen leichter planbar sind. Bezüglich der Flexibilität ist umgekehrt ein eventgetriggertes System im Vorteil. Sie ist hier deshalb größer, weil durch einen Trigger durchaus neue Transaktionen aufgerufen werden können. Bei rein zeitgetriggerten Systemen ist das nicht möglich. In Hard Realtime-Systemen werden daher - sofern möglich - eher zeitgetriggerte Verfahren eingesetzt, weil die höhere Flexibilität beim event-getriggerten Ansatz schwerer abzuschätzen ist. Generell ist es jedoch ein Scheduling-Problem, welches bei aktiven Echtzeitdatenbanksystemen auftritt. Um dies lösen zu können, muss jedem Trigger seine Deadline ebenso mitgegeben werden wie die Information, ob diese Deadline hard-realtime oder soft-realtime ist. 11

12 Der Scheduler muss in weiterer Folge dafür sorgen, dass Trigger gemäß ihren Echtzeitanforderungen ausgeführt werden.[8] Dabei unterscheiden sich Trigger insofern von Transaktionen, als dass einer oder mehrere Trigger eine Transaktion formen können und sich daher Abhängigkeiten bezüglich der rechtzeitigen Ausführung ergeben. Es nützt wenig, einen Trigger, der bereits als besonders kritisch angesehen wird, auszuführen, wenn er Teil einer Hard Realtime-Transaktion ist und ein Nachfolgetrigger derselben Transaktion nicht mehr vor der Deadline der Transaktion beendet werden kann. Somit werden für das sichere Erkennen der Kritikalität eines Triggers zusätzliche Informationen benötigt. Je nach Anwendungsgebiet kann es möglich sein, das Scheduling-Problem zu entschärfen, indem in Zeiten hoher Arbeitsbelastung des Systems konsistenzbewahrende Trigger hintangestellt werden. Das ist natürlich nur dann möglich, wenn entweder interne oder externe Konsistenz allein ausreichen, damit das System akzeptable Ergebnisse liefert, und es dem Scheduler ersichtlich ist, welcher Trigger konsistenzbewahrend und welcher ergebnisproduzierend ist. Ein solches verzögertes Ausführen der Trigger ist eher in zeitgetriggerten Systemen möglich.[2] Im abschließenden Kapitel 7 wird die Funktionsweise aktiver Echtzeitdatenbanksysteme im Einsatz zur Luftraumüberwachung näher vorgestellt. Gerade Überwachungsaufgaben werden gerne mittels aktiven Echtzeitdatenbanken realisiert. 6 Verteilte Echtzeitdatenbanken Verteilte Datenbanksysteme sind bei Echtzeitanwendungen weit verbreitet, besonders bei Systemen mit strengen Performance-Anforderungen bezüglich Antwortzeit und Robustheit gegenüber Hardwareausfällen. Beispiele für solche verteilte Datenbanksysteme sind Telekommunikationsdatenbanken und Datenbanken zum Betrieb von Webapplikationen wie beispielsweise für Electronic Commerce. Die Performance von Leseoperationen, die Verlässlichkeit und Verfügbarkeit solcher Applikationen kann durch solche verteilten Echtzeitdatenbanken signifikant verbessert werden.[3] Replizierte Datenkopien werden bei verteilten Datenbanken redundant an mehreren Orten gespeichert, wodurch ein Datenzugriff auch dann möglich ist, wenn eine oder mehrere dieser Kopien durch einen Fehler ausfallen. Außerdem kann durch eine verteilte Datenbank bei Zugriff über ein Netzwerk die nächste Kopie der Datenbank verwendet werden, oder gleich eine lokale Kopie. Das bewirkt den Performancegewinn bei Lesezugriffen in verteilten Datenbanken, und daher auch bei verteilten Echtzeitdatenbanken. Obwohl die Datenreplikation manche Vorteile birgt, führt sie auch zu Problemen. Der Zugriff auf die Daten wird nicht mehr von einer einzelnen Instanz überwacht, stattdessen ist die Zugriffskontrolle auf alle jene Teilsysteme verteilt, die Kopien des jeweiligen Datensatzes besitzen. Dadurch wird es nötig zu überwachen, ob die einzelnen Kopien der Daten konsistent zueinander sind. Diese Art der Konsistenz wird Mutual Consistency genannt. Anders gesagt, die einzelnen Instanzen der Daten müssen deckungsgleich sein, also sich genau wie eine einzelne Instanz verhalten. Um dies möglich zu machen, müssen konfligie- 12

13 rende Zugriffe auf den selben Datensatz in verschiedenen Kopien vermieden werden. Auch muss sichergestellt werden, dass alle Kopien alle Updates erhalten.[2] Das Weiterverbreiten eines jeden Updates ist eine schreibende Transaktion auf jeder Kopie, also muss auf jeder Kopie ein Write Lock gesetzt werden. Natürlich können verschiedene Kopien der Datenbank parallel aktualisiert werden. Wie die einzelnen Updates ausgeführt werden, hängt wieder einmal von der Updatestrategie ab und kann als Lösung des Serialisierbarkeitsproblems verstanden werden. Hier einsetzbare Strategien sind unter anderem Earliest Deadline First, Optimistic Concurrency Control, Priority Inheritance, Priority Abort oder Priority Ceiling.[5] Diese Strategien arbeiten lokal auf einer Datenbankkopie, sie stellen sicher, dass bereits als Transaktionen bekannte weitergeleitete Updates richtig scheduliert ausgeführt werden. Ob die Mutual Consistency eingehalten werden muss und wie streng die Regeln dafür sind, das heißt, ob ein Update sofort zu allen Kopien der Daten weitergeleitet werden muss oder bis wann das zu geschehen hat, bestimmen die Anforderungen des Anwendungsgebiets. Denn die Echtzeitkriterien müssen selbstverständlich auch bei verteilten Echtzeitdatenbanken eingehalten werden. Dabei ist es wichtig zu beachten, dass ein Update der verteilten Datenbankkopien nicht nur die Zeit des Updates selbst beansprucht, auch die Übertragungszeit der Daten über das Netzwerk muss zur Ausführungszeit hinzugerechnet werden. Der zusätzliche Aufwand eines schreibenden Datenbankzugriffs steht somit der Performanceverbesserung bei Lesezugriffen entgegen. Entsprechend eignen sich besonders Datenbanken mit verhältnismäßig wenigen schreibenden Transaktionen oder Systeme mit der Anforderung hoher Verfügbarkeit für diese Organisationsform einer Echtzeitdatenbank. 7 Beispiel: System zur Luftverkehrsüberwachung Dieses Beispiel ist entnommen aus: C.-S. Peng, K.J. Lin, T.P. Ng, A performance study of the semantic-based concurrency control protocol in air traffic control systems, in A. Bestavros, V. Fay-Wolfe Real-time databse and information systems, Kluwer Academic Publishers, 1997, S Luftverkehrsüberwachungssysteme variieren bedeutend in Größe und Komplexität, je nachdem, wie groß der Luftraum ist, der überwacht werden soll. Große Luftverkehrsüberwachungssysteme sind ein verteiltes System, welches aus duzenden Servern und Workstations bestehen kann und über ein LAN verbunden ist. Die Server interagieren mit externen Systemen wie Radars, Wetterinformationsquellen (normalerweise Informationssysteme) und andere Luftverkehrsüberwachungssysteme. Eine große Anlage kann mit duzenden Radaranlagen verbunden sein, tausende Flüge und Flugpläne gleichzeitig behandeln. Jeder Radar ist in der Lage, 100 bis 200 Meldungen pro Scan an das Überwachungssystem zu liefern. Dabei ist aber zu prüfen, welche Objekte diesen Meldungen zugrunde liegen, denn Radaranlagen haben überlappende Überwachungsgebiete und nicht alle Objekte auf dem Radarschirm sind Flugzeuge. Die Server bieten eine Vielfalt an Funktionen. Manche davon verarbeiten Radardaten und bilden die Kurse der erfassten Flugzeuge. Manche vergleichen die Kurse mit den 13

14 gespeicherten Flugpläne. Manche speichern Daten in offline-gehaltenen Medien, um sie später zu analysieren. Manche berechnen Flugbahnen voraus, um eine Frühwarnfunktion bereitzustellen. Manche überwachen und steuern andere Computer, Netzwerke und externe Interfaces. Die Workstations des Luftraumüberwachungssystems zeigen relevante Daten (beispielsweise Flugziele, Flugrouten, Warnungen, Wetter) an einem großen Display für menschliche Benutzer an. Typischerweise zeigt jede Workstation nur eine Teilmenge der Daten an, und zwar diejenige Region des Luftraumes, die von dem Aufseher kontrolliert wird, der diese Workstation benutzt. 7.1 Systemmodell Unter den vielen Komponenten eines Luftverkehrsüberwachungssystems befinden sich zwei Datenbanken. Eine davon ist die Datenbank für Ziele und Kurse (Target and Track Database, TDB), und die andere ist die Datenbank für die Anzeige (display database, DDB). Für jedes erkannte Ziel (beispielsweise ein Flugzeug) wird ein Kurs erzeugt und aktuell gehalten. Jeder Kurs wird als Objekt in der TDB gespeichert, während der entsprechende Datensatz für ein Anzeigeobjekt ein davon abgeleitetes Objekt ist und in der DDB gespeichert wird. Es gibt außerdem einen Strom externer Updatetransaktionen, welche die durch Sensoren wie Radar festgestellten Kurse (Tracks, daher TRK) in die TDB einschreibt. Eine Zusammenstellung von Anzeigetransaktionen (Display Transactions, DIS) greift lesend die TDB zu, um die Kurse sowohl sowohl anzuzeigen als auch in die DDB einzufügen. Außerdem lesen Transaktionen zur Erkennung von taktischen Alarmen (Alarm Detection Transaction, ALE) in der TDB und setzt die so gewonnenen Daten in Beziehung mit den Daten in der DDB um eine gefährliche Situation zu erkennen und einen Alarm auszulösen. Wenn ein solcher Alarm ausgelöst wird, zeigt ALE den Alarm in einem auffälligen Format auf eigenen Monitoren an. 7.2 Interaktionen zwischen TRK, DIS und ALE Jede TRK ist ein periodischer Job, wobei die Periodenlänge von der Radarscanfrequenz bestimmt wird. Der Abschluss einer TRK innerhalb einer Periode triggert eine DIS, welche die aktualisierten geometischen Informationen über das überwachte Flugobjekt auf den Monitoren anzeigt. Der Abschluss einer DIS aktiviert wiederum eine ALE, um die Warnzustände zu erkennen. Wenn ein neues Flugobjekt vom Radar entdeckt wird und somit ein neuer TRK-Job entsteht, kreiert er ein neues Kursobjekt mit einer neuen Identifikationsnummer. Diese Identifikationsnummer wird in weiterer Folge konsistent durch die TRKs und DISs sowohl in der TDB als auch in der DDB verwendet. 7.3 Zeitliche Requirements Der Transaktionsscheduler benutzt die Earliest-Deadline-First-Policy. Diese Policy soll helfen, die Anzahl der Transaktionen, welche die Deadline überziehen, zu minimieren. 14

15 Jede TRK hat eine harte Deadline, welche gleichzeitig das Ende der Periode markiert. Jede unvollständige Ausführung einer TRK wird bei Erreichen der Deadline abgebrochen, es wird eine neue TRK gestartet. Jede DIS besitzt eine weiche Deadline, wobei die Deadline der DIS noch in der Periode der TRK liegt. Der Sinn davon liegt im Sicherheitsinteresse - der Benutzer muss das Flugobjekt rasch am Überwachungsmonitor aufscheinen sehen. Eine ALE hat ebenso eine weiche Deadline, welche ebenfalls das Ende der aktuellen TRK- Periode darstellt. In Zeiten hoher Auslastung ist es möglich, die Anzeige der aktuellen Positionen der Flugobjekte zu unterdrücken und und somit einerseits durch den Abbruch der DIS Zeit zu sparen und andererseits dem Benutzer eine stabilere, nicht hektisch flimmernde Anzeige zu bieten. Die ALE zur Erkennung von kritischen Zuständen muss aber trotzdem ausgeführt werden, und in gewissen zeitlichen Abständen muss garantiert sein, dass eine DIS die Anzeige aktualisiert. Diese Strategie der abgebrochenen DIS wird als weniger störend empfunden als dauernd zu spät eintreffende Warnungen, weil die ALE nicht mehr in der Lage ist, ihr Ergebnis zeitgerecht zu produzieren und zeitgerecht zu terminieren.[10] Soweit ein kurzer Überblick über die Architektur und Arbeitsweise eines nichttrivialen Echtzeitdatenbanksystems. Damit ist auch dieser kurze Überblick über Echtzeitdatenbanksysteme beendet. Literatur [1] R. Elmasri, S.B. Navathe, Fundamentals of Database Systems, Addison-Wesley, Reading, Massachusetts, [2] Ö. Ulusoy, Current Research on Real-Time Databases, IEEE SIGMOD RECORD, Vol. 21, No. 4, Dezember [3] K. Ramamritham, S.H. Son, L.C. Dipippo, Real-Time Databases and Data Services, Real-Time Systems 28, Kluwer Academic Publishers, 2004 [4] J.A. Stankovic, S. Son, J. Hansson, Misconceptions about Real-Time Databases, IEEE Computer, Volume 32, Issue 6, Juni 1999 [5] P.S. Yu, K.-L. Wu, On Real-Time Databases: Concurrency Control and Scheduling, Proceedings of the IEEE, Volume 82, Issue 1, Jänner 1994 [6] H. Garcia-Molina, K. Salem, Main Memory Database Systems: An Overview, IEEE Transactions on Knowledge and Data Engineering, Vol. 4, No. 6, December 1992 [7] Oracle TimesTen In-Memory Database: Architectural Overview, Release 6.0, 2006, 15

16 [8] M. Berndtsson, J. Hansson, Issues in Active Real-Time Databases, M. Berndtsson, J. Hansson (Ed.), Active and Real-Time Database Systems, Proceedings of the First International Workshop on Active and Real-Time Database Systems, Skövde, Sweden, 9-11 June 1995, Springer Verlag, London, 1996 [9] U. Dayal, B. Blaustein, A. Buchmann, U. Chakravarthy, M. Hsu, R. Ledin, D. McCarthy, A. Rosenthal, S. Sarin, M.J. Carey, M. Livny, R. Jauhari, The HiPAC Project: Combining Active Databases and Timing Constraints, ACM SIGMOD RECORD, Vol. 17, No. 1, März 1988 [10] C.-S. Peng, K.J. Lin, T.P. Ng, A performance study of the semantic-based concurrency control protocol in air traffic control systems, in A. Bestavros, V. Fay-Wolfe Real-time databse and information systems,kluwer Academic Publishers, 1997, S