Untersuchung der Skalierbarkeit verschiedener Datenbankmanagementsysteme unter hohen Nutzerzahlen

Größe: px
Ab Seite anzeigen:

Download "Untersuchung der Skalierbarkeit verschiedener Datenbankmanagementsysteme unter hohen Nutzerzahlen"

Transkript

1 Universität Zürich Institut für Informatik Database Technology Research Group Prof. Dr. Carl-Christian Kanne Untersuchung der Skalierbarkeit verschiedener Datenbankmanagementsysteme unter hohen Nutzerzahlen Facharbeit Verfasser Samuel Mezger St. Gallen Betreuer Christian Tilgner Abgabedatum

2

3 Inhaltsverzeichnis 1 Einleitung Aufbau der Arbeit Zur Einordnung der Arbeit Grundlagen und Voraussetzungen Mehrbenutzersynchronisation Transaktionen Historien und typische Fehler Serialisierbarkeit Das Zwei-Phasen-Sperrprotokoll Multi-versioning Multiprogramming limit und lock thrashing Weitere verwendete Begriffe Mehrbenutzersynchronisation in den verwendeten DBMS Mechanismen der Mehrbenutzersynchronisation in SQL Mehrbenutzersynchronisation in DB Mehrbenutzersynchronisation in SQL Server Mehrbenutzersynchronisation in PostgreSQL Messungen Versuchsumgebung Vorgehen Messreihen DB Konfigurationsparameter von DB Vorbereitung von DB DB2, Messreihe 1: Grösse des Pufferspeichers DB2, Messreihe 2: Kardinalität der Datenbasis SQL Server Konfigurationsparameter von MSSQL Vorbereitung von MSSQL MSSQL, Messreihe 1: Grösse des Pufferspeichers MSSQL, Messreihe 2: Kardinalität der Datenbasis MSSQL, Messreihe 3: Anzahl Tupel pro Transaktion PostgreSQL Konfigurationsparameter von Postgres Vorbereitung von Postgres Postgres, Messreihe 1: Grösse des Pufferspeichers Postgres, Messreihe 2: Kardinalität der Datenbasis Fazit der Messungen Zusammenfassung und Ausblick 49 A Detaillierte Messergebnisse 52 A.1 Messreihe A.1.1 DB A.1.2 MSSQL A.1.3 Postgres A.2 Messreihe

4 A.2.1 DB A.2.2 MSSQL A.2.3 Postgres A.3 Messreihe A.3.1 DB A.3.2 MSSQL A.3.3 Postgres A.4 Auslastungsmessungen B Quellcode 152

5 Abbildungsverzeichnis 1 Schema der Versuchsumgebung DB2 Speicher: Übersicht instance_memory DB2 Speicher: detailliert DB2: Durchsatzunterschied cold cache zu hot cache DB2 MR1: Durchsatz bei kleineren Datenbank-Pufferspeichern DB2 MR1: Durchsatz bei grösseren Datenbank-Pufferspeichern DB2 MR1: Antwortzeiten bei verschiedenen Grössen des Datenbank-Pufferspeichers 25 8 DB2 MR1: CPU-Auslastung des Servers bei 64 MB Datenbank-Pufferspeicher DB2 MR1: CPU-Auslastung des Servers bei 768 MB Datenbank-Pufferspeicher DB2 MR2: Rollbacks und aborts bei verschiedenen Kardinalitäten der Datenbasis DB2 MR2: Durchsatz bei verschiedenen Kardinalitäten der Datenbasis DB2 MR2: CPU-Auslastung des Servers bei Kardinalität MSSQL MR1: Durchsatz bei verschiedenen Grössen des Datenbank-Pufferspeichers MSSQL MR1: Antwortzeit bei verschiedenen Grössen des Datenbank-Pufferspeichers MSSQL MR2: Durchsatz bei verschiedenen Kardinalitäten der Datenbasis MSSQL MR2: Rollbacks und aborts bei verschiedenen Kardinalitäten der Datenbasis MSSQL MR3: Durchsatz bei variierter Anzahl Tupeln pro TA MSSQL MR3: Rollbacks und aborts bei variierter Anzahl Tupeln pro TA Postgres: Einfluss von VACUUM FULL und checkpoint Postgres MR1: Durchsatz bei verschiedenen Grössen des Datenbank-Pufferspeichers Postgres MR1: Einfluss der Isolationsstufe bei 128 MB Pufferspeicher Postgres MR1: Antwortzeit bei verschiedenen Grössen des Datenbank-Pufferspeichers Postgres MR2: Rollbacks und aborts bei verschiedenen Kardinalitäten der Datenbasis Postgres MR2: Durchsatz bei verschiedenen Kardinalitäten der Datenbasis

6 Tabellenverzeichnis 1 Kompatibilitätsmatrix mit Intentionssperren Kompatibilitätsmatrix mit Zertifizierungssperren Attribute, die im Benchmark verwendet wurden Variierte Parameter nach Messreihen Fixe Parameter der Messreihe Fixe Parameter der Messreihe Fixe Parameter der Messreihe DB2: Voreinstellungen für die Messungen Postgres: Voreinstellungen für die Messungen

7 Zusammenfassung In dieser Facharbeit werden Transaktionsdurchsatz-Messungen mit Fokus auf Mehrbenutzersynchronisation beschrieben, die für IBM DB2 9.5, PostgreSQL 8.3 und Microsoft SQL Server 28 vorgenommen wurden. In diesen Messungen wurde die Isolationsstufe, der zur Verfügung stehende Datenbank-Pufferspeicher, die Kardinalität der Datenbasis und die Anzahl Operationen pro Transaktion variiert, um deren Einfluss auf den Transaktionsdurchsatz festzustellen. Mit Bezug auf theoretische Grundlagen wird ermittelt, dass zwar Phänomene beobachtet werden können, welche zu erwarten sind, aber Implementationsspezifika der Datenbankmanagementsysteme die Resultate charakterisieren: Erwartete Resultate, wie lock thrashing und Limitierungsphänomene durch I/O und die Rechenleistung des Prozessors, können nachgewiesen werden. Allerdings kann eine I/O-Limitierung auch bei grossem Datenbank-Pufferspeicher auftreten, und nicht alle verwendeten Datenbankmanagementsysteme reagieren gleich auf lock thrashing. Zudem können alle verwendeten Datenbankmanagementsysteme bei höheren Isolationsstufen höheren Durchsatz erreichen. DB2 bricht bei zu grossem Datenbank-Pufferspeicher Verbindungen ab, während SQL Server bei zu kleinem Pufferspeicher ebenso reagiert. Bei PostgreSQL kann festgestellt werden, dass sich der Transaktionsdurchsatz verringert, wenn die Nebeläufigkeit erhöht wird, weil Speicherverbrauch durch den Einsatz von multi-versioning anwächst.

8 Abstract The work presented here describes measurements of transaction throughput for different database management syste that focus on concurrency control. The measurements were taken for IBM DB2 9.5, PostgreSQL 8.3 and Microsoft SQL Server 28. During the measurements, the following parameters were being changed to determine their effect on throughput: the isolation level, the amount of memory available for the database s buffer pool, the database s cardinality and the amount of operations per transaction. When trying to relate the measurements results to the expectations based on theoretical principles, it is found that while some effects show as expected, many phenomena have to be attributed to specific implementations of the different database management syste. Expected results like lock thrashing and throughput-limitations due to I/O-performance or the CPU s processing speed are apparent. Unexpectedly, I/O-performance is a limiting factor not only when small database buffer pools are used, and lock thrashing affects all database management syste in a different way. Furthermore, it is found that all of the used management syste can reach higher throughput numbers at higher isolation levels. DB2 is noted to break connections when the database s buffer pool is chosen too large, while SQL Server does the same when the database s buffer pool is chosen too small. For PostgresSQL, transaction throughput is reduced whenthe level of concurrency is increased. This happens due to the multi-versioning protocol used by PostgreSQL, which leads to an increase in memory consumption under these conditions.

9 1 Einleitung In dieser Facharbeit werden die Reaktionen von drei verschiedenen Datenbankmanagementsystemen (DBMS) auf eine grosse Zahl paralleler Nutzeranfragen untersucht. Bei den untersuchten DBMS handelt es sich um PostgreSQL 8.3, Microsoft SQL Server 28 und IBM DB2 Express-C 9.5. Es gilt, den Einfluss diverser Parameter auf den Transaktionsdurchsatz der DBMS festzustellen, d.h. die Anzahl erfolgreich durchgeführter Transaktionen eines definierten Typs in einer bestimmten Zeit. Variierte Parameter sind die Nutzerzahl, die Isolationsstufe von Transaktionen, die Kardinalität der Datenbasis, die Anzahl Operationen pro Transakion und verschiedene Konfigurationsparameter des jeweiligen DBMS. Es ist das Ziel, die Ergebnisse einer Reihe von Skalierungsbenchmarks aufzuzeigen, zu interpretieren und mit dem zu vergleichen, was anhand theoretischer Grundlagen zu erwarten gewesen wäre. Die praktische Relevanz solcher Versuchsreihen liegt in aktuellen Internet-Anwendungen wie Online Banking oder Auktionsseiten, mit welchen oft tausende Nutzer gleichzeitig verbunden sind und worauf sie Transaktionen ausführen. Obwohl dabei connection pooling eingesetzt wird, ist für optimale Ressourcenausnutzung eine entsprechende Nebenläufigkeit zu verwenden. An Formalem sind typographische Unterschiede zu beachten. Kursiv gesetzte Worte stellen Englische Fachbegriffe dar. Formeln und Variabeln sind ebenfalls hervorgehoben. SQL-Aufrufe und Programmnamen sind in einer nicht proportionalen Schriftart gehalten. 1.1 Aufbau der Arbeit Im Kapitel 2 wird auf theoretische Grundlagen eingegangen. Es folgt in Kapitel 3.1 eine Darstellung der technischen Rahmenbedingungen, unter welchen die Messdaten gewonnen wurden. Damit sollen die Hardware-Restriktionen ersichtlich gemacht und ein Überblick über die benutzte Software geboten werden. Im Kapitel 3.2 wird Aufbau sowie der grundsätzliche Ablauf der Versuche beschrieben. Im Kapitel 3.3 werden die verwendeten Parameter und Versuchsergebnisse dokumentiert sowie mit Bezug auf die theoretischen Grundlagen interpretiert. Kapitel 4 beinhaltet eine Zusammenfassung der Erkenntnisse. Im Anhang A werden die Messergebnisse detailliert dargestellt, der Anhang B beinhaltet die benutzten Shellskripts. 1.2 Zur Einordnung der Arbeit Eine sogenannte Facharbeit ist im Rahmen des Bachelor-Nebenfachstudiu der Informatik zu verfassen, wenn das Hauptfach in der philosophischen Fakultät belegt wird. Die Facharbeit umfasst Kreditpunkte im Wert von 36 Arbeitsstunden, und dieses Dokument stellt den schriftlichen Teil dieser Arbeit dar. Die anderen beiden Komponenten waren eine mündliche Prüfung zum Thema Mehrbenutzersynchronisation und praktische Arbeit in der Organisation, Durchführung und Auswertung der Versuche. 1

