Gottfried Weiss

Größe: px
Ab Seite anzeigen:

Download "Gottfried Weiss 0160040 gweiss@edu.uni-klu.ac.at"

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

Darunter versteht man die Anmeldung eines Benutzers beim System unter Angabe einer Benutzererkennung.

Darunter versteht man die Anmeldung eines Benutzers beim System unter Angabe einer Benutzererkennung. Datenmanagement 60 5 Datenschutz und Datensicherheit 5.1 Datenschutz Wer wird hier geschützt? Personen Ein anderer Begriff für Datenschutz ist Zugriffskontrolle. Datenschutz soll sicherstellen, dass alle

Mehr

Wiederherstellung (Recovery)

Wiederherstellung (Recovery) Fragestellungen Aufgaben der Komponenten für das Recovery: Sicherstellung der Dauerhaftigkeit der gespeicherten Daten, d.h. Daten, die in einer Transaktion einmal bestätigt wurden (commit), bleiben auch

Mehr

Datenintegrität und Transaktionskonzept

Datenintegrität und Transaktionskonzept und Transaktionskonzept 1. / Datenkonsistenz 1 Mögliche Gefährdung der : Missachtung von Konsistenzbedingungen ("Semantische Integrität") Inkorrekte Verweise auf Datensätze in verschiedenen Tabellen ("Referentielle

Mehr

1 Transaktionen in SQL. 2 Was ist eine Transaktion. 3 Eigenschaften einer Transaktion. PostgreSQL

1 Transaktionen in SQL. 2 Was ist eine Transaktion. 3 Eigenschaften einer Transaktion. PostgreSQL 1 Transaktionen in SQL Um Daten in einer SQL-Datenbank konsistent zu halten, gibt es einerseits die Möglichkeit der Normalisierung, andererseits sog. Transaktionen. 2 Was ist eine Transaktion Eine Transaktion

Mehr

View. Arbeiten mit den Sichten:

View. Arbeiten mit den Sichten: View "individuelle Sicht" (vgl. 3-Schichten-Modell) virtuelle Tabellen: in der DB wird nicht deren Inhalt, sondern nur die Ableitungsregel gespeichert. Arbeiten mit den Sichten: Anfragen: kein Problem.

Mehr

Literatur und Quellen. Datenbanken. Inhalt. Inhalt. Transaktionen. Nikolaus Augsten. Wintersemester 2013/14

Literatur und Quellen. Datenbanken. Inhalt. Inhalt. Transaktionen. Nikolaus Augsten. Wintersemester 2013/14 Literatur und Quellen Datenbanken Nikolaus Augsten nikolaus.augsten@sbg.ac.at FB Computerwissenschaften Universität Salzburg Wintersemester 2013/14 Lektüre zu den Themen : Kapitel 9 () aus Kemper und Eickler:

Mehr

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem Fachbericht zum Thema: Anforderungen an ein Datenbanksystem von André Franken 1 Inhaltsverzeichnis 1 Inhaltsverzeichnis 1 2 Einführung 2 2.1 Gründe für den Einsatz von DB-Systemen 2 2.2 Definition: Datenbank

Mehr

Synchronisierung von Transaktionen ohne Sperren. Annahme: Es gibt eine Methode, zu erkennen, wann eine Transaktion die serielle Ordnung verletzt.

Synchronisierung von Transaktionen ohne Sperren. Annahme: Es gibt eine Methode, zu erkennen, wann eine Transaktion die serielle Ordnung verletzt. OPTIMISTIC CONCURRENCY CONTROL Synchronisierung von Transaktionen ohne Sperren. Annahme: Es gibt eine Methode, zu erkennen, wann eine Transaktion die serielle Ordnung verletzt. Abbruch einer Transaktion

Mehr

Transaktionsverwaltung

Transaktionsverwaltung Transaktionsverwaltung VU Datenbanksysteme vom 21.10. 2015 Reinhard Pichler Arbeitsbereich Datenbanken und Artificial Intelligence Institut für Informationssysteme Technische Universität Wien Transaktionsverwaltung

Mehr

Kapitel 2 Transaktionsverwaltung

Kapitel 2 Transaktionsverwaltung LUDWIG- MAXIMILIANS- UNIVERSITY MUNICH DEPARTMENT INSTITUTE FOR INFORMATICS DATABASE Skript zur Vorlesung: Datenbanksysteme II Sommersemester 2014 Kapitel 2 Transaktionsverwaltung Vorlesung: PD Dr. Peer

Mehr

Synchronisation in Datenbanksystemen in a nutshell

Synchronisation in Datenbanksystemen in a nutshell Synchronisation in Datenbanksystemen in a nutshell 1. Modell für nebenläufige Transaktionen und Korrektheitskriterium Transaktionsmodell: Folgen von Lese und Schreiboperationen abgeschlossen durch c=commit.

Mehr

Verteilte Systeme - 5. Übung

Verteilte Systeme - 5. Übung Verteilte Systeme - 5. Übung Dr. Jens Brandt Sommersemester 2011 Transaktionen a) Erläutere was Transaktionen sind und wofür diese benötigt werden. Folge von Operationen mit bestimmten Eigenschaften: Atomicity

