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

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

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

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

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

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

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

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

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

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

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

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

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

Datenbanken und SQL. Kapitel 8. Concurreny und Recovery. Edwin Schicker: Datenbanken und SQL

Datenbanken und SQL. Kapitel 8. Concurreny und Recovery. Edwin Schicker: Datenbanken und SQL Datenbanken und SQL Kapitel 8 Concurreny und Recovery Concurrency und Recovery Transaktionen Recovery Einführung in die Recovery Logdateien Checkpoints Conncurrency Sperrmechanismen Deadlocks SQL-Norm

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

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

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

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

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

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

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

Kapitel 9 Paralleler Zugriff auf DB

Kapitel 9 Paralleler Zugriff auf DB Seite 1 von 8 www.jurijs-skripte.de.vu DBMS - Kapitel 9 Kapitel 9 Paralleler Zugriff auf DB FEHLERFÄLLE BEI UNKONTROLLIERTER ARBEIT Verloren gegangene Änderung - Da beide Anwendungen abwechselnd lesen

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

Kapitel 15. Transaktionen, Fehlerbehandlung, Multi-User. Prof. Dr. Wolfgang Weber Vorlesung Datenbanken

Kapitel 15. Transaktionen, Fehlerbehandlung, Multi-User. Prof. Dr. Wolfgang Weber Vorlesung Datenbanken Kapitel 15 Transaktionen, Fehlerbehandlung, Multi-User 1 Transaktionen, Fehlerbehandlung, Multi-User Transaktionskonzept Fehlerbehandlung Mehrbenutzersynchronisation 2 Transaktionen Warum? Beispiel 1 Was

Mehr

Dokumentation QuickHMI-Schnittstelle. Datenbanken

Dokumentation QuickHMI-Schnittstelle. Datenbanken Dokumentation QuickHMI-Schnittstelle für SQLServer Datenbanken Version 1.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

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

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

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

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

AK-Automatisierungs und Kommunikationstechnik TI Technische Informatik. NWT Netzwerktechnik www.munz-udo.de

AK-Automatisierungs und Kommunikationstechnik TI Technische Informatik. NWT Netzwerktechnik www.munz-udo.de Einführung Dieser Artikel behandelt das Sperren von Dateien in PHP, Perl, Python und Java. Das Sperren von Datenbanken folgt danach. Excell Sheets kann man im Netzwerk explizit sperren. Es werden hier

Mehr

PostgreSQL in großen Installationen

PostgreSQL in großen Installationen PostgreSQL in großen Installationen Cybertec Schönig & Schönig GmbH Hans-Jürgen Schönig Wieso PostgreSQL? - Die fortschrittlichste Open Source Database - Lizenzpolitik: wirkliche Freiheit - Stabilität,

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

IRF2000, IF1000 Application Note ModbusTCP API

IRF2000, IF1000 Application Note ModbusTCP API Version 2.0 Original-Application Note ads-tec GmbH IRF2000, IF1000 Application Note ModbusTCP API Version 2.0 Stand: 28.10.2014 ads-tec GmbH 2014 IRF2000 IF1000 2 Inhaltsverzeichnis 1 Einführung... 3 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

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

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

pywares-benutzerhandbuch

pywares-benutzerhandbuch pywares-benutzerhandbuch Lock Your World GmbH & Co.KG Alle Rechte vorbehalten. Hinweis Obwohl angemessene Bemühungen unternommen wurden, um sicherzustellen, dass die Informationen in diesem Dokument zum

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

Installationsanleitung BizTalk Server 2006

Installationsanleitung BizTalk Server 2006 Installationsanleitung BizTalk Server 2006 Inhaltsverzeichnis How To: Wie installiere ich den Microsoft BizTalk Server 2006 richtig?... 1 Installationsvorraussetzungen... 2 Hardwarevorraussetzung... 2

Mehr

(Prüfungs-)Aufgaben zum Thema Scheduling

(Prüfungs-)Aufgaben zum Thema Scheduling (Prüfungs-)Aufgaben zum Thema Scheduling 1) Geben Sie die beiden wichtigsten Kriterien bei der Wahl der Größe des Quantums beim Round-Robin-Scheduling an. 2) In welchen Situationen und von welchen (Betriebssystem-)Routinen

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