10 2 Grundlagen und Voraussetzungen Damit Erwartungen an die Messergebnisse formuliert und verifiziert werden können, sowie um die verwendeten Begriffe einzuführen, werden in Kaptiel 2.1 theoretische Grundlagen dargelegt. Dabei wird berücksichtigt, dass der gleichzeitige Zugriff vieler Benutzer auf eine Datenbank das Hauptgebiet ist, welches von den Messungen abgedeckt wird. Der Mehrbenutzerbetriebs erfordert eine Synchronisation, welche sicherstellt, dass die erwarteten Ergebnisse ohne gegenseitige Beeinflussung fehlerfrei geliefert werden. Es wird gezeigt, wie dies im Allgemeinen funktioniert und wie es in Grundlagentexten zu DBMS beschrieben wird. Kapitel 2.2 beinhaltet Begriffe, welche im vorhergehenden Kapitel nicht abgedeckt wurden. Im Kapitel 2.1 wird gezeigt, inwieweit der SQL92-Standard Mehrbenutzersynchronisation beinhaltet. Zudem werden die Uetzungen der Grundlagen und des Standards durch die DBMS vorgestellt, welche für die Messungen verwendet wurden. 2.1 Mehrbenutzersynchronisation Dieses Unterkapitel basiert auf theoretischen Grundlagen zur Mehrbenutzersynchronisation und erklärt grundlegende Konzepte sowie Mechanismen zu deren Implementierung. Um die Leistung eines Computersyste optimal nutzen zu können, bietet sich der Betrieb mit mehreren parallel oder pseudo-parallel ablaufenden Programmen an (multiprogramming). So können Zeiten, in welchen der Prozessor nicht beschäftigt wäre, weil er beispielsweise auf Daten eines Speichers wartet, mit anderen Berechnungen gefüllt werden. Datenbanksysteme können als einzelne Programme oder mehrere zusammengehörige Prozesse betrachtet werden, die von mehreren Nutzern zugleich verwendet werden können. Sie profitieren von der Nebenläufigkeit in einem besonderen Masse, weil in DBMS oft Daten vom Hintergrundspeicher geladen oder vom Haupt- in den Hintergrundspeicher zurückgeschrieben werden müssen, was vergleichsweise langsam geschieht und für den Prozessor Wartezeit bedeutet. Werden die Wartezeiten für die Berechnungen anderer Transaktionen verwendet, können im gleichen Zeitfenster mehr Transaktionen abgearbeitet werden. So kann durch effizientere Ressourcennutzung eine höhere Reaktionsgeschwindigkeit aus Nutzersicht erreicht werden, auch wenn die Zeit zur Abarbeitung einer Transaktion unter Utänden erhöht wird, wie aus [12, S. 299, Abb. 11.1] ersichtlich ist Transaktionen Wenn von Transaktionen gesprochen wird, so ist die Rede von einer Bündelung mehrerer Datenbankoperationen, die in einem Mehrbenutzersystem ohne unerwünschte Einflüsse durch andere Transaktionen als Einheit fehlerfrei ausgeführt werden sollen [12, S. 269]. In dieser Definition sind zwei der so genannten ACID-Eigenschaften angesprochen worden, welche das Transaktionskonzept bestimmen. ACID ist ein Akronym, das für Eigenschaften steht, welche einen reibungslosen Betrieb garantieren, auch wenn viele Benutzer gleichzeitig Anfragen an die Datenbank stellen [12, S. 273]. Atomicity Eine Transaktion ist eine unteilbare Einheit, die entweder ganz ausgeführt wird oder gar nicht. Consistency Wenn eine Transaktion abgeschlossen ist, sind sämtliche Bedingungen an die Daten eingehalten. Isolation Jede Transaktion läuft für sich allein und wird nicht von anderen Transaktionen beeinflusst, die ganz oder teilweise zeitlich überlappend, also verzahnt ausgeführt werden. 2

11 2.1 Mehrbenutzersynchronisation Durability Wenn eine Transaktion als erfolgreich beendet gemeldet wurde, müssen die Änderungen in der Datenbasis festgeschrieben sein. Tritt ein Systemfehler auf, muss der durch die Transaktion eventuell geänderte Zustand der Datenbasis wiederherstellbar sein. Ein weiterer Punkt, der in der obigen Definition angesprochen wird, dass eine Transaktion aus mehreren Datenbankoperationen bestehe, muss, oberflächlich betrachtet, nicht zutreffen. Erstens steht es einem Benutzer frei, nur einen einzelnes SQL-Statement in eine Transaktion zu fassen. Zweitens interpretieren viele DBMS jedes Statement, das nicht innerhalb einer explizit deklarierten Transaktion steht, implizit als eigene Transaktion. Dies ist bei allen untersuchten DBMS der Fall ([4] für DB2 via JDBC, [14] für MSSQL und [2] für Postgres). Im Mehrbenutzerbetrieb ist ein solches Vorgehen deswegen sinnvoll, weil auch einzelne Statements gegen die ACID-Bedingungen verstossen können, wenn mehrere verzahnt ausgeführt werden, denn einzelne Statements lösen nicht atomare Operationen aus. Die Definition genügt für die Zwecke dieser Arbeit auch in Hinblick auf ihre Einschränkung auf Datenbanksysteme und Operationen. Dass Transaktionen als abstraktes Konzept für Applikationen transparent sind, wie [23, S. 4] feststellt, gilt für diese Arbeit nicht grundsätzlich, weil teilweise auf die Mechanismen hinter den Transaktionen und den Einfluss von Transaktionsparametern auf die erhaltenen Messergebnisse eingegangen wird. Die weniger strikte Einhaltung des ACID-Paradigmas durch die Verringerung der Isolation durch die Verwendung von Isolationsstufen bedingt auch, dass man sich der Auswirkungen bewusst ist, welche im Unterkapitel 2.3 erläutert werden: Man kann sich beim Einsatz von Isolationsstufen nicht, wie wenn es vollständig transparent wäre, gänzlich auf die fehler- und konfliktfreie Ausführung von Transaktionen verlassen. Was für ein Transaktionssystem ebenfalls relevant ist, aber in der Definition nicht angesprochen wurde, ist die Performance. Angegeben wird sie in Durchsatz, gemessen in erfolgreichen Transaktionen pro Zeiteinheit, und in Antwortzeit, gemessen in der Zeitspanne vom Befehl, eine Transaktion zu starten, bis zur ihrem erfolgreichen Abschluss [23, S. 26 und 785]. Das sind auch die Masse, welche im Kapitel 3 verwendet werden Historien und typische Fehler Wenn mehrere Benutzer gleichzeitig auf die gleiche Datenbank zugreifen und dort Änderungen vornehmen können, kann dies verschiedene Probleme verursachen. Davon können die Bereiche der Atomarität und der Konsistenz betroffen sein, und zwar dann, wenn die Bedingung der Isolation nicht eingehalten wird. So können sich beispielsweise nicht abgeschlossene Transaktionen auf andere, parallel ausgeführte, auswirken. Die typischen Fehlerklassen, welche in [12, S. 3 f.] genannt werden, sind lost update, dirty read und phantom read. [2, S ] nennt einige andere, dennoch damit zusammenhängende Beispiele, wie unrepeatable read, das Problem der falschen Summenbildung und temporäre Aktualisierungen. Um einige dieser Fehlerfälle, welche für die in Unterkapitel erwähnten verschiedenen Isolatiosstufen der DBMS relevant sind, illustrieren zu können, wird das Konzept der Darstellung einer Historie eingeführt. Eine Historie bildet den Ablauf einer oder mehrerer verzahnter Transaktionen ab, indem die verwendeten Befehle chronologisch aufgelistet werden. Hier genügt eine verkürzte Darstellung, indem eine geordnete Reihenfolge von Lese- und Schreibzugriffen, die einer Transaktion zugeordnet sind, auf symbolisch benannte Daten wie folgt notiert wird: X 1 T (D1 )! X 2 T (D2 )! E T X steht für einen Zugriff und kann die Werte r oder w annehmen. r bedeutet einen lesenden, w einen schreibenden Zugriff. Das Subskript T repräsentiert die Transaktion, die Argumente D ein Datum. E steht für den Abschluss einer Transaktion und kann die Werte c für commit oder a für abort annehmen. Der Pfeil kennzeichnet eine transitive Ordnungsrelation, welche die Reihenfolge 3