Mehr

www.informatik-aktuell.de

www.informatik-aktuell.de www.informatik-aktuell.de Flashback Reise in die Vergangenheit einfach. gut. beraten. Warum Oracle Zeitreisen anbieten kann, der Microsoft SQL Server aber leider nicht. IT-Tage Datenbanken 18.12.2015,

Mehr

Datenbanksysteme Technische Grundlagen Transaktions-Konzept, Mehrbenutzer-Synchronisation, Fehlerbehandlung

Datenbanksysteme Technische Grundlagen Transaktions-Konzept, Mehrbenutzer-Synchronisation, Fehlerbehandlung Datenbanksysteme Technische Grundlagen Transaktions-Konzept, Mehrbenutzer-Synchronisation, Fehlerbehandlung Prof. Dr. Manfred Gruber FH München Transaktions-Konzept (1) Beispiel: op 1 BOT op 2 read(k 1

Mehr

Datenbanken: Transaktionskonzept und Concurrency Control

Datenbanken: Transaktionskonzept und Concurrency Control Wesentlich für das Arbeiten mit Datenbanken sind konsistente Datenbestände! Folgerung: es muss sichergestellt werden, dass Datenmanipulationen von Benutzern immer in einem erneut konsistenten Zustand der

Mehr

Software-Engineering und Datenbanken

Software-Engineering und Datenbanken Software-Engineering und Datenbanken Transaktionskonzepte 1 Der Transaktionsbegriff Eine Transaktion ist eine Folge von Operationen, die die Datenbank von einem konsistenten Zustand in einen neuen überführen.

Mehr

Recovery- und Buffermanager

Recovery- und Buffermanager Recovery- und Buffermanager Gesamtübersicht der Komponenten beim Zusammenspiel des lokalen Recovery Manager und des Datenbank Buffer Manager: persistenter Log Main memory Lokaler Recovery Manager (LRM)

Mehr

Echtzeitfähige Ereignisgetriebene Scheduling-Strategien

Echtzeitfähige Ereignisgetriebene Scheduling-Strategien Friedrich-Alexander-Universität Erlangen-Nürnberg Ausgewählte Kapitel eingebetteter Systeme Echtzeitfähige Ereignisgetriebene Scheduling-Strategien Sven Kerschbaum 1. Einführung Bei einem eingebetteten

Mehr

Vorlesung 30.03.2009 1) Einführung

Vorlesung 30.03.2009 1) Einführung Vorlesung 30.03.2009 1) Einführung Was versteht man unter dem Begriff Datenbank? - Eine Datenbank ist eine Struktur zur Speicherung von Daten mit lesendem und schreibendem Zugriff - Allgemein meint man

Mehr

Technische Informatik II

Technische Informatik II Institut für Technische Informatik und Kommunikationsnetze Technische Informatik II Übung 1: Prozesse und Threads Aufgabe 1: Prozesse und Threads a) Wie verhält sich eine Applikation die aus mehreren Prozessen

Mehr

Transaktionen und Synchronisation konkurrierender Zugriffe

Transaktionen und Synchronisation konkurrierender Zugriffe Transaktionen und Synchronisation konkurrierender Zugriffe Fragestellungen Aufgaben des Transaktionsmanagers Aktivieren von Transaktionen entsprechend den Anforderungen von Anwendungsprogrammen. Dabei

Mehr

Systeme 1. Kapitel 5. Scheduling

Systeme 1. Kapitel 5. Scheduling Systeme 1 Kapitel 5 Scheduling Scheduling Verteilung und Zuweisung von begrenzten Ressourcen an konkurrierende Prozesse Beispiel: -> Zeitablaufsteuerung Zwei Prozesse zur gleichen Zeit rechenbereit auf

Mehr

Relationale Datenbanken Datenbankgrundlagen

Relationale Datenbanken Datenbankgrundlagen Datenbanksystem Ein Datenbanksystem (DBS) 1 ist ein System zur elektronischen Datenverwaltung. Die wesentliche Aufgabe eines DBS ist es, große Datenmengen effizient, widerspruchsfrei und dauerhaft zu speichern

Mehr

Teil VI. Datenbanken

Teil VI. Datenbanken Teil VI Datenbanken Überblick 1 Grundlegende Begriffe Motivation 2 Relationale Datenbanksysteme Das Relationale Datenmodell SQL 3 Entwurf von Datenbanken Das Enity Relationship (ER) Modell Abbildung von

Mehr

Real-Time Operating Systems Ein Überblick

Real-Time Operating Systems Ein Überblick Real-Time Operating Systems Ein Überblick Stefan Tittel Universität Dortmund Proseminar: Werkzeuge und Techniken zur Spezifikation, Simulation und Implementierung von eingebetteten Systemen, 2004 1 Einführung

Mehr

TAV Übung 3. Übung 3: Verteilte Datenhaltung

TAV Übung 3. Übung 3: Verteilte Datenhaltung Übung 3: Verteilte Datenhaltung 1. Serialisierung Konstruieren Sie Historien aus drei Transaktionen T1, T2 und T3, die folgende Merkmale aufweisen: 1. Die serielle Reihenfolge ist T1 vor T2 vor T3. 2.