Datenbankanwendungen (JDBC)

Datenbankanwendungen (JDBC) Datenbankanwendungen (JDBC) Hierarchie: Connection Transaction Statement Connection Aufbau (klassisch): Registrierung des JDBC Driver beim DriverManager: Class.forName(JDBC Driver); Eigentlicher Verbindungsaufbau

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

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

FME Desktop. Data in Motion

FME Desktop. Data in Motion FME Desktop Data in Motion Übersicht Reporting Ausführen, Debuggen, Inspizieren, Profilen Neuigkeiten bei Datenbanken Reporting Move Your Data Analysis Organized Reporting in FME Tabellenkalkulationen

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

JOB SCHEDULER. Managed User Jobs. Dokumentation Juli 2005. MySQL-Job-Automation

JOB SCHEDULER. Managed User Jobs. Dokumentation Juli 2005. MySQL-Job-Automation MySQL-Job-Automation Managed User Jobs JOB SCHEDULER Dokumentation Juli 2005 Software- und Organisations-Service GmbH Giesebrechtstr. 15 D-10629 Berlin Telefon (030) 86 47 90-0 Telefax (030) 861 33 35

Mehr

Handbuch. PLCConnect. HPF GmbH - NL Chemnitz. PhiZoe V1.000 2012-08-30

Handbuch. PLCConnect. HPF GmbH - NL Chemnitz. PhiZoe V1.000 2012-08-30 Handbuch PLCConnect HPF GmbH - NL Chemnitz PhiZoe V1.000 2012-08-30 Title PLCConnect Project SPIDERnetServer HPF GmbH NL Chemnitz Zietenstraße 104 09130 Chemnitz (GERMANY) Tel.: +49 371 44478-0 Fax.: +49

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

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

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

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

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

Telephone Integration für Microsoft CRM 4.0 (TI)

Telephone Integration für Microsoft CRM 4.0 (TI) Telephone Integration für Microsoft CRM 4.0 (TI) Benutzerhandbuch Der Inhalt des Dokuments ist Änderungen vorbehalten. Microsoft und Microsoft CRM sind registrierte Markenzeichen von Microsoft Inc. Alle

Mehr

Hardware- und Software-Anforderungen IBeeS.ERP

Hardware- und Software-Anforderungen IBeeS.ERP Hardware- und Software-Anforderungen IBeeS.ERP IBeeS GmbH Stand 08.2015 www.ibees.de Seite 1 von 8 Inhalt 1 Hardware-Anforderungen für eine IBeeS.ERP - Applikation... 3 1.1 Server... 3 1.1.1 Allgemeines

Mehr

Grundlagen verteilter Systeme

Grundlagen verteilter Systeme Universität Augsburg Institut für Informatik Prof. Dr. Bernhard Bauer Stephan Roser Viviane Schöbel Wintersemester 07/08 Übungsblatt 5 08.01.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1:

Mehr

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015 Abstrakt zum Vortrag im Oberseminar Graphdatenbanken Gero Kraus HTWK Leipzig 14. Juli 2015 1 Motivation Zur Darstellung komplexer Beziehungen bzw. Graphen sind sowohl relationale als auch NoSQL-Datenbanken

Mehr

Acrolinx IQ. Verbindung mit einer externen Terminologiedatenbank herstellen 2.7

Acrolinx IQ. Verbindung mit einer externen Terminologiedatenbank herstellen 2.7 Acrolinx IQ Verbindung mit einer externen Terminologiedatenbank herstellen 2.7 2 Inhalt Einleitung 3 Über diesen Leitfaden...3 Verbinden mit externen Terminologiedatenbanken 4 Erstellen von Sicherungen

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

Aufgabe der Recovery-Komponente des Datenbanksystems ist es, nach einem Fehler den jüngsten konsistenten Datenbankzustand wiederherzustellen.