12 2.1 Mehrbenutzersynchronisation der Operationen wiedergibt. Relevant ist diese bei sogenannten Konfliktoperationen, womit jede Folge von zwei Operationen auf dem gleichen Datum bezeichnet wird, von welchen mindestens eine ein Schreibzugriff ist [12, S. 36 f.], [2, S. 424 f.]. Wird multi-versioning eingesetzt kann dies unter Utänden anders definiert sein, wie in Kapitel gezeigt wird. Lost updates können durch folgende Operationsreihenfolge verursacht werden: r 1 (A)! r 2 (A)! w 2 (A)! w 1 (A). Die Änderung am Datum A durch die Transaktion 2 wird also von Transaktion 1 überschrieben. An diesem Beispiel lässt sich auch erkennen, wie die Reihenfolge bei Operationen, die keine Konfliktoperationen sind, keinen Einfluss auf das Ergebnis hat. So repräsentiert r 2 (A)! r 1 (A)! w 2 (A)! w 1 (A) einen äquivalenten Ausschnitt aus einer Historie. Es ist deshalb nur ein Ausschnitt, weil beide Transaktionen nicht abgeschlossen sind. Dirty reads werden in Historienausschnitten folgender Art ersichtlich, welche Lesen von nicht durch ein commit bestätigten Änderungen darstellen: w 1 (A)! r 2 (A), wobei Probleme auftreten, wenn Transaktion 1 nicht erfolgreich beendet wird, w 1 (A) also rückgängig gemacht wird, oder Transaktion 1 weitere Änderungen an A vornimmt. Unrepeatable reads treten bei mehrfachen Lesezugriffen auf Daten, die sich in der Zwischenzeit geändert haben, auf: r 1 (A)! w 2 (A)! r 1 (A). Phantom reads können ähnlich betrachtet werden wie unrepeatable reads, wobei A dabei für einen Datenbereich steht, und w(a) für ein Hinzufügen von Werten zum Bereich Serialisierbarkeit Jedes der genannten Probleme kann nur auftreten, weil die verzahnt ausgeführten Transaktionen nicht voneinander isoliert sind. Durch eine Utellung der Reihenfolge der Konfliktoperationen können sie gelöst werden. Der Scheduler des jeweiligen DBMS hat die Aufgabe, die Operationen so anzuordnen, dass die Reihenfolge der Konfliktoperationen mit denen einer seriellen Ausführung der Transaktionen identisch ist. Eine Historie ist äquivalent zu einer anderen, wenn die Reihenfolgen der Konfliktoperationen identisch sind 1. Serialisierbarkeit ist gegeben, wenn eine Historie äquivalent zu einer seriellen Historie ist ([12, S. 38]). Die Reihenfolge der Konfliktoperationen bestimmt die Reihenfolge der Transaktionen in der äquivalenten seriellen Historie. Dadurch sind Historien, welche lost updates oder unrepeatable reads enthalten, inhärent nicht serialisierbar, weil keine äquivalente serielle Historie existieren kann. Zudem soll der Scheduler Rücksetzbarkeit garantieren. Rücksetzbar, auch wiederherstellbar genannt, ist eine Historie dann, wenn eine Transaktion erst dann ihr commit durchführt, wenn alle Transaktionen, von denen sie gelesen hat, beendet sind [12, S. 31]. Damit ist sichergestellt, dass ein Transaktionsabbruch keinen Einfluss auf bereits beendete Transaktionen hat. Wenn das Zurücksetzen einer Transaktion zum Rücksetzen anderer Transaktionen führt, die von ihr lesen, spricht man von kaskadierendem Rücksetzen. Dazu kann es kommen, wenn Daten gelesen werden, bevor die Transaktion als commited oder aborted gemeldet wurde. Eine weitere Einschränkung, die besonders der Wiederstellung nach einem Fehler der Datenbank erleichtert, ist die Erstellung von strikten Ausführungsplänen. Hier ist nicht nur das Lesen, sondern auch das Schreiben eines Datu nicht erlaubt, bis die letzte Transaktion, welche dieses Datum schreibt, beendet ist [2, S. 426 f.]. Historien, welche kaskadierendes Rücksetzen vermeiden, sind immer rücksetzbar [12, S. 312, Abb ]. Serialisierbarkeit schliesst diese Fälle der Rücksetzbarkeit und des Vermeidens kaskadierenden Rücksetzens nicht zwingend mit ein, und das Einhalten dieser Bedingungen erzeugt noch keine Serialisierbarkeit. Aus Gründen der Fehlerfreiheit und der Wiederherstellbarkeit wird eine Kombination von Serialisierbarkeit und Vermeidung kaskadierenden Rücksetzens bevorzugt. Eine Möglichkeit eine solche Kombination zu erreichen stellt die strikte oder rigorose Variante des Zwei-Phasen-Sperrprotokolls dar, wie im Unterkapitel beschrieben wird. 1 Mit äquivalent ist in dieser Arbeit generell die Konfliktäquivalenz angesprochen, wie sie in [12, S. 37 f.] und [2, S. 43 f.] dargestellt ist. [23, S. 93] liefert eine formale Definition. 4

13 2.1 Mehrbenutzersynchronisation In gewissen Fällen ist Serialisierbarkeit, welche nur mit grösserem Aufwand zu erreichen ist, keine nötige Voraussetzung für ein korrektes Verhalten. Das gilt wegen der Kommutativität der verwendeten mathematischen Operationen z.b. für Debit-/Kredit-Transaktionen, in welchen Werte nur additiv geändert werden. Es genügen hierbei schwächere Definitionen der Serialisierbarkeit [2, S. 438] Das Zwei-Phasen-Sperrprotokoll Der Scheduler kann, statt mögliche Historien aus Anfragen im Voraus zu berechnen, Serialisierbarkeit z.b. mittels sperrbasierter Synchronisation gewährleisten. Für den Zugriff auf jedes Datum muss eine Sperre (lock) erworben werden, wobei zwischen shared lock für lesende und exclusive lock für schreibende Zugriffe unterschieden wird. Ein exclusive lock darf nur für noch nicht gesperrte Daten gewährt werden, und wenn ein exclusive lock für ein Datum gewährt wurde, dürfen keine weiteren Sperren für dieses Datum vergeben werden. Wird eine Sperre nicht gewährt, muss die anfragende Transaktion an dieser Stelle warten, bis die Sperre wieder frei ist und ihr zugesprochen wird. Sperren können gemäss dem Zwei-Phasen-Sperrprotokoll (two phase locking, 2PL) nur so vergeben werden, dass eine einleitende Wachstuphase exisitiert, während der keine Sperren freigegeben werden können, gefolgt von einer Schrumpfungsphase, während der keine Sperren mehr erworben werden können. Rücksetzbarkeit und die Vermeidung von kaskadierendem Rücksetzen wird nur garantiert, wenn striktes oder rigoroses 2PL verwendet wird. Beim strikten 2PL wird die Schrumpfungsphase so implementiert, dass die Freigabe der exclusive locks erst nach dem commit oder abort einer Transaktion erfolgt. Beim rigorosen 2PL, welches bei [23, S. 144] als strong bezeichnet wird, werden alle Sperren erst nach dem commit oder abort einer Transaktion freigegeben. Die rigorose Variante schränkt die Nebenläufigkeit stärker ein, ist aber laut [2, S. 453] leichter zu implementieren. Bei allen bisher genannten Varianten des 2PL können Verklemmungen (deadlocks) auftreten. Eine Verklemmung liegt dann vor, wenn zwei Transaktionen gegenseitig auf Ressourcen warten, die von der jeweils anderen gesperrt sind. Um Verklemmungen zu vermeiden, kann konservatives 2PL benutzt werden. Bei [12, S. 318] wird dabei von preclaiming gesprochen, während [23, S. 142] beide Begriffe verwendet. Konservatives 2PL wird dann angewendet, wenn die Wachstuphase daraus besteht, dass alle Sperren zu Beginn der Transaktion erworben werden, und keine Sperre gehalten wird, bis alle Sperren erworben werden können [12, S ], [2, S ]. Da dies bedingen würde, dass alle Lese- und Schreiboperationen im Voraus deklariert werden, werden üblicherweise andere Mechanismen zur Auflösung von Verklemmungen eingesetzt. Wartegraphen sind eine Möglichkeit, Verklemmungen zu erkennen. Indem festgestellt wird, welche Transaktion auf Ressourcen wartet, die von welcher anderen Transaktion gehalten werden, können zyklische Abhängigkeiten erkannt werden und blockierende Transaktionen gezielt zurückgesetzt werden. Da dieses Verfahren relativ aufwändig ist, kann auch auf ein timeout gewartet und jede Transaktion, die es erreicht, zurückgesetzt werden. Werden Zeitstempel (timestamps) eingesetzt, können die wound-wait- oder wait-die-strategien eingesetzt werden. Bei ersterer wird eine jüngere Transaktion zurückgesetzt, die eine Ressource besetzt, auf die eine ältere Transaktion wartet. Bei letzterer wird eine jüngere Transaktion zurückgesetzt, die auf eine Ressource wartet, welche von einer älteren Transaktion besetzt ist. Zurückgestzte Transaktionen werden mit ihrem originalen Zeitstempel neu gestartet. Die letzten drei Methoden garantieren nicht, dass nur Abbrüche erfolgen, in welche Verklemmungen involviert sind [2, S. 454 f.]. Bisher wurde generell von Sperren gesprochen, ohne zu spezifizieren, was genau gesperrt wird. Die Granularität kann beim multiple-granularity-locking (MGL) unterschiedlich gewählt werden. Üblicherweise ist die Tupelebene die feinste umgesetzte Sperrgenauigkeit. Es folgen Seiten, Segmente und Datenbasis. Eine Seite ist eine physische Speichereinheit, welche mehrere Tupel enthalten kann. Ein Segment ist eine logische Einheit aus mehreren Seiten. Wird auf einer Ebene 5

