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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Implementierung von Dateisystemen

Implementierung von Dateisystemen Implementierung von Dateisystemen Teil 2 Prof. Dr. Margarita Esponda WS 2011/2012 44 Effizienz und Leistungssteigerung Festplatten sind eine wichtige Komponente in jedem Rechnersystem und gleichzeitig

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

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

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

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

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

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

Einleitung. Literatur. Pierre Fierz. Architektur von Datenbanksystemen. Physische Datenunabhängigkeit. Der Datenbank Administrator (DBA) 1.

Einleitung. Literatur. Pierre Fierz. Architektur von Datenbanksystemen. Physische Datenunabhängigkeit. Der Datenbank Administrator (DBA) 1. Inhalt der Vorlesung Literatur 1 Datenmodellierung (Entity-Relationship Modell) 2 Das relationale Modell 3 Relationenalgebra 4 Datenbanksprache (SQL) 5 Normalisierung 6 Vom ERM zum Datenbankschema 7 Routinen

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

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

Die wichtigsten Vorteile von SEPPmail auf einen Blick

Die wichtigsten Vorteile von SEPPmail auf einen Blick Die wichtigsten Vorteile von SEPPmail auf einen Blick August 2008 Inhalt Die wichtigsten Vorteile von SEPPmail auf einen Blick... 3 Enhanced WebMail Technologie... 3 Domain Encryption... 5 Queue-less Betrieb...

Mehr

Projektphasen und Technische Vorbereitung eines NX Refiles mit dem PLMJobManager

Projektphasen und Technische Vorbereitung eines NX Refiles mit dem PLMJobManager Projektphasen und Technische Vorbereitung eines NX Refiles mit dem PLMJobManager Dieses Dokument dient zur Information über die Organisation der Projektphasen und der technischen Vorbereitung eines Refile

Mehr

Scheduling in Echtzeitbetriebssystemen. Prof. Dr. Margarita Esponda Freie Universität Berlin

Scheduling in Echtzeitbetriebssystemen. Prof. Dr. Margarita Esponda Freie Universität Berlin Scheduling in Echtzeitbetriebssystemen Prof. Dr. Margarita Esponda Freie Universität Berlin Echtzeitsysteme Korrekte Ergebnisse zum richtigen Zeitpunkt Hart Echtzeitsysteme Eine verspätete Antwort ist

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

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

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

Approximationsalgorithmen

Approximationsalgorithmen Ausarbeitung zum Thema Approximationsalgorithmen im Rahmen des Fachseminars 24. Juli 2009 Robert Bahmann robert.bahmann@gmail.com FH Wiesbaden Erstellt von: Robert Bahmann Zuletzt berarbeitet von: Robert

Mehr

In die Zeilen würden die Daten einer Adresse geschrieben werden. Das Ganze könnte in etwa folgendermaßen aussehen:

In die Zeilen würden die Daten einer Adresse geschrieben werden. Das Ganze könnte in etwa folgendermaßen aussehen: 1 Einführung in Datenbanksysteme Fast jeder kennt Excel und hat damit in seinem Leben schon einmal gearbeitet. In Excel gibt es Arbeitsblätter, die aus vielen Zellen bestehen, in die man verschiedene Werte

Mehr

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Name: Matrikel-Nr: Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Bitte schreiben Sie leserlich und antworten Sie kurz und präzise. 1. Zeichnen Sie das Schichten-Modell eines Computersystems und markieren

Mehr

Reaktive Systeme und synchrones Paradigma

Reaktive Systeme und synchrones Paradigma Sascha Kretzschmann Freie Universität Berlin Reaktive Systeme und synchrones Paradigma Einführung in das Seminar über synchrone Programmiersprachen Worum geht es? INHALT 2 Inhalt 1. Einleitung - Wo befinden

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

Systeme I: Betriebssysteme Kapitel 7 Scheduling. Maren Bennewitz

Systeme I: Betriebssysteme Kapitel 7 Scheduling. Maren Bennewitz Systeme I: Betriebssysteme Kapitel 7 Scheduling Maren Bennewitz Version 23.01.2013 1 Inhalt Vorlesung Aufbau einfacher Rechner Überblick: Aufgabe, Historische Entwicklung, unterschiedliche Arten von Betriebssystemen

Mehr

In Tabelle 2.1 sehen Sie das Ergebnis beider Ausführungen auf meiner Maschine.