Mehr

Datenbanken 16.1.2008. Die Entwicklung der Datenbanksysteme ist eng an die der Hardware gekoppelt und wird wie jene in Generationen eingeteilt:

Datenbanken 16.1.2008. Die Entwicklung der Datenbanksysteme ist eng an die der Hardware gekoppelt und wird wie jene in Generationen eingeteilt: Datenbanksysteme Entwicklung der Datenbanksysteme Die Entwicklung der Datenbanksysteme ist eng an die der Hardware gekoppelt und wird wie jene in Generationen eingeteilt: 1. Generation: In den fünfziger

Mehr

OSEK / OSEKtime Ausgewählte Kapitel eingebetteter Systeme

OSEK / OSEKtime Ausgewählte Kapitel eingebetteter Systeme OSEK / OSEKtime Ausgewählte Kapitel eingebetteter Systeme Wilhelm Haas Wilhelm.Haas@informatik.stud.uni-erlangen.de Friedrich-Alexander-Universität Erlangen-Nürnberg Institut für Informatik Lehrstuhl 4

Mehr

Gliederung Datenbanksysteme

Gliederung Datenbanksysteme Gliederung Datenbanksysteme 5. Datenbanksprachen 1. Datendefinitionsbefehle 2. Datenmanipulationsbefehle 3. Grundlagen zu SQL 6. Metadatenverwaltung 7. DB-Architekturen 1. 3-Schema-Modell 2. Verteilte

Mehr

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann Blatt Nr. 11 Übung zur Vorlesung Einsatz und Realisierung von Datenbanksystemen im SoSe15 Moritz Kaufmann (moritz.kaufmann@tum.de)

Mehr

Verteilte Datenbanken. Folien zum Datenbankpraktikum Wintersemester 2009/10 LMU München

Verteilte Datenbanken. Folien zum Datenbankpraktikum Wintersemester 2009/10 LMU München Kapitel 8 Verteilte Datenbanken Folien zum Datenbankpraktikum Wintersemester 2009/10 LMU München 2008 Thomas Bernecker, Tobias Emrich unter Verwendung der Folien des Datenbankpraktikums aus dem Wintersemester

Mehr

Datenbanken. Prof. Dr. Bernhard Schiefer. bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer

Datenbanken. Prof. Dr. Bernhard Schiefer. bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer Datenbanken Prof. Dr. Bernhard Schiefer bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer Wesentliche Inhalte Begriff DBS Datenbankmodelle Datenbankentwurf konzeptionell, logisch und relational

Mehr

Datenbanken: Datenintegrität. www.informatikzentrale.de

Datenbanken: Datenintegrität. www.informatikzentrale.de Datenbanken: Datenintegrität Definition "Datenkonsistenz" "in der Datenbankorganisation (...) die Korrektheit der gespeicherten Daten im Sinn einer widerspruchsfreien und vollständigen Abbildung der relevanten

Mehr

Software-Engineering und Datenbanken

Software-Engineering und Datenbanken Software-Engineering und Datenbanken Prof. Dr. Bernhard Schiefer bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer Prof. Dr. Bernhard Schiefer 1-1 Wesentliche Inhalte Begriff DBS Datenbankmodelle

Mehr

Bedeutung der Metadateien. Alle Metadaten werden in Dateien gehalten. NTFS ist ein Journal-File-System

Bedeutung der Metadateien. Alle Metadaten werden in Dateien gehalten. NTFS ist ein Journal-File-System 6 Beispiel: Windows NT (NTFS) 6.3 Metadaten 6 Beispiel: Windows NT (NTFS) 6.3 Metadaten 6.3 Metadaten 6.3 Metadaten (2) Alle Metadaten werden in Dateien gehalten Indexnummer 0 1 2 3 4 5 6 7 8 16 17 MFT

Mehr

Kapitel 6 Anfragebearbeitung

Kapitel 6 Anfragebearbeitung LUDWIG- MAXIMILIANS- UNIVERSITY MUNICH DEPARTMENT INSTITUTE FOR INFORMATICS DATABASE Skript zur Vorlesung: Datenbanksysteme II Sommersemester 2014 Kapitel 6 Anfragebearbeitung Vorlesung: PD Dr. Peer Kröger

Mehr

Prozessarchitektur einer Oracle-Instanz

Prozessarchitektur einer Oracle-Instanz 6. Juni 2008 Inhaltsverzeichnis Oracle Instanz 1 Oracle Instanz 2 3 Redo Log Buffer Shared Pool Java Pool & Large Pool Oracle Instanz Eine Oracle-Instanz ist Hauptbestandteil des Oracle Datenbank Management

Mehr

Caching Handbuch. Auftraggeber: Version: 01. INM Inter Network Marketing AG Usterstrasse 202 CH-8620 Wetzikon

Caching Handbuch. Auftraggeber: Version: 01. INM Inter Network Marketing AG Usterstrasse 202 CH-8620 Wetzikon Caching Handbuch Auftraggeber: Version: 01 Projekttyp: Erstellt durch: Internet David Bürge INM Inter Network Marketing AG Usterstrasse 202 CH-8620 Wetzikon Email david.buerge@inm.ch URL http://www.inm.ch