14 2.1 Mehrbenutzersynchronisation eine Sperre angebracht, so erhalten alle darüberliegenden Ebenen eine Intentionssperre der jeweiligen Sperrart (shared oder exclusive). Unter welchen Bedingungen welche Sperren möglich sind, zeigt die Kompatibilitätsmatrix in Tabelle 1. Die oberste Zeile enthält die bestehende Sperre, die Spalte links aussen die neu angeforderte, wobei S für shared lock, X für exclusive lock steht und I eine entsprechende Intentionssperre. IS steht für intention share und bezeichnet eine Sperre, welche auf den Ebenen gesetzt wird, unter welchen ein shared lock folgt. IX steht für intention exclusive und bedeutet das Analoge für exclusive locks. Tabelle 1: Kompatibilitätsmatrix mit Intentionssperren - S X IS IX S J J n J n X J n n n n IS J J n J J IX J n n J J Durch die verschiedenen Granularitäten wird es möglich, Parallelität von Transaktionen und Ressourcenbelastung durch zu viele Sperren gegeneinander abzuwägen. Müssen zu viele Sperren verwaltet werden, kann das DBMS eine Sperreskalation (lock escalation) durchführen, was eine Sperre auf einer höheren als der eigentlich angeforderten Ebene bewirkt [12, S ]. Um phantom reads verhindern zu können, müssen Indexbereiche, oder, falls nicht über Indizes gesucht wird, Tupelbereiche mit gewissen Attributswerten gesperrt werden können. Letzteres wird predicate locking [23, S ] genannt und funktioniert über die Selektionsbedingungen von INSERT, UPDATE und DELETE-Anweisungen [12, S. 325 und ]. Es existieren auch Synchronisationsmechanismen, die ohne Sperren auskommen, sondern mir Zeitstempeln funktionieren, wie in [12, S ] und [23, S. 166 f.] sowie in einem Teil des Kapitels beschrieben wird, oder die mit optimistischem Scheduling arbeiten, wie in [23, S ] und [12, S. 373 f.] beschrieben wird Multi-versioning Bei Ansatz, der multi-versioning genannt wird, wird im Falle einer Schreiboperation eine ältere Version der Daten behalten, auf welche nach wie vor lesend zugegriffen werden kann. Dies kann zu erhöhtem Speicherverbrauch führen. Wird mit Zeitstempeln gearbeitet, erhält das Datum A für read_ts(a) den Wert des Zeitstempels der zuletzt lesend auf A zugreifenden Transaktion. Write_ts(A) bekommt den Zeitstempel der Transaktion zugewiesen, welche diese Version von A geschrieben hat. Die Serialisierbarkeit wird erhalten, indem eine schreibend zugreifende Transaktion T zurückgesetzt wird, wenn die neueste Version von A älter als T ist, aber read_ts(a) einen jüngeren Wert als T aufweist. Eine lesend zugreifende Transaktion T liest von der Version von A, welche den jüngsten Wert von write_ts(a) hat, der älter oder gleich alt wie T ist. Read_ts(A) wird nur angepasst, wenn T jünger als der bestehende Wert von read_ts(a) ist. Wie beim Vorgehen ohne multi-versioning kann statt mit Zeitstempeln mit Sperren gearbeitet werden. Zu den shared locks S und den exclusive locks X kommt ein dritter Typ hinzu, die Zertifizierungssperren Z. In diesem Falle wird für S besser von Lese-, für X besser von Schreibsperren statt von shared und exclusive locks gesprochen. In Tabelle 2 enthält die oberste Zeile die bestehende Sperre, die Spalte links aussen die neu angeforderte. In der Tabelle 2 ist zu erkennen, dass bei multi-versioning r 1 (A) möglich ist, auch wenn für Datum A bereits eine Schreibsperre der Transaktion 2 existiert, nicht aber w 1 (A). Transaktion 1 liest 6

15 2.1 Mehrbenutzersynchronisation Tabelle 2: Kompatibilitätsmatrix mit Zertifizierungssperren - S X Z S J J J n X J J n n Z J n n n im Falle von r 1 (A) von einer aktuell als commited markierten Version von A. Will die schreibende Transaktion 2 ein commit ausführen, benötigt sie Zertifizierungssperren für sämtliche Daten, für die sie momentan Schreibsperren hält, im Beispiel also für A. Diese können erst gewährt werden, wenn sämtliche Transaktionen, die das Datum A lesen, beendet sind und die Lesesperren auf A freigegeben haben. Zertifizierungssperren sind somit vollständig exklusiv, wodurch erreicht wird, dass bei Einsatz des 2PL-Protokolls, kombiniert mit der Tatsache, dass nur Daten gelesen werden können, die commited sind, Serialisierbarkeit garantiert und kaskadierendes Rücksetzen vermieden wird [2, S. 461 f.], [23, S ]. Konfliktoperationen sind für diese Art der Nebenläufigkeitskontrolle nur noch Lese- gefolgt von Schreiboperationen auf dem gleichen Datum, unabhängig von dessen Version. Dadurch wird Serialisierbarkeit durch die Existenz einer seriellen monoversion Historie mit der gleichen Abfolge von Konfliktoperationen definiert [23, S ]. Als monoversion wird eine Historie dann bezeichnet, wenn die Version von gelesenen Daten mit der Version identisch ist, welche sie durch die letzte vorhergehende Schreiboperation erhalten haben. Eine Beispielausschnitt aus einer Historie dazu ist w 1 (A 1 )! r 2 (A 1 ), während in einer beliebigen multi-version-historie auch w 1 (A 1 )! r 2 (A ) einen möglichen Ausschnitt darstellt [23, S. 189] Multiprogramming limit und lock thrashing Durch parallele Ausführung mehrerer Transaktionen können die vorhandenen Ressourcen eines DBMS besser ausgenutzt werden und der Durchsatz optimiert werden. Zugleich werden die Stellen zahlreicher, an welchen die im Unterkapitel erläuterten Probleme auftreten können, da die Kombinationsmöglichkeiten und somit die zu berücksichtigenden Abfolgen von Konfliktoperation zunehmen. Der Verwaltungsaufwand kann den Gewinn durch die Nebenläufigkeit wieder relativieren. Deswegen kann es sinnvoll sein, die Zahl der gleichzeitigen Transaktionen zu begrenzen, was als multiprogramming limit (MPL) bezeichnet wird. Welche Grenze eine sinnvolle Wahl darstellt, ist abhängig von der Art der Anfragen und von der verwendeten Hardware. Wenn sich evaluieren lässt, welches der am deutlichsten limitierende Faktor ist, lässt sich die Performance gezielt anheben und der Wert für ein MPL erhöhen, wie in [22] empirisch gezeigt wird. Mögliche Faktoren, welche von [22] evaluiert werden, sind I/O-Operationen, die Rechenleistung der CPU oder eine hohe Anzahl an Sperren. Man spricht von lock thrashing, wenn sich der Durchsatz bei Erhöung der Nebenläufigkeit dadurch verringert, dass die Wartezeit auf Sperren superlinear anwächst. Befinden sich Transaktionen zudem in Verklemmungen, können weitere Transaktionen, die auf deren Ressourcen warten aber selbst nicht an der Verklemmung teilnehmen, ebenfalls nicht fortgesetzt werden, wodurch der Effekt weiter verstärkt wird. Verklemmungen sind jedoch nicht allein für lock thrashing verantwortlich, wie in [23, S ] betont wird, wo das Phänomen allgemeiner als data contention thrashing bezeichnet wird. Diese allgemeinere Formulierung berücksichtigt, dass analoge Probleme beim Scheduling anderer Ressourcen auch auftreten können. Eine von [23, S. 371] angegebene Grenze liegt bei 3% blockierter Transaktionen, bevor thrashing einsetzt. Um die Wahrscheinlichkeit von Konflikten und Verklemmungen abzuschätzen, nennt [1, S. 29] die folgenden Formeln: P conflict = x2 n d 7