Aufgabe der Recovery-Komponente des Datenbanksystems ist es, nach einem Fehler den jüngsten konsistenten Datenbankzustand wiederherzustellen. Kapitel 14 Recovery Aufgabe der Recovery-Komponente des Datenbanksystems ist es, nach einem Fehler den jüngsten konsistenten Datenbankzustand wiederherzustellen. 14.1 Fehlerklassen Wir unterscheiden drei

Mehr

Installationsanleitung Mehrplatz-/Netzwerk Hypo Office Banking

Installationsanleitung Mehrplatz-/Netzwerk Hypo Office Banking Installationsanleitung Mehrplatz-/Netzwerk Hypo Office Banking Inhalt 1. VORAUSSETZUNGEN 2 BETRIEBSSYSTEME 2 HARDWARE ANFORDERUNGEN 2 2. MEHRPLATZ-/NETZWERKINSTALLATION 3 HINTERGRUND ZUR INSTALLATION 3

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

Fehlerbehandlung (Recovery)

Fehlerbehandlung (Recovery) Kapitel 9 Fehlerbehandlung (Recovery) 345 / 520 Überblick Recovery Wichtige Aufgabe eines DBMS ist das Verhindern von Datenverlust durch Systemabstürze Die zwei wichtigsten Mechanismen des Recovery sind:

Mehr

Datenadminstrator, Datenbankdesigner, Systemanalytiker (für die logische Sicht zuständig)

Datenadminstrator, Datenbankdesigner, Systemanalytiker (für die logische Sicht zuständig) 1 Grundlagen Begriffe Daten bekannte zutreffende Tatsachen über die Domäne/Miniwelt DBS Einsatz eines DBMS für eine Datenbank, DBS besteht aus folgenden Komponenten: 1. DBMS 2. Datenbank DBMS Software

Mehr

Begriff: Scheduling Planung, Schedule Plan. Verplanung der CPU-Zeit an die Threads (bzw. Prozesse)

Begriff: Scheduling Planung, Schedule Plan. Verplanung der CPU-Zeit an die Threads (bzw. Prozesse) 5 CPU-Scheduling Im folgenden wird von Threads gesprochen. Bei Systemen, die keine Threads unterstützen, ist der einzige "Thread" eines Prozesses gemeint. Früher wurde dieser Thread synonym mit dem Begriff

Mehr

IBM Informix Tuning und Monitoring

IBM Informix Tuning und Monitoring Seminarunterlage Version: 11.01 Copyright Version 11.01 vom 25. Juli 2012 Dieses Dokument wird durch die veröffentlicht. Copyright. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

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

Transaktionsverwaltung und Recovery

Transaktionsverwaltung und Recovery Transaktionsverwaltung und Recovery Transaktionsverwaltung Transaktionsbegriff Synchronisation und Sperren Isolation Level in SQL MVCC Hierarchische Sperren Isolation Level und Sperren in relationalen

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

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

Data Sharing im Cluster am Beispiel von Adabas Arno Zude, Adabas-Entwicklung Vortrag an der Universität Jena

Data Sharing im Cluster am Beispiel von Adabas Arno Zude, Adabas-Entwicklung Vortrag an der Universität Jena Data Sharing im Cluster am Beispiel von Arno Zude, -Entwicklung Vortrag an der Universität Jena 2. Februar 2006 Themen Cluster Services Data Sharing im Cluster mit / 2.2.06 / 2 Software AG Cluster Services

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

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG ALM mit Visual Studio Online Philip Gossweiler Noser Engineering AG Was ist Visual Studio Online? Visual Studio Online hiess bis November 2013 Team Foundation Service Kernstück von Visual Studio Online

Mehr

Server: Vice nach Tanenbaum, van Steen

Server: Vice nach Tanenbaum, van Steen 3 Fallbeispiel: Coda Nachfolger des Andrew File Systems (AFS) Carnegie Mellon University, 1990 (CMU) Zielsetzung hohe Verfügbarkeit bei mehreren 10.000 Client-Rechnern Fehlertoleranz abgesetzter Betrieb

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

3 Variablen. 3.1 Allgemeines. 3.2 Definition und Verwendung von Variablen