Mehr

Multicore Programming: Transactional Memory

Multicore Programming: Transactional Memory Software (STM) 07 Mai 2009 Software (STM) 1 Das Problem 2 Probleme mit 3 Definitionen Datenspeicherung Konflikterkennung Granularität Optimierungsmöglichkeiten Software (STM) 4 Software (STM) Beispielimplementation

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

Infrastruktur fit machen für Hochverfügbarkeit, Workload Management und Skalierbarkeit

Infrastruktur fit machen für Hochverfügbarkeit, Workload Management und Skalierbarkeit make connections share ideas be inspired Infrastruktur fit machen für Hochverfügbarkeit, Workload Management und Skalierbarkeit Artur Eigenseher, SAS Deutschland Herausforderungen SAS Umgebungen sind in

Mehr

Kapitel 12 Integrität der Datenbank

Kapitel 12 Integrität der Datenbank Kapitel 12 Integrität der Datenbank 12 Integrität der Datenbank 12 Integrität der Datenbank...1 12.1 Aspekte des Integritätsproblems...3 12.2 Semantische Integrität...4 12.3 Das Konzept der Transaktion...6

Mehr

Lösungsskizzen zur Abschlussklausur Betriebssysteme

Lösungsskizzen zur Abschlussklausur Betriebssysteme Lösungsskizzen zur Abschlussklausur Betriebssysteme 24. Januar 2013 Name: Vorname: Matrikelnummer: Studiengang: Hinweise: Tragen Sie zuerst auf allen Blättern (einschlieÿlich des Deckblattes) Ihren Namen,

Mehr

Task A Zündung. Task B Einspritzung. Task C Erfassung Pedalwert. J. Schäuffele, Th. Zurawka: Automotive Software Engineering, Vieweg, 2003

Task A Zündung. Task B Einspritzung. Task C Erfassung Pedalwert. J. Schäuffele, Th. Zurawka: Automotive Software Engineering, Vieweg, 2003 Task! evt. parallel zu bearbeitende Ausführungseinheit! Beispiel: Task A Zündung Task B Einspritzung Task C Erfassung Pedalwert Zeit t J. Schäuffele, Th. Zurawka:, Vieweg, 2003 Echtzeitbetriebssysteme

Mehr

Die Grundbegriffe Die Daten Die Informationen

Die Grundbegriffe Die Daten Die Informationen Die Grundbegriffe Die Daten sind diejenigen Elemente, die vom Computer verarbeitet werden. Die Informationen sind Wissenselemente, welche durch die Analyse von Daten erhalten werden können. Die Daten haben

Mehr

Grundlagen verteilter Systeme

Grundlagen verteilter Systeme Universität Augsburg Insitut für Informatik Prof. Dr. Bernhard Bauer Wolf Fischer Christian Saad Wintersemester 08/09 Übungsblatt 3 12.11.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1: a)

Mehr

Koordination des Mehrbenutzerbetriebs 9. Koordination des Mehrbenutzerbetriebs

Koordination des Mehrbenutzerbetriebs 9. Koordination des Mehrbenutzerbetriebs 9. Mehrbenutzerbetrieb: DBS bedient gleichzeitig mehrere Benutzer Benutzer arbeiten zwar unabhängig voneinander, können aber die gleiche Relation oder sogar den gleichen Datensatz bearbeiten! Aktivität

Mehr

4 Planung von Anwendungsund

4 Planung von Anwendungsund Einführung 4 Planung von Anwendungsund Datenbereitstellung Prüfungsanforderungen von Microsoft: Planning Application and Data Provisioning o Provision applications o Provision data Lernziele: Anwendungen

Mehr

Verteilte Echtzeit-Systeme

Verteilte Echtzeit-Systeme - Verteilte Echtzeit-Systeme Hans-Albrecht Schindler Wintersemester 2015/16 Teil B: Echtzeit-Betriebssysteme Abschnitt 9: Scheduling gemischter Prozessmengen CSI Technische Universität Ilmenau www.tu-ilmenau.de

Mehr

Definition Informationssystem

Definition Informationssystem Definition Informationssystem Informationssysteme (IS) sind soziotechnische Systeme, die menschliche und maschinelle Komponenten umfassen. Sie unterstützen die Sammlung, Verarbeitung, Bereitstellung, Kommunikation

Mehr

Performance by Design Wie werden performante ETL-Prozesse erstellt?

Performance by Design Wie werden performante ETL-Prozesse erstellt? Performance by Design Wie werden performante ETL-Prozesse erstellt? Reinhard Mense ARETO Consulting Bergisch Gladbach Schlüsselworte: DWH, Data Warehouse, ETL-Prozesse, Performance, Laufzeiten, Partitionierung,

Mehr

SOLISYON GMBH CHRISTIAN WOLF, BENJAMIN WEISSMAN. Optimierung von Abfragen in MS SQL Server DWH-Umgebungen