16 2.2 Weitere verwendete Begriffe P deadlock = x4 n d 2 P steht für die Wahrscheinlichkeit, x ist die Anzahl exclusive locks pro Transaktion, n die Anzahl gleichzeitig ausgeführter Transaktionen und d die Anzahl Objekte, die gesperrt werden können. Bei Sperren auf Tupel-Ebene ist d somit die Kardinalität der Datenbasis. Wenn man die Kardinalität der Datenbasis erhöht, Sperranforderungen einer feineren Granularität verwendet oder die Transaktionskomplexität verringert, verzögert sich also der Zeitpunkt, zu dem lock thrashing einsetzt und das maximal sinnvolle MPL wird erhöht. Gleichzeitig werden je nach Art der Transaktionen bei feinerer Granularität mehr Sperren nötig. Je höher die Sperrenanzahl, was neben der Art der Transaktionen auch durch die gewählte Isolationsstufe beeinflusst wird, wie im Unterkapitel 2.3 gezeigt wird, desto niedriger wird wiederum das sinnvolle MPL. Transaktionen, die gestartet werden sollen, nachdem das MPL bereits erreicht ist und die dadurch auf ihre Bearbeitung warten müssen, können durch das DBMS selbst oder gegebenenfalls durch einen externen scheduler in queues gehalten werden. Diese können komplexe Datenstrukturen sein und Kommunikationsprotokolle einzuhalten haben. Verschiedene Implementationsansätze sind bei [3, S ] aufgeführt, konkrete Versuche bei [22]. Weil für alle in den Messungen von Kapitel 3 berücksichtigten DBMS kein direkter Zugriff auf das intern verwendete MPL gefunden werden konnte, müssen im Rahmen dieser Arbeit Annahmen getroffen werden, wenn über MPL oder thrashing geschrieben wird. Anhand der Konfigurationsparameter, welche die Anzahl gleichzeitiger Verbindungen festlegen, sowie jenen, welche die Anzahl Sperren einschränken, können Grenzen festgelegt werden. So repräsentiert in den Versuchen von Kapitel 3 die Anzahl Threads die maximale Menge gleichzeitig ausgeführter Transaktionen, ein Rückschluss, der auch in [22] gemacht wird, wo die Zahl verbundener Clients als MPL-Mass impliziert wird. Die Menge an Sperren wird in den Versuchen von Kapitel 3 nicht per Parameter beschränkt. Wie die entsprechenden Parameter genau bezeichnet und wie man von ihnen Gebrauch machen könnte, wird in den DBMS-spezifischen Unterkapiteln von 2.3 gezeigt. 2.2 Weitere verwendete Begriffe Neben den Begriffen, welche durch die theoretischen Grundlagen der Mehrbenutzersynchronisation vorgegeben sind, müssen zum Verständnis der Arbeit weitere Definitionen berücksichtigt werden. Diese sind in diesem Kapitel ohne weitere Gliederung aufgeführt. Unter einem Checkpoint wird das Zurückschreiben aller zuvor noch nicht in den Hintergrundspeicher abgelegten Änderungen aus der Transaktions-Logdatei verstanden [23, S. 477]. Mit snapshot ist ein konsistenter Datenbankzustand zu einem bestimmten Zeitpunkt gemeint [2, S. 42]. Mit Versuch oder Benchmark wird ein Durchlauf der Java-Applikation bezeichnet, der vier Minuten dauert. Während eines Versuchs werden keine Parameter geändert. Am Ende eines Versuchs werden die gemessenen Performance-Werte gespeichert. Eine Messung bezeichnet eine Folge von Versuchen. Innerhalb einer Messung werden Versuche mit steigender Anzahl Verbindungen durchgeführt, alle anderen Parameter werden nicht geändert. Eine Messreihe besteht aus mehreren Messungen mit verschiedenen Parametern. Grundsätzlich ist mit Datenbasis die Menge an gespeicherten Daten gemeint, die vom DBMS verwaltet wird, wie [12, S. 17] festlegt. In dieser Arbeit wird damit die Menge an Daten bezeichnet, die innerhalb desjenigen Bereichs aller vorhandenen Daten liegt, auf welchen das Benchmark- Programm in einem Versuch Zugriff hat. Der Datenbank-Pufferspeicher ist ein Teil des Arbeitsspeichers, der für das DBMS reserviert ist. Es werden Seiten von Tupeln aus dem Hintergrundspeicher hinein geladen, auf welchen erst dann Operationen ausgeführt werden können. Geänderte Tupel müssen wieder zurück in den Hintergrundspeicher geschrieben werden [12, S ]. 8

17 2.3 Mehrbenutzersynchronisation in den verwendeten DBMS Von cold cache ist dann die Rede, wenn eine Messung auf einem DBMS ausgeführt wird, dessen Datenbank-Pufferspeicher zu Beginn noch nicht gefüllt ist. Sind alle Daten, die für eine Operation benötigt werden, bereits in den Pufferspeicher geladen, wird der Zustand hot cache genannt. 2.3 Mehrbenutzersynchronisation in den verwendeten DBMS Dieses Unterkapitel basiert nicht mehr auf theoretischen Grundlagetexten, sondern auf der Definition von SQL und den Benutzerhandbüchern der drei DBMS. Es dient dazu, aufzuzeigen, wie die Funktionsweise diverser Einstellungen intendiert ist. Damit können erstens Abschätzungen ihrer Auswirkungen erstellt werden, womit die Ergebnissen aus dem Kapitel 3 verglichen werden können. Zweitens sind diese Informationen die Grundlagen für die Wahl der Messreihen und der Grundeinstellungen der DBMS sowie des Benchmark-Program für die Versuche Mechanismen der Mehrbenutzersynchronisation in SQL Der SQL92-Standard definiert vier Isolationsstufen für Transaktionen. Angegeben werden sie explizit als Teil einer SQL-Transaktionsanweisung SET TRANSACTION ISOLATION LEVEL <level> oder als Parameter, falls aus einer anderen Programmumgebung ein Interface verwendet wird, wie es beim verwendeten Programm mit JDBC der Fall ist. Isolationsstufen sind eingeführt worden, um Transaktionen schneller ausführen zu können, als wenn Serialisierbarkeit Voraussetzung jeder Transaktion wäre. Zudem gibt es Fälle, wo auch ohne Serialisierbarkeit ein korrektes Ergebnis garantiert ist, wie die im Unterkapitel erwähnten Debit-/Kredit-Transaktionen. Soll nur ein grober Überblick über gewisse Datenbankaspekte gewonnen werden, ist ein genaues Resultat nicht eine Verschiebung anderer Transaktionen wert [2, S ], [12, S ]. Read uncommited Diese Einstellung ist lediglich bei rein lesenden Transaktionen erlaubt und schränkt den Lesezugriff auf Daten durch andere Transaktionen nicht ein. Es werden keine Sperren benötigt. Sämtliche Problemtypen, die in Kapitel 2.1.2, können auftauchen. Read commited Bei dieser Stufe werden nur bestätigte Werte gelesen, unrepeatable reads werden jedoch nicht verhindert. Repeatable read Phantom reads können durch parallele Änderungstransaktionen nach wie vor auftreten. Serializable Alle genannten Fehlerquellen können nicht mehr auftreten. Serialisierbarkeit ist dadurch laut [2, S. 439] nicht gewährleistet, [12, S. 333] hingegen befindet die Stufe serializable als serialisierbar. Wie diese Stufen implementiert werden, ist den Herstellern der DBMS überlassen, wobei garantiert werden muss, dass die jeweils angewandte Isolationsstufe mindestens den Definitionen entspricht. Ein Hersteller ist nicht verpflichtet, für SQL92-Kompatibilität alle Stufen einzubauen, lediglich serializable ist durch die genannte Einschränkung Pflicht, da bei einer deklarierten Isolationsstufe von serializable auch mindestens diese resultieren muss Mehrbenutzersynchronisation in DB2 9.5 IBM DB2 9.5 (im Folgenden DB2) verwendet vom Standard abweichende Bezeichnungen und Konzepte für die Isolationsstufen von Transaktionen, wie in [8] ausgeführt wird. Transaktionen werden als Arbeitseinheiten (units of work, UOW) bezeichnet. Es wird auf eine sperrbasierte Synchronisation zurückgegriffen, welche neben shared und exclusive auch update locks einsetzt. Normalerweise werden die Sperren auf Tupel-, nach einer Sperreskalation auf Tabellenebene gesetzt. 9

18 2.3 Mehrbenutzersynchronisation in den verwendeten DBMS Dabei funktionieren shared locks wie gewohnt, wobei sie bei DB2 share locks genannt werden, exclusive locks hingegen lassen Lesezugriffe durch Transaktionen im niedrigsten isolation level zu. Der zusätzliche Sperrtyp, update lock, liegt zwischen den beiden anderen und erlaubt Lesezugriff auf die gesperrten Daten, ausser die Transaktionen, welche auf die entsprechende Zeile zugreifen, haben deklariert, dass sie diese aktualisieren wollen. Die DB2 eigenen Isolationsstufen, welche teilweise vom zeilenweisen Vorgehen mit cursors ausgehen, sind folgendermassen definiert: Uncommited read (UR) Während gewisser Leseoperationen erlaubt es diese Isolationsstufe, dass gelesene und zu lesende Daten verändert werden. Alle anderen Anweisungen verhalten sich wie bei cursor stability. Der Unterschied zum read uncommited des SQL-Standards ist, dass auch schreibende Transaktionen diese Isolationsstufe verwenden können, wobei diese sich automatisch wie unter der nächsthöheren Isolationsstufe verhalten. Das gleiche gilt für einige Leseoperationen. Cursor stability (CS) Für jede Zeile, auf die aktuell zugegriffen werden soll, wird in diesem Moment mindestens ein shared lock benötigt. Gelesene Daten werden sofort wieder freigegeben. Zeilen, die von anderen Transaktionen geändert wurden, dürfen nicht gelesen werden, bis diese Transaktionen beendet sind. Diese Stufe ist vergleichbar mit read commited des SQL- Standards. Read stability (RS) Jede Zeile, auf die im Lauf der UOW zugegriffen wird, benötigt mindestens ein shared lock. Zeilen mit einem shared lock können bis zum Ende der UOW nicht von anderen Transaktionen geändert werden, ausser es wird ein cursor geschlossen, dessen CLOSE- Statement mit der Option WITH RELEASE deklariert wurde. Es kann auf keine Zeilen zugegriffen werden, die von anderen Transaktionen geändert werden, bis diese commited haben. Phantom reads können auftreten. Bis auf die Abschwächung bei der Verwendung von cursors mit CLOSE <curor> WITH RELEASE ist diese Stufe vergleichbar mit repeatable read des Standards. Repeatable read (RR) Diese Stufe ist analog zu RS, ausser dass keine phantom reads auftreten können, da durch entsprechende Sperren eine vollständige Isolation erreicht wird. Bis auf die Abschwächung bei der Verwendung von cursors mit CLOSE <cursor> WITH RELEASE ist diese Stufe vergleichbar mit serializable des Standards. Die Java-Anwendung, welche als Benchmark-Applikation verwendet wird, verwendet das dem JDBC-Interface. Damit werden die Isolationsstufen vom DBMS unabhängig durch die mit den Standardnamen bezeichneten Konstanten eingestellt. DB2 setzt diese wie folgt um: read uncommited wird zu UR, read commited zu CS, repeatable read zu RS und serializable zu RR, was in [7] beschrieben wird Mehrbenutzersynchronisation in SQL Server 28 Microsoft SQL Server 28 (MSSQL) hält sich gemäss den Erklärungen in [15] in den meisten Bezeichnungen und Konzepten der Isolationsstufen an den SQL92-Standard. Die Synchronisation ist sperrbasiert. Allerdings gibt es Zusätze, welche gewisse Zugriffe auf snapshots erlaubt. Sperren können auf Tupel-, Seiten- oder Tabellenebene gesetzt werden, wobei die letzteren beiden Ebenen nur bei zu vielen Sperren durch lock escalation erreicht werden. Die Isolationsstufen der Transaktionen in MSSQL sind folgendermassen definiert: Read uncommited Hierbei werden weder Sperren beantragt noch Sperren anderer Transaktionen berücksichtigt. Diese Einstellung ist mit der gleich benannten des SQL-Standards vergleichbar. 1