3 Variablen. 3.1 Allgemeines. 3.2 Definition und Verwendung von Variablen 3 Variablen 3.1 Allgemeines Variablen werden in Prozeduren, Mustern und Parameter-Dokumenten definiert und verwendet und bei der Jobgenerierung durch die Werte, die ihnen zugewiesen werden, ersetzt. Variablen

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

Learning Suite Talent Suite Compliance Suite. Systemvoraussetzungen

Learning Suite Talent Suite Compliance Suite. Systemvoraussetzungen Learning Suite Talent Suite Compliance Suite Systemvoraussetzungen Vorwort Dieses Dokument beschreibt, welche Anforderungen an die Installationsumgebung zu stellen sind, um die Plattform unter optimalen

Mehr

Migrationsanleitung von 2.0 auf 2.1

Migrationsanleitung von 2.0 auf 2.1 Die wichtigste Neuerung von 2.0 auf 2.1 aus Sicht der Anwendungs- Migration ist die Verwendung von Maven. Mit Maven holt sich die Anwendung alle notwendigen Bibliotheken in den jeweils angegebenen Versionen

Mehr

Uni Duisburg-Essen Fachgebiet Informationssysteme Prof. Dr. N. Fuhr

Uni Duisburg-Essen Fachgebiet Informationssysteme Prof. Dr. N. Fuhr Raum: LF 230 Bearbeitung: 9.-11. Mai 2005 Datum Gruppe Vorbereitung Präsenz Aktuelle Informationen unter: http://www.is.informatik.uni-duisburg.de/courses/dbp_ss03/ Tabellen in IBM DB2 Tabellen Eine relationale

Mehr

Hinweise zur Verwendung von myfactory unter Windows XP mit Service Pack 2

Hinweise zur Verwendung von myfactory unter Windows XP mit Service Pack 2 Hinweise zur Verwendung von myfactory unter Windows XP mit Service Pack 2 Durch Verbesserungen der Sicherheitsstandards seitens Microsoft sind mit der Installation des Service Pack 2 für XP zum fehlerfreien

Mehr

SiteAudit Knowledge Base. Move Add Change Tracking. Vorteile Übersicht. In diesem Artikel: Vorteile Übersicht Funktionsübersicht Berichte anpassen

SiteAudit Knowledge Base. Move Add Change Tracking. Vorteile Übersicht. In diesem Artikel: Vorteile Übersicht Funktionsübersicht Berichte anpassen SiteAudit Knowledge Base Move Add Change Tracking Dezember 2010 In diesem Artikel: Vorteile Übersicht Funktionsübersicht Berichte anpassen MAC Benachrichtigungen Vorteile Übersicht Heutzutage ändern sich

Mehr

XP - Winows 2003 / 2000 DomainController Slow Copy Files Network XP - Kopiert langsam auf Win2003 / 2000 Server Domain Controller