SOLISYON GMBH CHRISTIAN WOLF, BENJAMIN WEISSMAN. Optimierung von Abfragen in MS SQL Server DWH-Umgebungen WEITER BLICKEN. MEHR ERKENNEN. BESSER ENTSCHEIDEN. Optimierung von Abfragen in MS SQL Server DWH-Umgebungen SOLISYON GMBH CHRISTIAN WOLF, BENJAMIN WEISSMAN VERSION 1.0 OPTIMIERUNG VON ABFRAGEN IN MS SQL

Mehr

Datenbanken Konsistenz und Mehrnutzerbetrieb III

Datenbanken Konsistenz und Mehrnutzerbetrieb III Datenbanken Konsistenz und Mehrnutzerbetrieb III 1. Oracle Architektur! Komponenten des Oracle Servers! Zugriff über Netzwerk 2. Zugriffsrechte! Starten und Schließen der Datenbank! Nutzer und Rollen!

Mehr

Vorlesungsinhalt. Recovery. G. Specht: Datenbanksysteme 11-1. Kapitel XI. Vorlesung Datenbanksysteme Univ.-Prof. Dr.

Vorlesungsinhalt. Recovery. G. Specht: Datenbanksysteme 11-1. Kapitel XI. Vorlesung Datenbanksysteme Univ.-Prof. Dr. Recovery Kapitel XI Vorlesung Datenbanksysteme Univ.-Prof. Dr. Günther Specht Universität Innsbruck Institut für Informatik Datenbanken und Informationssysteme (DBIS) Vorlesungsinhalt 11. Recovery Fehler

Mehr

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz Hochverfügbar und Skalierung mit und ohne RAC Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC Alexander Scholz Copyright its-people Alexander Scholz 1 Einleitung Hochverfügbarkeit

Mehr

25.09.2014. Zeit bedeutet eine Abwägung von Skalierbarkeit und Konsistenz

25.09.2014. Zeit bedeutet eine Abwägung von Skalierbarkeit und Konsistenz 1 2 Dies ist ein Vortrag über Zeit in verteilten Anwendungen Wir betrachten die diskrete "Anwendungszeit" in der nebenläufige Aktivitäten auftreten Aktivitäten in einer hochgradig skalierbaren (verteilten)

Mehr

Einführung in Datenbanken

Einführung in Datenbanken Grundlagen der Programmierung 2 Einführung in Datenbanken Grundlagen der Programmierung 2 I-1 Inhalt Einführung Entity-Relationship-Diagramm Relationales Modell Entity-Relationship-Diagramm ins Relationales

Mehr

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector 7.4 Analyse anhand der SQL-Trace 337 7.3.5 Vorabanalyse mit dem Code Inspector Der Code Inspector (SCI) wurde in den vorangegangenen Kapiteln immer wieder erwähnt. Er stellt ein paar nützliche Prüfungen

Mehr

Transaktionen Recovery Isolationslevel. Datenbanksysteme. Transaktionen. Burkhardt Renz. Fachbereich MNI Technische Hochschule Mittelhessen

Transaktionen Recovery Isolationslevel. Datenbanksysteme. Transaktionen. Burkhardt Renz. Fachbereich MNI Technische Hochschule Mittelhessen Transaktionen Fachbereich MNI Technische Hochschule Mittelhessen Sommersemester 2015 Motivation ACID-Eigenschaften Übersicht Transaktionen Motivation ACID-Eigenschaften Ursachen für Logging und Backup

Mehr

FLASHRECOVER SNAPSHOTS. Sofortige, unlimitierte Snapshots, speziell für 100 % Flash-Speicherung

FLASHRECOVER SNAPSHOTS. Sofortige, unlimitierte Snapshots, speziell für 100 % Flash-Speicherung FLASHRECOVER SNAPSHOTS Sofortige, unlimitierte Snapshots, speziell für 100 % Flash-Speicherung FLASHRECOVER SNAPSHOTS BIETEN EFFIZIENTE, SKALIERBARE UND LEICHT ZU VERWALTENDE SNAPSHOTS OHNE KOMPROMISSE

Mehr

IT-Kompaktkurs. Datenbanken Skript zur Folge 4. Prof. Dr. Manfred Gruber Fachhochschule München

IT-Kompaktkurs. Datenbanken Skript zur Folge 4. Prof. Dr. Manfred Gruber Fachhochschule München Fachhochschule München Munich University of Applied Sciences IT-Kompaktkurs Skript zur Folge 4 Prof. Dr. Manfred Gruber Fachhochschule München manfred.gruber@informatik.fh-muenchen.de Nov 1, 2000 Transaktions-Konzept,

Mehr

IT-Kompaktkurs. Datenbanken Skript zur Folge 10. Prof. Dr. Dieter Rummler Fachhochschule Deggendorf

IT-Kompaktkurs. Datenbanken Skript zur Folge 10. Prof. Dr. Dieter Rummler Fachhochschule Deggendorf IT-Kompaktkurs Skript zur Folge 10 Prof. Dr. Dieter Rummler Fachhochschule Deggendorf Client Server Architektur Zunächst zur grundsätzlichen Unterscheidung zwischen File-Server Datenbank und Server-Datenbank

Mehr

Systeme I: Betriebssysteme Kapitel 4 Prozesse. Maren Bennewitz