19 2.3 Mehrbenutzersynchronisation in den verwendeten DBMS Read commited Da bei dieser Isolationsstufe mindestens shared locks beantragt werden, können nur Daten gelesen werden, die bereits commited sind, also nicht mehr durch ein exclusive lock gesperrt sind. Sobald der aktuelle Bereich, bezogen auf die Sperrgranularität, verlassen wird, wird die jeweilige Sperre der Transaktion der Stufe read commited aufgehoben. Diese Einstellung ist mit der gleich benannten des SQL-Standards vergleichbar. Ist die Datenbankoption READ_COMMITED_SNAPSHOT gesetzt, wird multi-versioning auf Tupel-Ebene eingesetzt, sobald auf das jeweilige Tupel zugegriffen werden soll, genannt row versioning. Repeatable read Für alle Daten, auf die während der Transaktion dieser Stufe zugegriffen wird, werden mindestens shared locks beantragt. Die Sperren werden erst bei Transaktionsende wieder aufgehoben. Dadurch sind phantom reads möglich, weil keine Index- oder Prädikatssperren eingesetzt werden. Diese Einstellung ist mit der gleich benannten des SQL-Standards vergleichbar. Snapshot Diese Isolationsstufe erzeugt bei Transaktionsbeginn eine konsistente Version aller Daten, auf die während der Transaktion zugegriffen wird. Lesende Zugriffe diese Stufe und Schreibzugriffe anderer Transaktionen sind gleichzeitig möglich. Impliziert wird, dass schreibende Zugriffe von Transaktionen dieser Stufe andere Transaktionen am Zugriff hindert und umgekehrt, aber es wird nicht ausgeführt, ob dabei einer der im Unterkapitel beschriebenen Mechanismen mit Zeitstempeln oder Zertifikatssperren eingesetzt wird. Für den Einsatz dieser Isolationsstufe muss für alle an entsprechenden Transaktionen beteiligten Datenbanken die Option ALLOW_SNAPSHOT_ISOLATION aktiviert sein. Serializable Auf Daten, die nicht commited sind, kann nicht zugegriffen werden. Andere Transaktionen können nicht auf verwendete Daten einer Transaktion dieser Isolationsstufe zugreifen. Es werden Bereichssperren auf Indizes verwendet, wodurch das Phantom-Problem ausgeschlossen wird. Diese Einstellung ist mit dem gleich benannten Standard vergleichbar. Das Benchmark-Programm benutzt mit dem JDBC-Interface generell vom DBMS unabhängig die mit den Standardnamen bezeichneten Konstanten für die Isolationsstufen. Für die MSSQLspezifische Stufe snapshot wird aber eine eigene Konstante eines SQLServerConnection-Objektes benötigt [16] Mehrbenutzersynchronisation in PostgreSQL 8.3 PostgreSQL 8.3 (Postgres) verwendet, wie in [21] nachzulesen ist, grundsätzlich multi-versioning zur Nebenläufigkeitskontrolle. Es werden nur folgende Isolationsstufen angeboten: Read commited Lesende Zugriffe können auf sämtliche Daten ausgeführt werden, auch wenn auf diese zur Zeit ein schreibender Zugriff stattfindet. Es wird die zur Startzeit des lesenden Zugriffs letzte als commited markierte Version berücksichtigt. Zugriff ist hier auf die Ausführung ein einzelnen Statements bezogen, nicht auf eine Transaktion. Dadurch können zwei identische SELECT-Anfragen derselben Transaktion verschiedene Daten lesen, unrepeatable reads können also vorkommen. Schreibzugriffe erfordern exclusive locks. Gehaltene exklusive Sperren werden erst bei Transaktionsende freigegeben. Serializable Es wird nur auf die Versionen von Daten zugegriffen, die zu Beginn der Transaktion als commited markiert sind. Wenn Daten geschrieben werden sollen, muss ein exclusive lock gewährt werden. Hat seit dem Start der aktuellen eine andere Transaktion Daten geändert oder gelöscht, die von der aktuellen Transaktion gesperrt werden sollen, wird die aktuelle Transaktion zurückgerollt. Dies entspricht nicht gänzlich einem der Vorgehen, welche im Unterkapitel für multi-versioning beschrieben werden, ist aber einer Variante von monoversions-basierten Zertifizierungssperren-Synchronisation ähnlich. Es wird explizit von echter Serialisierbarkeit unterschieden, mit dem Hinweis auf nach wie vor mögliche phantom reads. 11

20 2.3 Mehrbenutzersynchronisation in den verwendeten DBMS Um die vom implementierten multi-versioning-system nicht abgedeckten Probleme zu verhindern, ermöglicht Postgres die explizite Deklaration einer von acht verschiedenen Sperren in Anfragen, wovon alle auf Tabellen-Ebene gesetzt werden. Einige Sperren werden bei gewissen Statements automatisch angefordert, welche in diesem Fall auch auf Tupel-Ebene gesetzt werden können. Dies trifft laut [17] auf exclusive locks bei Schreibzugriffen zu, welche immer bis zum Ende der Transaktion gehalten werden. Dadurch hält die serializable-implementation ein striktes 2PL ohne Verhinderung von phantom reads ein. Das Benchmark-Programm benutzt mit dem JDBC-Interface für Isolationsstufen generell vom DBMS unabhängig die mit den Standardnamen bezeichneten Konstanten. Wenn eine von Postgres nicht implementierte Stufe angefordert wird, wird stattdessen die nächsthöhere verwendet. Falls also read uncommited eingestellt wird, wird read commited geliefert, repeatable read wird zu serializable verstärkt, wie [17] bestätigt. Dieses Verhalten ist laut [12, S. 333] im SQL-Standard so vorgesehen. 12

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

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

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

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

Datenbankadministration

Datenbankadministration Datenbankadministration 11. Synchronisation AG DBIS University of Kaiserslautern, Germany Karsten Schmidt kschmidt@informatik.uni-kl.de (Vorlage TU-Dresden) Wintersemester 2008/2009 Transaktion Transaktion

Mehr

Mehrbenutzersynchronisation

Mehrbenutzersynchronisation Kapitel 10 Mehrbenutzersynchronisation 381 / 520 Mehrbenutzersynchronisation Alle TAs strikt seriell (also nacheinander) auszuführen ist sicher, aber langsam Oft werden Systemressourcen nicht voll ausgenutzt,

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

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

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

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

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

Transaktionen in der Praxis. Dr. Karsten Tolle

Transaktionen in der Praxis. Dr. Karsten Tolle Transaktionen in der Praxis Dr. Karsten Tolle Praxisbeispiel in Java Connection con = null; try { con = DriverManager.getConnection("jdbc:db2:sample"); } catch (Exception e) { e.printstacktrace(); } con.setautocommit(false);

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

Serialisierbarkeit von Historien: Minimalanforderung bzgl. "akzeptabler" Synchronisation

Serialisierbarkeit von Historien: Minimalanforderung bzgl. akzeptabler Synchronisation Rücksetzbarkeit Serialisierbarkeit von Historien: Minimalanforderung bzgl. "akzeptabler" Synchronisation von Transaktionen zusätzliche Forderung: lokale Rücksetzbarkeit von Historien, d.h. Jede Transaktion

Mehr

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

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

... T n T 1 T 2 T 3. Transaktions-Manager. Daten-Manager. Recovery-Manager Puffer-Manager. Datenbank

... T n T 1 T 2 T 3. Transaktions-Manager. Daten-Manager. Recovery-Manager Puffer-Manager. Datenbank Techniken der Schedule-Realisierung T 1 T 2 T 3.... T n Isolations-Eigenschaft wird durch den Scheduler sichergestellt. Aufgabe: : Koordination des Ablaufs konkurrierender Transaktionen so, dass deren

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

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

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

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

Dieser Foliensatz darf frei verwendet werden unter der Bedingung, dass diese Titelfolie nicht entfernt wird.

Dieser Foliensatz darf frei verwendet werden unter der Bedingung, dass diese Titelfolie nicht entfernt wird. Thomas Studer Relationale Datenbanken: Von den theoretischen Grundlagen zu Anwendungen mit PostgreSQL Springer, 2016 ISBN 978-3-662-46570-7 Dieser Foliensatz darf frei verwendet werden unter der Bedingung,