XP - Winows 2003 / 2000 DomainController Slow Copy Files Network XP - Kopiert langsam auf Win2003 / 2000 Server Domain Controller XP - Winows 2003 / 2000 DomainController Slow Copy Files Network XP - Kopiert langsam auf Win2003 / 2000 Server Domain Controller Problem liegt an Domain-Controller - (ist ja eigentlich nicht als File-Server

Mehr

Monitoring Microsoft SQL Server

Monitoring Microsoft SQL Server Monitoring Microsoft SQL Server Michael Streb NETWAYS GmbH Einführung Welche Software kommt zum Einsatz SQL Server Microsoft Windows 2003 Server x64 Microsoft SQL Server 2008 x64 Standart NSClient++ 0.3.3

Mehr

Datenbankstammtisch. Replikation in heterogenen Datenbankumgebungen am Beispiel des Sybase Replication Servers. 1. Februar 2006

Datenbankstammtisch. Replikation in heterogenen Datenbankumgebungen am Beispiel des Sybase Replication Servers. 1. Februar 2006 Datenbankstammtisch Replikation in heterogenen Datenbankumgebungen am Beispiel des Sybase Replication Servers 1. Februar 2006 Autoren: Andreas Reis, Sebastian Mehl Dipl.-Phys. Thomas Richter Gliederung

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

Systemanforderungen ab Version 5.31

Systemanforderungen ab Version 5.31 Systemanforderungen ab Version 5.31 Auszug aus BüroWARE Erste Schritte Version 5.4 Generelle Anforderungen SoftENGINE BüroWARE SQL / Pervasive Das Programm kann sowohl auf 32 Bit- als auch auf 64 Bit-en

Mehr

Acrolinx IQ. Verbindungen mit externen Terminologiedatenbanken 2.9

Acrolinx IQ. Verbindungen mit externen Terminologiedatenbanken 2.9 Acrolinx IQ Verbindungen mit externen Terminologiedatenbanken 2.9 2 Inhalt Einleitung 3 Über diesen Leitfaden...3 Verbinden mit externen Terminologiedatenbanken 4 Erstellen von Sicherungen vorhandener

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

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

Datenbankadministration WS 2012/13: Performance-Monitoring und -Tuning

Datenbankadministration WS 2012/13: Performance-Monitoring und -Tuning Datenbankadministration WS 2012/13: Performance-Monitoring und -Tuning Prof. Dr. K. Küspert, Dipl.-Math. K. Büchse, Dipl.-Inf. A. Göbel Friedrich-Schiller-Universität Jena 09. Januar 2013 Gliederung Motivation

Mehr

Von der UML nach C++

Von der UML nach C++ 22 Von der UML nach C++ Dieses Kapitel behandelt die folgenden Themen: Vererbung Interfaces Assoziationen Multiplizität Aggregation Komposition Die Unified Modeling Language (UML) ist eine weit verbreitete

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

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

DBS= DB + DBMS (Datenbank + Datenbankmanagementsystem)

DBS= DB + DBMS (Datenbank + Datenbankmanagementsystem) 1. Einleitung Datenbanksysteme (DBS) DBS ermöglicht die anwendungsübergreifende Nutzung von Daten. DBS isoliert Anwendungen von Hardware und Betriebssystem DBS= DB + DBMS (Datenbank + Datenbankmanagementsystem)

Mehr

Online Help StruxureWare Data Center Expert

Online Help StruxureWare Data Center Expert Online Help StruxureWare Data Center Expert Version 7.2.7 Virtuelle StruxureWare Data Center Expert-Appliance Der StruxureWare Data Center Expert-7.2-Server ist als virtuelle Appliance verfügbar, die auf

Mehr

Messdaten auswerten und visualisieren 5 Tipps, die passende Darstellungstechnik für ein Messsystem zu finden

Messdaten auswerten und visualisieren 5 Tipps, die passende Darstellungstechnik für ein Messsystem zu finden Messdaten auswerten und visualisieren 5 Tipps, die passende Darstellungstechnik für ein Messsystem zu finden 27.05.13 Autor / Redakteur: Nach Unterlagen von National Instruments / Hendrik Härter Messdaten

Mehr

9 Verteilte Verklemmungserkennung

9 Verteilte Verklemmungserkennung 9 Verteilte Verklemmungserkennung 9.1 Grundlagen Für die Existenz einer Verklemmung notwendige Bedingungen Exklusive Betriebsmittelbelegung Betriebsmittel können nachgefordert werden Betriebsmittel können

Mehr

IDS Lizenzierung für IDS und HDR. Primärserver IDS Lizenz HDR Lizenz

IDS Lizenzierung für IDS und HDR. Primärserver IDS Lizenz HDR Lizenz IDS Lizenzierung für IDS und HDR Primärserver IDS Lizenz HDR Lizenz Workgroup V7.3x oder V9.x Required Not Available Primärserver Express V10.0 Workgroup V10.0 Enterprise V7.3x, V9.x or V10.0 IDS Lizenz

Mehr

tcvision Freigabemitteilung Version 6

tcvision Freigabemitteilung Version 6 tcvision Freigabemitteilung Version 6 Stand: 5. Mai 2015 TCP/IP TCP/IP Verbindungen werden dynamisch auf- und abgebaut, um Stabilitätsproblemen in der Infrastruktur zu begegnen. Mit Hilfe des tcscript

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