In Tabelle 2.1 sehen Sie das Ergebnis beider Ausführungen auf meiner Maschine. Kapitel 2 Datenverwaltung durch SQL Server Wir wollen das obige Skript zwei Mal laufen lassen, einmal mit und einmal ohne eingeschalteten Schreibcache der Festplatte. Für eine lokale Festplatte können

Mehr

Scheduler. vereinfachende Annahmen: alle Transaktionen werden wirksam nur Konflikt-Serialisierbarkeit keine Versionen

Scheduler. vereinfachende Annahmen: alle Transaktionen werden wirksam nur Konflikt-Serialisierbarkeit keine Versionen Scheduler Der Scheduler des Informationssystems hat zunächst die Aufgabe, die Anweisungen von parallel auszuführenden Transaktionen in einer geeigneten Reihenfolge anzuordnen. Darüber hinaus muß er auch

Mehr

REAL-TIME DATA WAREHOUSING

REAL-TIME DATA WAREHOUSING REAL-TIME DATA WAREHOUSING Lisa Wenige Seminarvortrag Data Warehousing und Analytische Datenbanken Friedrich-Schiller-Universität Jena - 19.01.12 Lisa Wenige 19.01.2012 2 Agenda 1. Motivation 2. Begriffsbestimmung

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

Redwood Cronacle und REALTECH theguard! Integration

Redwood Cronacle und REALTECH theguard! Integration Redwood Cronacle und REALTECH theguard! Integration Einleitung Redwood Software und REALTECH haben gemeinsam eine Lösung entwickelt, die die Systemverfügbarkeit von SAP und mysap Systemen signifikant erhöht.

Mehr

Die angegebenen Versionsnummern beziehen sich jeweils auf die Datei DbbLxGui.exe.

Die angegebenen Versionsnummern beziehen sich jeweils auf die Datei DbbLxGui.exe. Change Log: DBB/LX Die angegebenen Versionsnummern beziehen sich jeweils auf die Datei DbbLxGui.exe. 1. Version 4.5.0.1243 1. AF: Das Tool Datenbank neu aufbauen wurde ergänzt. Damit können Datenbanken,

Mehr

In-Memory Analytics. Marcel Poltermann. Fachhochschule Erfurt. Informationsmanagement

In-Memory Analytics. Marcel Poltermann. Fachhochschule Erfurt. Informationsmanagement Marcel Poltermann Fachhochschule Erfurt Informationsmanagement Inhaltsverzeichnis Glossar...III Abbildungsverzeichnis...III 1 Erläuterung:... 2 2 Technische Grundlagen... 2 2.1 Zugriff physische Datenträger:...

Mehr

Dateisysteme mit Plugin-Funktion

Dateisysteme mit Plugin-Funktion Dateisysteme mit Plugin-Funktion Basierend auf Reiser 4 unter Linux http://llugb.amsee.de/logo.gif Ausgearbeitet und vorgetragen von Michael Berger 1/23 Agenda Die Idee Dateisysteme mit Plugin-Funktion

Mehr

Effizientes Änderungsmanagement in Outsourcing- Projekten

Effizientes Änderungsmanagement in Outsourcing- Projekten Effizientes Änderungsmanagement in Outsourcing- Projekten Dr. Henning Sternkicker Rational Software IBM Deutschland GmbH Sittarder Straße 31 52078 Aachen henning.sternkicker@de.ibm.com Abstract: Es werden

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

Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte Einleitung

Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte Einleitung Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte DWH Projekt, Methodik, Stärken und Schwächen, Übersicht, Weg der Daten,

Mehr

Microsoft SQL Server 2005 für Administratoren

Microsoft SQL Server 2005 für Administratoren Microsoft SQL Server 2005 für Administratoren Irene Bauder ISBN 3-446-22800-4 Leseprobe Weitere Informationen oder Bestellungen unter http://www.hanser.de/3-446-22800-4 sowie im Buchhandel Sichern von

Mehr

Alle Metadaten werden in Dateien gehalten

Alle Metadaten werden in Dateien gehalten 6 Beispiel: Windows NT (NTFS) 6.3 Metadaten 6.3 Metadaten Alle Metadaten werden in Dateien gehalten Indexnummer 0 1 2 3 4 5 6 7 8 16 17 MFT MFT Kopie (teilweise) Log File Volume Information Attributtabelle

Mehr

Projekt:

Projekt: <Hier den Namen des Projektes eingeben!> <Adresse> <Telefon / Fax> <Ansprechpartner> Pflichtenheft Die Aufgabe des Pflichtenheftes ist es zu beschreiben, was die zu entwickelnde Software für den Anwender leisten soll. Diese Vorlage basiert auf der aus TSE I bekannten Vorlage. Projekt:

Mehr

Oracle Datenbank - Recovery

Oracle Datenbank - Recovery Oracle Datenbank - Recovery H.-G. Hopf Georg-Simon-Ohm Fachhochschule Nürnberg Datenbank-Recovery / 1 Η. G.Hopf / 10.04.2003 Inhaltsverzeichnis Transaktionsablauf Prozess - Recovery Instanz - Recovery

Mehr

Institut für Verteilte Systeme

Institut für Verteilte Systeme Institut für Verteilte Systeme Prof. Dr. Franz Hauck Seminar: Multimedia- und Internetsysteme, Wintersemester 2010/11 Betreuer: Jörg Domaschka Bericht zur Seminarssitzung am 2011-01-31 Bearbeitet von :

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

Konsistente Navision Datensicherung

Konsistente Navision Datensicherung Konsistente Navision Datensicherung Dokumentation Hintergrund Die Möglichkeit, Datensicherungen durchzuführen, ist in jedem Navision System gegeben. Diese eingebaute Routine ist eine sehr anspruchsvolle

Mehr

RECOVERY. "Concurrency Control and Recovery in Database Systems" Bernstein, Hadzilacos, Goodman. Addison-Wesley. Kapitel 1, 6.

RECOVERY. Concurrency Control and Recovery in Database Systems Bernstein, Hadzilacos, Goodman. Addison-Wesley. Kapitel 1, 6. Recovery 1 RECOVERY "Concurrency Control and Recovery in Database Systems" Bernstein, Hadzilacos, Goodman Addison-Wesley Kapitel 1, 6 Recovery 2 Modell eines Datenbanksystems Ein Datenbanksystem besteht

Mehr

CPU-Scheduling - Grundkonzepte

CPU-Scheduling - Grundkonzepte CPU-Scheduling - Grundkonzepte Sommersemester 2015 Seite 1 Gesamtüberblick 1. Einführung in Computersysteme 2. Entwicklung von Betriebssystemen 3. Architekturansätze 4. Interruptverarbeitung in Betriebssystemen

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

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 Automatisierung von Datensicherungen mit Microsoft Dynamics NAV (CSIDE) amball empfiehlt ExpandIT Backup Utility

1 Automatisierung von Datensicherungen mit Microsoft Dynamics NAV (CSIDE) amball empfiehlt ExpandIT Backup Utility 1 Automatisierung von Datensicherungen mit Microsoft Dynamics NAV (CSIDE) amball empfiehlt ExpandIT Backup Utility Backups sind unverzichtbarer Bestandteil jeder verlässlichen ERP-Lösung. Das Backup der

Mehr

6 Architektur-Mittel (WOMIT)

6 Architektur-Mittel (WOMIT) 6 Architektur-Mittel (WOMIT) Abb. 6-1: Positionierung des Kapitels im Ordnungsrahmen. Dieses Kapitel befasst sich mit der WOMIT-Dimension des architektonischen Ordnungsrahmens, indem es grundlegende Konzepte

Mehr

Grundlagen der Verwendung von make

Grundlagen der Verwendung von make Kurzskript zum Thema: Grundlagen der Verwendung von make Stefan Junghans Gregor Gilka 16. November 2012 1 Einleitung In diesem Teilskript sollen die Grundlagen der Verwendung des Programmes make und der

Mehr

Verschiedene Arten des Datenbankeinsatzes

Verschiedene Arten des Datenbankeinsatzes 1 Beispiele kommerzieller DBMS: Kapitelinhalt Was charakterisiert und unterscheidet verschiedene Einsatzbereiche für. Welche prinzipiell unterschiedlichen Anforderungen ergeben sich für das DBMS bei Ein-

Mehr

Ausarbeitung im Rahmen der PG Autolab zum Thema: OSEK 1 -OS. geschrieben von Oliver Botschkowski

Ausarbeitung im Rahmen der PG Autolab zum Thema: OSEK 1 -OS. geschrieben von Oliver Botschkowski Ausarbeitung im Rahmen der PG Autolab zum Thema: OSEK 1 -OS geschrieben von Oliver Botschkowski 1 Offene Systeme und deren Schnittstelle für die Elektronik im Kraftfahrzeug 1 Oliver Botschkowski - OSEK-OS

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