Mehr

Mehrbenutzer-Synchronisation

Mehrbenutzer-Synchronisation MehrbenutzerSynchronisation KonfliktKategorien Serialisierung Historien Sperrungen Verklemmungen Optimistische Synchronisation Synchronisation in SQL Mehrbenutzersynchronisation Ausführung der drei Transaktionen,

Mehr

9 Transaktionskonzept

9 Transaktionskonzept 9 Transaktionskonzept Transaktionskonzept 9.1 Das Transaktionskonzept 9.2 Concurrency & Locking 9.3 Recovery 9.4 JDBC Teil II 9.4.1 Transaktionsmanagement 9.4.2 Objektrelationale Konzepte Schestag Datenbanken

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

Isolationsstufen für. Dr. Karsten Tolle Dienstag 31. Januar 2012

Isolationsstufen für. Dr. Karsten Tolle Dienstag 31. Januar 2012 Isolationsstufen für Transaktionen / Sicherheit Dr. Karsten Tolle Dienstag 31. Januar 2012 Praxisbeispiel in Java Connection con = null; try { con = DriverManager.getConnection("jdbc:db2:sample"); } catch

Mehr

Mehrbenutzer-Synchronisation

Mehrbenutzer-Synchronisation Mehrbenutzer-Synchronisation Konflikt-Kategorien Serialisierung Historien Sperrungen Verklemmungen Optimistische Synchronisation Synchronisation in SQL Kapitel 11 1 Mehrbenutzersynchronisation Ausführung

Mehr

Mehrbenutzersynchronisation

Mehrbenutzersynchronisation Mehrbenutzersynchronisation VU Datenbanksysteme vom 4.11. 2015 Reinhard Pichler Arbeitsbereich Datenbanken und Artificial Intelligence Institut für Informationssysteme Technische Universität Wien Nebenläufigkeit

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

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

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

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

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

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

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

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

Firebird Database Cache Buffer

Firebird Database Cache Buffer Firebird Database Cache Buffer Norman Dunbar 20. Juli 2013 Version 1.3.1-de - deutsche Version Übersetzung ins Deutsche: Martin Köditz Inhaltsverzeichnis Einleitung... 3 Der Firebird-Cache... 3 MON$IO_STATS

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

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

Unterabfragen (Subqueries)

Unterabfragen (Subqueries) Unterabfragen (Subqueries) Die kürzeste Formulierung ist folgende: SELECT Felderliste FROM Tabelle1 WHERE Tabelle1.Feldname Operator (SELECT Feldname FROM Tabelle2 WHERE Bedingung); wobei Tabelle1 und

Mehr

Unzulänglichkeiten der ANSI-SQL-Isolationslevel [1] Intelligente Datenbanken

Unzulänglichkeiten der ANSI-SQL-Isolationslevel [1] Intelligente Datenbanken Unzulänglichkeiten der ANSI-SQL-Isolationslevel [1] Ausarbeitung zum Seminar Intelligente Datenbanken im Sommersemester 2005 Fabian Klingbeil Universität Bonn Institut für Informatik III am 19.7.2005 Seminar

Mehr

3.17 Zugriffskontrolle

3.17 Zugriffskontrolle 3. Der SQL-Standard 3.17. Zugriffskontrolle Seite 1 3.17 Zugriffskontrolle Datenbanken enthalten häufig vertrauliche Informationen, die nicht jedem Anwender zur Verfügung stehen dürfen. Außerdem wird man

Mehr

Prozedurale Datenbank- Anwendungsprogrammierung

Prozedurale Datenbank- Anwendungsprogrammierung Idee: Erweiterung von SQL um Komponenten von prozeduralen Sprachen (Sequenz, bedingte Ausführung, Schleife) Bezeichnung: Prozedurale SQL-Erweiterung. In Oracle: PL/SQL, in Microsoft SQL Server: T-SQL.

Mehr

Leitfaden Datensicherung und Datenrücksicherung

Leitfaden Datensicherung und Datenrücksicherung Leitfaden Datensicherung und Datenrücksicherung Inhaltsverzeichnis 1. Einführung - Das Datenbankverzeichnis von Advolux... 2 2. Die Datensicherung... 2 2.1 Advolux im lokalen Modus... 2 2.1.1 Manuelles

Mehr

PostgreSQL im praktischen Einsatz. Stefan Schumacher

PostgreSQL im praktischen Einsatz. Stefan Schumacher PostgreSQL im praktischen Einsatz 2. Brandenburger Linux Infotag 2005 Stefan Schumacher , PGP Key http:/// $Header: /home/daten/cvs/postgresql/folien.tex,v 1.11 2005/04/25

Mehr

Von Netop ProtectOn 2 auf Netop ProtectOn Pro umstellen

Von Netop ProtectOn 2 auf Netop ProtectOn Pro umstellen Von Netop ProtectOn 2 auf Netop ProtectOn Pro umstellen Wenn Sie Benutzer von ProtectOn 2 sind und überlegen, auf ProtectOn Pro upzugraden, sollten Sie dieses Dokument lesen. Wir gehen davon aus, dass

Mehr

Antwortzeitverhalten von Online Storage Services im Vergleich

Antwortzeitverhalten von Online Storage Services im Vergleich EPOD Encrypted Private Online Disc Antwortzeitverhalten von Online Storage Services im Vergleich Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee

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

Datensicherung. Beschreibung der Datensicherung

Datensicherung. Beschreibung der Datensicherung Datensicherung Mit dem Datensicherungsprogramm können Sie Ihre persönlichen Daten problemlos Sichern. Es ist möglich eine komplette Datensicherung durchzuführen, aber auch nur die neuen und geänderten

Mehr

Zeiterfassung-Konnektor Handbuch

Zeiterfassung-Konnektor Handbuch Zeiterfassung-Konnektor Handbuch Inhalt In diesem Handbuch werden Sie den Konnektor kennen sowie verstehen lernen. Es wird beschrieben wie Sie den Konnektor einstellen und wie das System funktioniert,

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

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

Dokumentation QuickHMI-Schnittstelle für Oracle Datenbanken

Dokumentation QuickHMI-Schnittstelle für Oracle Datenbanken Dokumentation QuickHMI-Schnittstelle für Oracle Datenbanken Version 2.0 D-28359 Bremen info@indi-systems.de Tel + 49 421-989703-30 Fax + 49 421-989703-39 Inhaltsverzeichnis Was ist die QuickHMI-Schnittstelle

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

Views in SQL. 2 Anlegen und Verwenden von Views 2

Views in SQL. 2 Anlegen und Verwenden von Views 2 Views in SQL Holger Jakobs bibjah@bg.bib.de, holger@jakobs.com 2010-07-15 Inhaltsverzeichnis 1 Wozu dienen Views? 1 2 Anlegen und Verwenden von Views 2 3 Schreibfähigkeit von Views 3 3.1 Views schreibfähig

Mehr

SMC Integrationsserver 5.0 Versionsinformationen

SMC Integrationsserver 5.0 Versionsinformationen SMC Integrationsserver 5.0 Versionsinformationen SMC IT AG Pröllstraße 24 86157 Augsburg Tel. (0821) 720 62-0 Fax. (0821) 720 62-62 smc-it.de info@smc-it.de Geschäftsstelle Ettlingen Pforzheimer Straße

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

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

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

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

Übung Datenbanksysteme I Transaktionen, Selektivität und XML. Thorsten Papenbrock

Übung Datenbanksysteme I Transaktionen, Selektivität und XML. Thorsten Papenbrock Übung Datenbanksysteme I Transaktionen, Selektivität und XML Thorsten Papenbrock Übersicht: Übungsthemen 2 Transaktionen Selektivität XML Thorsten Papenbrock Übung Datenbanksysteme I JDBC Transaktionen:

Mehr

Anforderungen BauPlus

Anforderungen BauPlus en BauPlus 1 BauPlus-Umgebungen... 2 1.1 Übersicht... 2 1.2 Einzelplatz... 2 1.3 Mehrplatzumgebung... 3 1.4 Terminalserver-Umgebung... 4 2 Microsoft SQL-Server... 5 2.1 e... 5 2.2 Voraussetzungen... 5

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) Synchronisation paralleler Transaktionen Kapitel X Vorlesung Datenbanksysteme Univ.-Prof. Dr. Günther Specht Universität Innsbruck Institut für Informatik Datenbanken und Informationssysteme (DBIS) Vorlesungsinhalt

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

SQL: statische Integrität

SQL: statische Integrität SQL: statische Integrität.1 SQL: statische Integrität Im allgemeinen sind nur solche Instanzen einer Datenbank erlaubt, deren Relationen die der Datenbank bekannten Integritätsbedingungen erfüllen. Integritätsbedingungen

Mehr

Hinweise zu Java auf dem Mac:

Hinweise zu Java auf dem Mac: Hinweise zu Java auf dem Mac: 1. Möglichkeit zum Überprüfen der Java-Installation / Version 2. Installiert, aber im Browser nicht AKTIVIERT 3. Einstellungen in der Java-KONSOLE auf Deinem MAC 4. Java Hilfe

Mehr

1 Die Active Directory

1 Die Active Directory 1 Die Active Directory Infrastruktur Prüfungsanforderungen von Microsoft: Configuring the Active Directory Infrastructure o Configure a forest or a domain o Configure trusts o Configure sites o Configure

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

Übungen zur Vorlesung. Datenbanken I