Systeme I: Betriebssysteme Kapitel 4 Prozesse. Maren Bennewitz Systeme I: Betriebssysteme Kapitel 4 Prozesse Maren Bennewitz Version 20.11.2013 1 Begrüßung Heute ist Tag der offenen Tür Willkommen allen Schülerinnen und Schülern! 2 Wdhlg.: Attributinformationen in

Mehr

RAID. Name: Artur Neumann

RAID. Name: Artur Neumann Name: Inhaltsverzeichnis 1 Was ist RAID 3 1.1 RAID-Level... 3 2 Wozu RAID 3 3 Wie werden RAID Gruppen verwaltet 3 3.1 Software RAID... 3 3.2 Hardware RAID... 4 4 Die Verschiedenen RAID-Level 4 4.1 RAID

Mehr

Datenbank-Administration im WS 2012/13 - Einführung in Projekt 3 - Prof. Dr. Klaus Küspert Dipl.-Math. Katharina Büchse Dipl.-Inf.

Datenbank-Administration im WS 2012/13 - Einführung in Projekt 3 - Prof. Dr. Klaus Küspert Dipl.-Math. Katharina Büchse Dipl.-Inf. Datenbank-Administration im WS 2012/13 - Einführung in Projekt 3 - Prof. Dr. Klaus Küspert Dipl.-Math. Katharina Büchse Dipl.-Inf. Andreas Göbel Friedrich-Schiller-Universität Jena Lehrstuhl für Datenbanken

Mehr

Transaktionsverwaltung

Transaktionsverwaltung Transaktionsverwaltung Commit Eigenschaften von Transaktionen (ACID) Transaktionen in SQL Kapitel 9 1 Transaktionsverwaltung Beispiel einer typischen Transaktion in einer Bankanwendung: 1. Lese den Kontostand

Mehr

P.A. Bernstein, V. Hadzilacos, N. Goodman

P.A. Bernstein, V. Hadzilacos, N. Goodman TRANSAKTIONEN UND DATENINTEGRITÄT Concurrency Control and Recovery in Database Systems P.A. Bernstein, V. Hadzilacos, N. Goodman Addison Wesley, 1987. Kapitel 1. und 6. Grundlagen der Datenbanksysteme

Mehr

Datenbanken: Backup und Recovery

Datenbanken: Backup und Recovery Der Prozess der Wiederherstellung der Daten einer Datenbank nach einem Fehler im laufenden Betrieb in einen konsistenten, möglichst verlustfreien Zustand heißt Recovery. Beteiligt an diesem Recovery sind

Mehr

Datenbanken. Ein DBS besteht aus zwei Teilen:

Datenbanken. Ein DBS besteht aus zwei Teilen: Datenbanken Wikipedia gibt unter http://de.wikipedia.org/wiki/datenbank einen kompakten Einblick in die Welt der Datenbanken, Datenbanksysteme, Datenbankmanagementsysteme & Co: Ein Datenbanksystem (DBS)

Mehr

Datenbanken II Literatur