Inhaltsverzeichnis. BüroWARE Systemanforderungen ab Version 5.31. Generelle Anforderungen SoftENGINE BüroWARE SQL / Pervasive. 2

Inhaltsverzeichnis. BüroWARE Systemanforderungen ab Version 5.31. Generelle Anforderungen SoftENGINE BüroWARE SQL / Pervasive. 2 Inhaltsverzeichnis Generelle Anforderungen SoftENGINE BüroWARE SQL / Pervasive. 2 1. Terminal-Server-Betrieb (SQL)... 3 1.1. Server 3 1.1.1. Terminalserver... 3 1.1.2. Datenbankserver (bei einer Datenbankgröße

Mehr

Informa(onssysteme Übersicht Sommersemester 2015

Informa(onssysteme Übersicht Sommersemester 2015 Prof. Dr.-Ing. Stefan Deßloch AG Heterogene Informationssysteme Zi. 36/329, Tel.: 0631-205-3275 E-Mail: dessloch@cs.uni-kl.de Informa(onssysteme Übersicht Sommersemester 2015 h8p://wwwlgis.informa(k.uni-

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

Tinytag Funk- Datenlogger- Software

Tinytag Funk- Datenlogger- Software Tinytag Funk- Datenlogger- Software Seite: 1 Tinytag Funk- Datenlogger- Software Tinytag Explorer ist die Windows- basierte Software zum Betrieb eines Tinytag Funk- Systems. Die Anwender können ihre Daten

Mehr

Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht)

Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht) Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht) Christian Haag, DATA MART Consulting Consulting Manager Oracle DWH Team

Mehr

TECHNISCHE PRODUKTINFORMATION CARUSO

TECHNISCHE PRODUKTINFORMATION CARUSO 1111 TECHNISCHE PRODUKTINFORMATION CARUSO TECHNISCHE PRODUKTINFORMATION Seite 0/7 Inhalt 1 Systemdefinition............2 2 Technische Details für den Betrieb von CARUSO......2 2.1 Webserver... 2 2.2 Java

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

Google Spanner. Proseminar Ein-/Ausgabe Stand der Wissenschaft. Hanno Harte. Betreuer: Julian Kunkel 24.6.13

Google Spanner. Proseminar Ein-/Ausgabe Stand der Wissenschaft. Hanno Harte. Betreuer: Julian Kunkel 24.6.13 Google Spanner Proseminar Ein-/Ausgabe Stand der Wissenschaft Hanno Harte Betreuer: Julian Kunkel 24.6.13 1 /31 Gliederung - Überblick - Funktionsweise - True Time - Konsistenzsemantik - Benchmarks - Zusammenfassung

Mehr

Hochschule für Technik, Wirtschaft und Kultur Leipzig. Fakultät Informatik, Mathematik und Naturwissenschaften. Abstract

Hochschule für Technik, Wirtschaft und Kultur Leipzig. Fakultät Informatik, Mathematik und Naturwissenschaften. Abstract Hochschule für Technik, Wirtschaft und Kultur Leipzig Fakultät Informatik, Mathematik und Naturwissenschaften Abstract Oberseminar "Datenbanksysteme - Aktuelle Trends" Hauptspeicherdatenbanken Eingereicht

Mehr

Military Air Systems

Military Air Systems Trennung von Applikationen unterschiedlicher Kritikalität in der Luftfahrt durch Software en am Beispiel des Real-time Operating Systems PikeOS Dr. Bert Feldmann DGLR Workshop Garching, 09.10.2007 Seite

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

BICsuite!focus Parallelisierung von Prozessen mit der BICsuite Dynamic Submit Funktion

BICsuite!focus Parallelisierung von Prozessen mit der BICsuite Dynamic Submit Funktion independit Integrative Technologies GmbH Bergstraße 6 D 86529 Schrobenhausen BICsuite!focus Parallelisierung von Prozessen mit der BICsuite Dynamic Submit Funktion Dieter Stubler Ronald Jeninga July 30,

Mehr

RAID-Konfigurations-Tool

RAID-Konfigurations-Tool RAID-Konfigurations-Tool Benutzerhandbuch Version: 1.1 SecureGUARD GmbH, 2011 Inhalt: 1. Der Begriff RAID... 3 1.1. RAID-Level... 3 2. RAID erstellen... 5 3. RAID löschen... 8 4. Fehlerbehebung... 10 4.1.

Mehr

Perzentile mit Hadoop ermitteln

Perzentile mit Hadoop ermitteln Perzentile mit Hadoop ermitteln Ausgangspunkt Ziel dieses Projektes war, einen Hadoop Job zu entwickeln, der mit Hilfe gegebener Parameter Simulationen durchführt und aus den Ergebnissen die Perzentile

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

Konzeption eines Master-Data-Management-Systems. Sven Schilling

Konzeption eines Master-Data-Management-Systems. Sven Schilling Konzeption eines Master-Data-Management-Systems Sven Schilling Gliederung Teil I Vorstellung des Unternehmens Thema der Diplomarbeit Teil II Master Data Management Seite 2 Teil I Das Unternehmen Vorstellung

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Computerpflege. Windows XP Update (Arbeitssicherheit) Dieses Programm öffnet die Internetseite von Windows. Starten Sie die [Schnellsuche].

Computerpflege. Windows XP Update (Arbeitssicherheit) Dieses Programm öffnet die Internetseite von Windows. Starten Sie die [Schnellsuche]. Computerpflege Neben dem Virus Schutz ist es sehr wichtig den PC regelmässig zu Pflegen. Es sammeln sich täglich verschiedene Dateien an die nicht wirklich gebraucht werden und bedenkenlos gelöscht werden

Mehr

Vorlesung Datenbanksysteme Univ.-Prof. Dr. Günther Specht. Universität Innsbruck Institut für Informatik Datenbanken und Informationssysteme (DBIS)

Vorlesung Datenbanksysteme Univ.-Prof. Dr. Günther Specht. Universität Innsbruck Institut für Informatik Datenbanken und Informationssysteme (DBIS) Verteilte DB-Systeme Kapitel XIII Vorlesung Datenbanksysteme Univ.-Prof. Dr. Günther Specht Universität Innsbruck Institut für Informatik Datenbanken und Informationssysteme (DBIS) Vorlesungsinhalt 13.

Mehr

IVY. White Paper. Microsoft Dynamics NAV Workflow Controller Powered by Xpert.ivy

IVY. White Paper. Microsoft Dynamics NAV Workflow Controller Powered by Xpert.ivy White Paper IVY Microsoft Dynamics NAV Workflow Controller Powered by Xpert.ivy Business Process Management (BPM) unterstützt den gesamten Lebenszyklus von Geschäftsprozessen. BPM-Lösungen liefern Technologie

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

B.4. B.4 Betriebssysteme. 2002 Prof. Dr. Rainer Manthey Informatik II 1

B.4. B.4 Betriebssysteme. 2002 Prof. Dr. Rainer Manthey Informatik II 1 Betriebssysteme Betriebssysteme 2002 Prof. Dr. Rainer Manthey Informatik II 1 Bekannte Betriebssysteme Windows 2000 CMS UNIX MS-DOS OS/2 VM/SP BS 2000 MVS Windows NT Solaris Linux 2002 Prof. Dr. Rainer

Mehr

5.2 Analyse des File Slack

5.2 Analyse des File Slack 5.2 Analyse des File Slack 109 Es gibt an vielen Stellen eines Betriebssystems Fundorte für Gebrauchsspuren oder Hinweise auf Auffälligkeiten. Diese Stellen sollten grundsätzlich aufgesucht und analysiert

Mehr

Betriebssysteme WS 2012/13 Peter Klingebiel, DVZ. Zusammenfassung Kapitel 4 - Datenträger/Dateiverwaltung

Betriebssysteme WS 2012/13 Peter Klingebiel, DVZ. Zusammenfassung Kapitel 4 - Datenträger/Dateiverwaltung Betriebssysteme WS 2012/13 Peter Klingebiel, DVZ Zusammenfassung Kapitel 4 - Datenträger/Dateiverwaltung Zusammenfassung Kapitel 4 Dateiverwaltung 1 Datei logisch zusammengehörende Daten i.d.r. permanent

Mehr

POSIX Echtzeit: Kernel 2.6 und Preempt-RT

POSIX Echtzeit: Kernel 2.6 und Preempt-RT POSIX Echtzeit: Kernel 2.6 und Preempt-RT Slide 1 - http://www.pengutronix.de - 21.01.2007 Echtzeit-Systemplanung Wenn das zeitliche Verhalten spezifiziert ist, kann auch spezifiziert werden, welche Applikationsteile

Mehr

Betriebssysteme Kap A: Grundlagen

Betriebssysteme Kap A: Grundlagen Betriebssysteme Kap A: Grundlagen 1 Betriebssystem Definition DIN 44300 Die Programme eines digitalen Rechensystems, die zusammen mit den Eigenschaften dieser Rechenanlage die Basis der möglichen Betriebsarten

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

Iris Treppner. astro. Wie Trader mit Astrologie die Börse schlagen FBV

Iris Treppner. astro. Wie Trader mit Astrologie die Börse schlagen FBV Iris Treppner astro trading Wie Trader mit Astrologie die Börse schlagen FBV TEIL I Grundzüge des Astro-Tradings 17 KAPITEL 1: ZUM UMGANG MIT DIESEM BUCH Damit Sie in diesem Buch nicht unnötig suchen

Mehr

2. DFG- Workshop 3.1. Erfassung/Bewertung/Transfer. Beitrag von Peter Küsters. Spiegelung. Archiv. Bild 1: Unterschied zwischen FTP und Spiegelung

2. DFG- Workshop 3.1. Erfassung/Bewertung/Transfer. Beitrag von Peter Küsters. Spiegelung. Archiv. Bild 1: Unterschied zwischen FTP und Spiegelung 2. DFG- Workshop 3.1. Erfassung/Bewertung/Transfer Beitrag von Peter Küsters Formen des Datentransfers bei der Erfassung von Websites Im folgenden werden Methoden und Software zur Erfassung vorgestellt.

Mehr

PBS Nearline Analytic Infrastructure - Ein Pilotkundenbericht -

PBS Nearline Analytic Infrastructure - Ein Pilotkundenbericht - PBS Nearline Analytic Infrastructure - Ein Pilotkundenbericht - Überblick Vorstellung Überblick PBS NAI Bericht über Pilottest Vorteile/Nachteile 2 Überblick Vorstellung Überblick PBS NAI Bericht über

Mehr

PowerBridge MSSQL Beta

PowerBridge MSSQL Beta SoftENGINE PowerBridge MSSQL Beta Dokumentation Thomas Jakob 17.04.2011 Inhalt Einrichtung der SQL Umgebung... 3 SQL-Server Installieren... 3 BüroWARE Installieren... 3 PowerBridge-SQL Modus einrichten...

Mehr

AFS Backup und Recover nicht nur für (Legato) NetWorker

AFS Backup und Recover nicht nur für (Legato) NetWorker AFS Backup und Recover nicht nur für (Legato) NetWorker Wolfgang Friebel, DESY 28.9.2006 1 Backup Inhalt Schematischer Ablauf Volle und inkrementelle Backups Backup auf Disk Backup auf Tape Recover Recover

Mehr

Zeit- und ereignisgesteuerte Echtzeitsysteme

Zeit- und ereignisgesteuerte Echtzeitsysteme Zeit- und ereignisgesteuerte Echtzeitsysteme Stephan Braun Stephan.Braun.Hagen@t-online.de PG Seminarwochenende 21.-23. Oktober 2007 1 Überblick Echtzeitsystemmodell Einführung Ereignis- und zeitgesteuerte

Mehr

Umsetzung von Geschäftsprozessen: Workflow-Managementsysteme. Knut Hinkelmann

Umsetzung von Geschäftsprozessen: Workflow-Managementsysteme. Knut Hinkelmann Umsetzung von Geschäftsprozessen: Knut Hinkelmann Das BPMS *) Paradigma Wo liegt unsere Wertschöpfung? Produkte Strategische Entscheidungen Wie erstellen wir unsere Produkte? Geschäftsprozesse Re-Engineering

Mehr

Proseminar Konzepte von Betriebssystem-Komponenten Disk-Caches & Dateizugriff von Athanasia Kaisa

Proseminar Konzepte von Betriebssystem-Komponenten Disk-Caches & Dateizugriff von Athanasia Kaisa Proseminar Konzepte von Betriebssystem-Komponenten Disk-Caches & Dateizugriff von Athanasia Kaisa Massenspeichermedien sind in der Regel gegenüber dem Hauptspeicher eines Rechners viel langsamer. Da Massenspeicher

Mehr