Übungen zur Vorlesung. Datenbanken I Prof. Dr. S. Böttcher Adelhard Türling Übungen zur Vorlesung Datenbanken I WS 2002/2003 Blatt 6 Aufgabe 1: In der Vorlesung haben Sie für die Einbringstrategie Update in Place die Vorgehensweisen steal,

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

Isolationslevel in SQL

Isolationslevel in SQL Isolationslevel in SQL Zu den ACID-Eigenschaften von Transaktionen gehört auch das I, also Isolation. Streng genommen versteht man unter Isolation, dass eine Transaktion unbeeinflusst durch andere Transaktionen

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

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

Die in diesem Dokument aufgelisteten Anforderungen an das Betriebssystem schließen die aktuellen Patches und Servivepacks ein.

Die in diesem Dokument aufgelisteten Anforderungen an das Betriebssystem schließen die aktuellen Patches und Servivepacks ein. Systemanforderungen Die unten angeführten Systemanforderungen für Quark Publishing Platform sind grundlegende Anforderungen, Ihre Benutzerzahl, Asset-Anzahl und Anzahl der Asset-Versionen beeinflussen

Mehr

9 Multithreading. 1 Idee des Multithreading

9 Multithreading. 1 Idee des Multithreading 9 Multithreading Jörn Loviscach Versionsstand: 21. Juli 2015, 11:50 Die nummerierten Felder sind absichtlich leer, zum Ausfüllen beim Ansehen der Videos: http://www.j3l7h.de/videos.html This work is licensed

Mehr

Performance und Bandbreitenmanagement Tests Version 10.01.2005. MuSeGa

Performance und Bandbreitenmanagement Tests Version 10.01.2005. MuSeGa Berner Fachhochschule Hochschule für Technik und Informatik HTI Performance und Bandbreitenmanagement Tests Version 10.01.2005 Diplomarbeit I00 (2004) MuSeGa Mobile User Secure Gateway Experte: Andreas

Mehr

Whitepaper. Produkt: combit Relationship Manager / address manager. FILESTREAM für Microsoft SQL Server aktivieren

Whitepaper. Produkt: combit Relationship Manager / address manager. FILESTREAM für Microsoft SQL Server aktivieren combit GmbH Untere Laube 30 78462 Konstanz Whitepaper Produkt: combit Relationship Manager / address manager FILESTREAM für Microsoft SQL Server aktivieren FILESTREAM für Microsoft SQL Server aktivieren

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

Technische Mitteilung. Nutzung von Oracle für die VIP CM Suite 8 Offene Cursor

Technische Mitteilung. Nutzung von Oracle für die VIP CM Suite 8 Offene Cursor Technische Mitteilung Nutzung von Oracle für die VIP CM Suite 8 Offene Cursor Informationen zum Dokument Kurzbeschreibung Dieses Dokument gibt Hinweise zur Konfiguration des RDBMS Oracle und von VIP ContentManager

Mehr

Der Parameter CLOSE bewirkt, dass sich das Sicherungsprogramm am Ende der Sicherung automatisch schliesst

Der Parameter CLOSE bewirkt, dass sich das Sicherungsprogramm am Ende der Sicherung automatisch schliesst 1 Sicherung 1.1 Einleitung Die Applikation WSCAR basiert auf der Datenbank-Engine Firebird 1.5.5 / 2.5.2. Beide Programme sind nur auf der Hauptstation(Server) installiert und dürfen nie deinstalliert

Mehr

Kapitel 8: Transaktionen

Kapitel 8: Transaktionen Ludwig Maximilians Universität München Institut für Informatik Lehr- und Forschungseinheit für Datenbanksysteme Skript zur Vorlesung Wintersemester 2006/2007 Vorlesung: Dr. Peer Kröger Übungen: Karsten

Mehr

Softwaredokumentation. PaCT V2.04

Softwaredokumentation. PaCT V2.04 Softwaredokumentation Januar 2009 INHALTSVERZEICHNIS 1 Systemvoraussetzungen... 2 2 Softwareinstallation... 3 3 Hardwareinstallation... 3 4 Start... 4 5 Drop Down Menüs... 6 6 Programmeinstellungen...

Mehr

Dr. H. Schuldt. Das Ziel dieser Ubung ist die Untersuchung, wie die in der Vorlesung vorgestellten

Dr. H. Schuldt. Das Ziel dieser Ubung ist die Untersuchung, wie die in der Vorlesung vorgestellten Dr. H. Schuldt Eidgenossische Technische Hochschule Zurich Swiss Federal Institute of Technology Zurich Transaktionsverwaltung in modernen IS Praktische Ubung 1 Beispiellosung Einleitung Das Ziel dieser

Mehr

CAS genesisworld.exchange connect Abgleich von Adressen und Terminen

CAS genesisworld.exchange connect Abgleich von Adressen und Terminen Abgleich von Adressen und Terminen Stand Juni 2004 Was ist CAS genesisworld.exchange connect? Inhalt 1 Was ist CAS genesisworld.exchange connect?... 3 2 Systemvoraussetzungen... 5 2.1 Software...5 2.2

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

Datenbanken & Informationssysteme Übungen Teil 1

Datenbanken & Informationssysteme Übungen Teil 1 Programmierung von Datenbankzugriffen 1. Daten lesen mit JDBC Schreiben Sie eine Java-Anwendung, die die Tabelle Books in der Datenbank azamon ausgibt. Verwenden Sie dabei die SQL-Anweisung select * from

Mehr

1 Application Compatibility Toolkit (ACT) 5.6

1 Application Compatibility Toolkit (ACT) 5.6 1 Application Compatibility Toolkit (ACT) 5.6 Systemvoraussetzungen: SQL Server 2005/2008 (auch Express) ACT 5.6 besteht aus zwei Tools: Der Compatibility Manager ermittelt Informationen, die Auswirkungen

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

Universität Karlsruhe (TH)

Universität Karlsruhe (TH) Universität Karlsruhe (TH) Forschungsuniversität gegründet 1825 Cluster-Praktikum Sommersemester 2007 Transparent Replizierte Objekte in JavaParty Institut für Programmstrukturen und Datenorganisation

Mehr

Datenbanken für Online Untersuchungen

Datenbanken für Online Untersuchungen Datenbanken für Online Untersuchungen Im vorliegenden Text wird die Verwendung einer MySQL Datenbank für Online Untersuchungen beschrieben. Es wird davon ausgegangen, dass die Untersuchung aus mehreren

Mehr

Transaction Validation for XML Documents based on XPath

Transaction Validation for XML Documents based on XPath Transaction Validation for XML Documents based on XPath @ Informatik 2002, m-dbis Stefan Böttcher Adelhard Türling Universität Paderborn Überblick Transaktionen für XML - Daten & mobile Clients Motivation

Mehr

Der Scheduler. 9. Transaktionsverwaltung. Zustände einer Transaktion. Transaktionsoperationen

Der Scheduler. 9. Transaktionsverwaltung. Zustände einer Transaktion. Transaktionsoperationen 9. Transaktionsverwaltung Der Scheduler Architektur der Transaktionsverwaltung Sperrende und nicht-sperrende Verfahren Transaktionen in SQL-Systemen Transaktionsmonitore T 1 T T 2 n Transaktions- Manager

Mehr

VMware Schutz mit NovaBACKUP BE Virtual

VMware Schutz mit NovaBACKUP BE Virtual VMware Schutz mit NovaBACKUP BE Virtual Anforderungen, Konfiguration und Restore-Anleitung Ein Leitfaden (September 2011) Inhalt Inhalt... 1 Einleitung... 2 Zusammenfassung... 3 Konfiguration von NovaBACKUP...

Mehr

Alinof ToDoList. Benutzerhandbuch. Version 2.0! Copyright 2011-2014 by Alinof Software GmbH!!!!!!! Seite 1/

Alinof ToDoList. Benutzerhandbuch. Version 2.0! Copyright 2011-2014 by Alinof Software GmbH!!!!!!! Seite 1/ Alinof ToDoList Benutzerhandbuch Version 2.0 Copyright 20-2014 by Alinof Software GmbH Seite 1/ Inhaltsverzeichnis Vorwort... 3 Urheberechte... 3 Änderungen... 3 Garantie... 3 Systemvoraussetzungen...

Mehr

Datenbanken II Speicherung und Verarbeitung großer Objekte (Large Objects [LOBs])

Datenbanken II Speicherung und Verarbeitung großer Objekte (Large Objects [LOBs]) Datenbanken II Speicherung und Verarbeitung großer Objekte (Large Objects [LOBs]) Hochschule für Technik, Wirtschaft und Kultur Leipzig 06.06.2008 Datenbanken II,Speicherung und Verarbeitung großer Objekte

Mehr

1. Transaktionskonzept

1. Transaktionskonzept 1. Transaktionskonzept Ein wesentliches Charakteristikum für (relationale) Datenbanksysteme stellt die Unterstützung des Transaktions-Konzepts dar. Transaktionen sind Verarbeitungseinheiten, die vom DBMS

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

Systemanforderungen. Sage Personalwirtschaft

Systemanforderungen. Sage Personalwirtschaft Systemanforderungen Sage Personalwirtschaft Inhalt 1.1 für die Personalwirtschaft... 3 1.1.1 Allgemeines... 3 1.1.2 Betriebssysteme und Software... 3 1.2 Hinweise zur Verwendung von Microsoft Office...

Mehr

PADS 3.0 Viewer - Konfigurationen

PADS 3.0 Viewer - Konfigurationen PADS 3.0 Viewer - Konfigurationen Net Display Systems (Deutschland) GmbH - Am Neuenhof 4-40629 Düsseldorf Telefon: +49 211 9293915 - Telefax: +49 211 9293916 www.fids.de - email: info@fids.de Übersicht

Mehr