Datenbanken II Literatur Datenbanken II Literatur C. J. Date: An Introduction to Database Systems; Addison-Wesley Systems Programming Series. 6th ed. 1995 H. E. Erbs, S. Karczewski und I. Schestag: Datenbanken (Datenmodelle, Objekte,

Mehr

Echtzeitscheduling (1)

Echtzeitscheduling (1) Echtzeitscheduling (1) Scheduling in Betriebssystemen Ressourcenausteilung (CPU, Speicher, Kommunikation) Faire Ressourcenvergabe, insbesondere CPU Hohe Interaktivität / kurze Reaktionszeit für interaktive

Mehr

Collaborative Virtual Environments

Collaborative Virtual Environments Collaborative Virtual Environments Stefan Lücking Projektgruppe Kreativität und Technik AG Domik WS 02/03 09.01.2003 1/35 Was sind CVE? Versuch einer Definition : Ein CVE ist ein Programm, das eine virtuelle

Mehr

56 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen. Client Client Client Client Client. Public Network. aktiv. Private Network.

56 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen. Client Client Client Client Client. Public Network. aktiv. Private Network. 56 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen aktiv inaktiv Node 1 ( Aktiv ) Node 2 ( Passiv ) Private Network aktiv inaktiv (exklusiver Zugriff) Abbildung 3.1: Schematische Darstellung

Mehr

Teil I Einführung & Grundlagen. 1.1 Was ist eine Transaktion?

Teil I Einführung & Grundlagen. 1.1 Was ist eine Transaktion? Teil I Einführung & Grundlagen Kapitel 1: Einführung in das Transaktionskonzept 1.1 Was ist eine Transaktion? 1.2 Transaktionseigenschaften 1.3 Beispiele Datenbanktransaktionen: Banküberweisung Moderne

Mehr

ProCall 5 Enterprise

ProCall 5 Enterprise ProCall 5 Enterprise Installationsanleitung Upgradeverfahren von ProCall 4+ Enterprise auf ProCall 5 Enterprise ProCall 5 Enterprise Upgrade Seite 1 von 10 Rechtliche Hinweise / Impressum Die Angaben in

Mehr

ND.Zip & Notes/Domino 6

ND.Zip & Notes/Domino 6 ND.Zip for Notes Version 1.1 ND.Zip & Notes/Domino 6 Stand: 9.5.2003 Inhaltsverzeichnis 1 Inhaltsverzeichnis 2 ND.Zip: ein Muss auch für Notes/Domino 6! 3 LZ1 erzielt keinen Mehrwert, 4 Sofortiger und

Mehr

Datenbanksystem. System Global Area. Hintergrundprozesse. Dr. Frank Haney 1

Datenbanksystem. System Global Area. Hintergrundprozesse. Dr. Frank Haney 1 Datenbanksystem System Global Area Hintergrundprozesse Dr. Frank Haney 1 Komponenten des Datenbanksystems System Global Area Program Global Area Hintergrundprozesse Dr. Frank Haney 2 System Global Area

Mehr

1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem

1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem 1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem Management, Access Management a. Event Management b. Service Desk c. Facilities Management d. Change Management e. Request Fulfilment

Mehr

Von der Platte zur Anwendung (Platte, Treiber, Dateisystem)

Von der Platte zur Anwendung (Platte, Treiber, Dateisystem) (Platte, Treiber, Dateisystem) 1. Einleitung 2. Dateisysteme 2.1. Logisches Dateisystem 2.2. Dateiorganisationsmodul 2.3. Basis Dateisystem 3. Festplattentreiber 3.1. Funktionsweise 3.2. Scheduling Verfahren

Mehr

Prozesse und Prozessmanagement des BS. 1 Unterschied Prozess, Threads. 1.1 Prozess. 1.2 Threads

Prozesse und Prozessmanagement des BS. 1 Unterschied Prozess, Threads. 1.1 Prozess. 1.2 Threads Prozesse und Prozessmanagement des BS 1 Unterschied Prozess, Threads 1.1 Prozess Bei jedem Programm muss gespeichert werden, welche Betriebsmittel (Speicherplatz, CPU- Zeit, CPU-Inhalt,...) es benötigt.

Mehr

Vorlesung Datenbankmanagementsysteme. Vorlesung Datenbankmanagementsysteme Überblick M. Lange, S. Weise Folie #0-1

Vorlesung Datenbankmanagementsysteme. Vorlesung Datenbankmanagementsysteme Überblick M. Lange, S. Weise Folie #0-1 Vorlesung Datenbankmanagementsysteme Vorlesung Datenbankmanagementsysteme Überblick M. Lange, S. Weise Folie #0-1 Vorlesung Datenbankmanagementsysteme Überblick M. Lange, S. Weise Folie #0-2 Bioinformatik:

Mehr

CARL HANSER VERLAG. Christopher Allen. Oracle PL/SQL für Einsteiger Der Einsatz von SQL und PL/SQL in der Oracle-Datenbank 3-446-21801-7

CARL HANSER VERLAG. Christopher Allen. Oracle PL/SQL für Einsteiger Der Einsatz von SQL und PL/SQL in der Oracle-Datenbank 3-446-21801-7 CARL HANSER VERLAG Christopher Allen Oracle PL/SQL für Einsteiger Der Einsatz von SQL und PL/SQL in der Oracle-Datenbank 3-446-21801-7 www.hanser.de Inhaltsverzeichnis Danksagung...XI Einleitung...XIII

Mehr

Benutzerdokumentation Hosted Backup Services Client

Benutzerdokumentation Hosted Backup Services Client Benutzerdokumentation Hosted Backup Services Client Geschäftshaus Pilatushof Grabenhofstrasse 4 6010 Kriens Version 1.1 28.04.2014 Inhaltsverzeichnis 1 Einleitung 4 2 Voraussetzungen 4 3 Installation 5

Mehr

Projekt für Systemprogrammierung WS 06/07

Projekt für Systemprogrammierung WS 06/07 Dienstag 30.01.2007 Projekt für Systemprogrammierung WS 06/07 Von: Hassan Bellamin E-Mail: h_bellamin@web.de Gliederung: 1. Geschichte und Definition 2. Was ist Virtualisierung? 3. Welche Virtualisierungssoftware

Mehr

Prozessor (CPU, Central Processing Unit)

Prozessor (CPU, Central Processing Unit) G Verklemmungen G Verklemmungen Einordnung: Prozessor (CPU, Central Processing Unit) Hauptspeicher (Memory) Ein-, Ausgabegeräte/ Periphere Geräte (I/O Devices) externe Schnittstellen (Interfaces) Hintergrundspeicher

Mehr

TIKOS Leitfaden. TIKOS Update

TIKOS Leitfaden. TIKOS Update TIKOS Leitfaden TIKOS Update Copyright 2015, Alle Rechte vorbehalten support@socom.de 06.05.2015 Inhalt 1. Allgemeine Hinweise... 3 2. Ausführen des Updates... 3 3. Mögliche Meldungen beim Update... 9

Mehr

4D Server v12 64-bit Version BETA VERSION

4D Server v12 64-bit Version BETA VERSION 4D Server v12 64-bit Version BETA VERSION 4D Server v12 unterstützt jetzt das Windows 64-bit Betriebssystem. Hauptvorteil der 64-bit Technologie ist die rundum verbesserte Performance der Anwendungen und

Mehr

Wiederanlauf (Recovery)

Wiederanlauf (Recovery) DEVO 8.1 Wiederanlauf (Recovery) DEVO 8.2 Ziele Wiederherstellung eines konsistenten Datenbankzustandes nach einem Fehler. Fehler: Transaktionsabbruch: eine Transaktion muß nach einem logischen Fehler

Mehr

Die allerwichtigsten Raid Systeme

Die allerwichtigsten Raid Systeme Die allerwichtigsten Raid Systeme Michael Dienert 4. Mai 2009 Vorbemerkung Dieser Artikel gibt eine knappe Übersicht über die wichtigsten RAID Systeme. Inhaltsverzeichnis 1 Die Abkürzung RAID 2 1.1 Fehlerraten

Mehr

Artikel eindeutig mit Barcodes identifizieren und verfolgen

Artikel eindeutig mit Barcodes identifizieren und verfolgen Artikel eindeutig mit Barcodes identifizieren und verfolgen Einführung Um die Vielfalt an Anforderungen zu erfüllen haben wir drei verschiedene Varianten zur Erfassung von Barcodes implementiert. Die drei

Mehr

Fragenkatalog zum Kurs 1666 (Datenbanken in Rechnernetzen) Kurstext von SS 96

Fragenkatalog zum Kurs 1666 (Datenbanken in Rechnernetzen) Kurstext von SS 96 Fragenkatalog zum Kurs 1666 (Datenbanken in Rechnernetzen) Kurstext von SS 96 Dieser Fragenkatalog wurde aufgrund das Basistextes und zum Teil aus den Prüfungsprotokollen erstellt, um sich auf mögliche

Mehr

DocuWare unter Windows 7

DocuWare unter Windows 7 DocuWare unter Windows 7 DocuWare läuft unter dem neuesten Microsoft-Betriebssystem Windows 7 problemlos. Es gibt jedoch einige Besonderheiten bei der Installation und Verwendung von DocuWare, die Sie

Mehr

Testfragen PRINCE2 Foundation

Testfragen PRINCE2 Foundation Testfragen PRINCE2 Foundation Multiple Choice Prüfungsdauer: 20 Minuten Hinweise zur Prüfung 1. Sie sollten versuchen, alle 25 Fragen zu beantworten. 2. Zur Beantwortung der Fragen stehen Ihnen 20 Minuten

Mehr

Grundlagen von Datenbanken

Grundlagen von Datenbanken Grundlagen von Datenbanken Aufgabenzettel 1 Grundlagen Datenbanken: Kurzer historischer Überblick (1) Anwendung 1 Anwendung 2 Datei 1 Datei 2 Datei 3 Zugriff auf Dateien ohne spezielle Verwaltung 2 Exkurs:

Mehr

SFTP Datenübertragungsclient PK-SFTP. automatische Verbindung zu einem SFTP-Server in einstellbaren Zeitintervallen

SFTP Datenübertragungsclient PK-SFTP. automatische Verbindung zu einem SFTP-Server in einstellbaren Zeitintervallen SFTP Datenübertragungsclient PK-SFTP automatische Verbindung zu einem SFTP-Server in einstellbaren Zeitintervallen senden, abholen und verifizieren der bereitstehenden Daten Protokollierung der Datenübertragung

Mehr

Tag 4 Inhaltsverzeichnis

Tag 4 Inhaltsverzeichnis Tag 4 Inhaltsverzeichnis Normalformen Problem Formen (1-4) Weitere Formen Transaktionen Synchronisationsprobleme Überblick Autocommit Locking Savepoints Isolation levels Übungen RDB 4-1 Normalformen Problematik

Mehr

OPERATIONEN AUF EINER DATENBANK

OPERATIONEN AUF EINER DATENBANK Einführung 1 OPERATIONEN AUF EINER DATENBANK Ein Benutzer stellt eine Anfrage: Die Benutzer einer Datenbank können meist sowohl interaktiv als auch über Anwendungen Anfragen an eine Datenbank stellen:

Mehr

Musteraufbau eines Anforderungsprofils zur Einführung neuer Software

Musteraufbau eines Anforderungsprofils zur Einführung neuer Software Musteraufbau eines Anforderungsprofils zur Einführung neuer Software Ottostr. 15 96047 Bamberg Tel. +49/951/98046200 Fax +49/951/98046150 email: info@softcondev.de www: softcondev.de INHALT Vorwort Diese

Mehr

RAC auf Sun Cluster 3.0

RAC auf Sun Cluster 3.0 RAC auf Sun Cluster 3.0 Schlüsselworte RAC, OPS, Sun Cluster, Performance, Availability Zusammenfassung Oracle hat mit dem Real Application Cluster (RAC) aus einer Hochverfügbarkeitslösung eine Höchstverfügbarkeitslösung

Mehr

Informationssystemanalyse Use Cases 11 1

Informationssystemanalyse Use Cases 11 1 Informationssystemanalyse Use Cases 11 1 Use Cases Slide 1 Als ein populäres Mittel um Anforderungen zu erfassen und Systeme zu beschreiben, werden Use Cases benutzt. Sie bilden die Basis für eine umfassendere

Mehr