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

Größe: px
Ab Seite anzeigen:

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

Transkript

1 Data Sharing im Cluster am Beispiel von Arno Zude, -Entwicklung Vortrag an der Universität Jena 2. Februar 2006

2 Themen Cluster Services Data Sharing im Cluster mit / / 2 Software AG

3 Cluster Services Vortragender Informatik studiert an der TH (heute: TU) Darmstadt mit Diplom abgeschlossen Seit 1989 Software-Entwickler bei der Software AG in Darmstadt im Bereich DBMS Mainframe Software AG 1969 gegründet war das erste Produkt heute: in 60 Ländern vertreten > 2600 Mitarbeiter (> 750 in Deutschland) > 400 Millionen Euro Jahresumsatz spezialisiert auf Mainframes sowie Software-Integrationstechnologien Data Sharing im Cluster mit / / 3 Software AG

4 Ursprung I Cluster Services Entwicklung begann vor der Zeit von SQL Flexible Datenzugriffswege über Feldinhalte Datensatzbasierte Programmierschnittstelle in gewissem Maße auch mengenbasiert SQL-Schnittstelle über Zusatzprodukt oder Dritthersteller z.b. ODBC-, JDBC-Schnittstellen Nicht-SQL-Features Multiple Felder Periodengruppen Dirty Read u.a. Data Sharing im Cluster mit / / 4 Software AG

5 Ursprung II Cluster Services Reputation für hohe Performance hohe Stabilität geringen Administrationsaufwand Eingesetzt hauptsächlich von Banken Behörden Logistikunternehmen Universitäten Versicherungen Verwaltungen u.a. Data Sharing im Cluster mit / / 5 Software AG

6 Terminologie Cluster Services - und SQL-Terminologie im Vergleich: -Term (deutsch) Datenbank Datei (Daten)satz Feld Deskriptor ET BT -Term (englisch) database file record field descriptor ET (end transaction) BT (backout transaction) SQL-Term (englisch) database table row column index commit rollback Data Sharing im Cluster mit / / 6 Software AG

7 Konzepte I Cluster Services Datenbank enthält mehrere Files File wird durch File-Kontrollblock repräsentiert enthält Verwaltungsinformationen Datensätze stehen im Datenspeicher werden durch ISNs identifiziert ISN = Interne Satznummer Datensätze werden über Adresskonverter gefunden Dateninhalte werden über Index und zugeordnete ISNs gefunden File-Kontrollblock Adresskonverter Index Datenspeicher Data Sharing im Cluster mit / / 7 Software AG

8 Konzepte II Cluster Services Daten abspeichern und wiederfinden Transaktionskonzept ACID-Eigenschaften Mehrbenutzerfähigkeit Recovery Administration Data Sharing im Cluster mit / / 8 Software AG

9 Ursprung Cluster Services Cluster-Technologie von IBM für IBM Mainframes mit z/os (früher MVS, OS/390) Hardware und Software Ziele: Höhere Verfügbarkeit Bessere Performance Mittel: Mehrfachauslegung der Komponenten Verteilung der Arbeit Load Balancing Dienste für typische Cluster-Funktionalität (z.b. Cache, Lock) Data Sharing im Cluster mit / / 9 Software AG

10 Architektur Cluster Services z/os Sysplex Timer z/os A Lock List C z/os Cache Coupling Facility z/os B Shared Disks Shared Disks D Data Sharing im Cluster mit / / 10 Software AG

11 Architektur Cluster Services Sysplex Timer synchronisierte Zeitstempel auf allen verbundenen Systemen Schnelle Verbindungen zur Coupling Facility (CF) im Mikrosekundenbereich mal schneller als I/O gegen schnelle Plattenspeicher In vielen Fällen wartet die CPU auf Antwort von der CF Schnelle CF-Anfrage kostet etwa Tausend Instruktionen Das ist ca. ¼ bis ⅓ eines durchschnittlichen -Kommandos! Betrieb von mehreren Coupling Facilities möglich (empfohlen) Duplexing von CF-Strukturen möglich shared everything gemeinsamer Plattenspeicher closely coupled getrennter Hauptspeicher, gemeinsamer CF-Speicher Data Sharing im Cluster mit / / 11 Software AG

12 Services I Cluster Services Cross-System Coupling Facility (XCF) gab es auch schon vor der Coupling Facility Gruppenbildung automatische Benachrichtigung über Zu- und Abgänge zwangsweise Terminierung anderer Gruppenmitglieder Kommunikation Austausch von Nachrichten Broadcast Timeout Statusbeobachtung (in Cluster Services nicht verwendet) regelmäßige Lebenszeichen Data Sharing im Cluster mit / / 12 Software AG

13 Services II Cluster Services Cross-System Extended Services (XES) Strukturen in der Coupling Facility Cache-Struktur für den Betrieb eines gemeinsamen Caches effiziente Benachrichtigung über ungültig gewordene Datenelemente Lock-Struktur für die Synchronisation von Operationen auf gemeinsamen Ressourcen flexible Sperrprotokolle möglich Listen-Struktur (von Cluster Services nicht verwendet) für den Betrieb gemeinsamer Datenstrukturen z.b. Auftragswarteschlange weitere Dienste mehr administrativer Art Data Sharing im Cluster mit / / 13 Software AG

14 Cluster Services Ziele I Cluster Services Erweiterung eines komplexen Systems () in ein verteiltes, auf mehreren separaten Rechnern laufendes [noch komplexeres ] System ( Cluster Services) eine Datenbank mehrere Server, die auf der gemeinsamen Datenbank arbeiten Symmetrisch Jeder Knoten im Cluster kann grundsätzlich alles machen insbesondere auch Updates durchführen Hoch verfügbar Wenn ein Knoten ausfällt geplant oder ungeplant, arbeiten die anderen mit der vollen Funktionalität weiter Data Sharing im Cluster mit / / 14 Software AG

15 Cluster Services Ziele II Cluster Services Bessere Performance angemessener (nur leicht höherer) CPU-Verbrauch höherer Durchsatz gleiche oder kürzere Antwortzeiten gute Skalierbarkeit (bei Vergrößerung des Clusters) geringer Basis-Overhead möglichst lineare Durchsatzsteigerung Kompatibel mit Einzel- Cluster-Einsatz transparent für Anwendungsprogramme Anwendungsprogramme müssen nicht angepasst werden Stabil, robust, für Produktionseinsatz geeignet Data Sharing im Cluster mit / / 15 Software AG

16 Cluster Services Allgemeines Cluster Services Grundlegende Schwierigkeiten bei der Entwicklung von Cluster-Software: konsistenten gemeinsamen Status behalten Operationen auf gemeinsamen Ressourcen korrekt synchronisieren alle gemeinsamen Ressourcen identifizieren alle Operationen auf diesen Ressourcen identifizieren möglichst wenig Aufwand (zur Laufzeit) für Synchronisation Data Sharing möglichst wenig Interaktion zwischen den Knoten Je häufiger ein Knoten auf einen anderen warten muss: desto länger braucht er für seine Arbeit ( Performance) desto höher ist das Risiko, von einem Ausfall des anderen getroffen zu werden ( Verfügbarkeit) Recovery für Knotenausfall Kranken Knoten isolieren, damit nicht der ganze Cluster krank wird Data Sharing im Cluster mit / / 16 Software AG

17 Cluster Services Architektur Cluster Services z/os A CF z/os B Benutzer XES Lock Cache XES Benutzer Nukleus XCF Nukleus DB DB Work PLOG PLOG Work Seq. PLOG Data Sharing im Cluster mit / / 17 Software AG

18 Cluster Services Benutzer Cluster Services Jeder Benutzer wird beim ersten -Kommando an einen der Nuklei im Cluster gebunden normalerweise an einen lokalen Nukleus wenn das nicht geht, an einen entfernten (remote) Nukleus Zugewiesener Nukleus hält den Benutzerkontext z/os A z/os B z/os C Benutzer Benutzer Benutzer Cluster Nukleus A Cluster Nukleus C Data Sharing im Cluster mit / / 18 Software AG

19 Cluster Services Kommunikation Cluster Services Interne Anfragen gezielt an einen oder pauschal an alle anderen Knoten gerichtet Alle internen Anfragen mit Timeout versehen Drastische, aber einfache Fehlerbehandlung: unerwarteter Fehlercode abstürzen! Knoten weg ist erwarteter Fehlercode keine Antwort nicht antwortenden Knoten canceln! danach: Online Recovery Cluster Nukleus B Cluster Nukleus A? Cluster Nukleus C Data Sharing im Cluster mit / / 19 Software AG

20 Cluster Services Synchronisation I Cluster Services XES unterstützt flexible Sperrprotokolle hierarchische Sperren Benachrichtigung bei Sperrkonflikten Entzug gehaltener Sperren (nach Benachrichtigung) Cluster Services braucht aber nur einfache Standardsperren Lesesperre (shared) Schreibsperre (exclusive) shared erlaubt andere shared exclusive schließt alle anderen aus bei Sperrkonflikt: warten bis Sperre frei Abbruch der Sperranforderung Data Sharing im Cluster mit / / 20 Software AG

21 Cluster Services Synchronisation II Cluster Services Einphasige Synchronisation Beispiel: Änderung eines globalen Parameters Nukleus A Nuklei B, C,... PARM-Sperre erwerben (exklusiv, warten) Parameter lokal ändern Anfrage entgegennehmen Anfrage an alle anderen Knoten schicken Parameter lokal ändern Auf Antworten warten Antwort zurückschicken PARM-Sperre freigeben Data Sharing im Cluster mit / / 21 Software AG

22 Cluster Services Synchronisation III Cluster Services Zweiphasige Synchronisation Beispiel: Transaktionssynchronisation am Ende eines Online Save Nukleus A Nuklei B, C,... Phase 1 ETSYNC-Sperre erwerben (exklusiv, nicht warten) Keine neuen Transaktionen starten ET-Sync-Phase-1 Anfrage verschicken Auf Antworten warten Alte Transaktionen auslaufen lassen Anfrage entgegennehmen Keine neuen Transaktionen starten Alte Transaktionen auslaufen lassen Antwort zurückschicken A Data Sharing im Cluster mit / / 22 Software AG

23 Cluster Services Synchronisation III Cluster Services Nukleus A Nuklei B, C,... A Synchronisierter Zustand erreicht! Phase 2 Neue Transaktionen starten ET-Sync-Phase-2 Anfrage verschicken Auf Antworten warten ETSYNC-Sperre freigeben Anfrage entgegennehmen Neue Transaktionen starten Antwort zurückschicken Data Sharing im Cluster mit / / 23 Software AG

24 Cluster Services Cache I Cluster Services Cache in CF sitzt logisch gesehen zwischen Datenbank und lokalem Cache jedes Knoten Verschiedene Cache Policies: directory-only keine Daten im Cache store-through keine geänderten Daten im Cache store-in geänderte Daten im Cache benötigt Cast-out-Prozesse (Schreiben der geänderten Blöcke in die Datenbank) Cluster Services benutzt Store-in Cache schreibt nur geänderte Blöcke in den Cache Cluster Nukleus A Lokaler Cache DB CF Cache DB Cluster Nukleus B Lokaler Cache Data Sharing im Cluster mit / / 24 Software AG

25 Cluster Services Cache II Cluster Services Cache-Kohärenz Wird ein geänderter Block in den Cache geschrieben, werden veraltete Kopien in anderen lokalen Caches invalidiert Cache CF 724 Wenn Nukleus A seine geänderte Kopie von Block 724 in den Cache schreibt, wird die veraltete Kopie von Nukleus C automatisch als ungültig markiert. Nukleus B hat keine Kopie dieses Blocks und ist nicht betroffen. S y s t e m A Cache-Vektor Cache-Vektor Cache-Vektor? 724 Lok. Cache Nukleus A S y s t e m B Lokaler Cache Nukleus B S y s t e m C? Lok. Cache 724 Nukleus C Data Sharing im Cluster mit / / 25 Software AG

26 Cluster Services Cache III Cluster Services Block lesen mit Sperre Lesesperre kann für mehrere Blöcke gelten Kein anderer darf den Block ändern Beim Lesen aus dem Cache wird registriert, dass dieser Knoten eine Kopie des Blocks hat auch wenn der Block gar nicht im Cache ist Wird der Block später geändert, dient die Registrierung zur Invalidierung der veralteten Kopie Lesesperre erwerben (shared, warten) Block lokal finden und validieren OK? J N Block verwenden Lesesperre freigeben Block aus Cache lesen OK? J N Block aus DB lesen Data Sharing im Cluster mit / / 26 Software AG

27 Cluster Services Cache IV Cluster Services Block ändern mit Sperre Schreibsperre kann für mehrere Blöcke gelten Kein anderer darf den Block lesen Oft müssen mehrere logisch zusammengehörende Blöcke geändert werden Beim Design des Sperrprotokolls auf mögliche Deadlocks achten! Schreibsperre erwerben (exklusiv, warten) Block lokal finden und validieren OK? J N Block ändern Block in Cache schreiben Block aus Cache lesen OK? J N Block aus DB lesen Schreibsperre freigeben Data Sharing im Cluster mit / / 27 Software AG

28 Cluster Services Cache V Cluster Services Blocksperren sind teuer Entweder viele Sperren mit kleinem Wirkungsbereich z.b. Blocksperren viele Sperroperationen Oder wenige Sperren mit großem Wirkungsbereich z.b. hierarchische Sperren häufigeres Warten bei parallelen Zugriffen Blocksperren sind pessimistisch erzeugen Aufwand auch ohne parallele Zugriffe Block lokal finden Block validieren OK? N J Fertig Block aus Cache lesen J OK? Fertig N Block aus DB lesen Block lesen ohne Sperre Data Sharing im Cluster mit / / 28 Software AG

29 Cluster Services Cache VI Cluster Services Block lesen ohne Sperre möglich wenn Zielobjekt im Block schon anders gesperrt ist z.b. Sperre auf Datensatzebene Zielobjekt im Block nicht gesperrt zu werden braucht z.b. gewisse Verwaltungsinformationen Dirty Read Inkonsistenzen zwischen logisch zusammengehörenden Blöcken erkannt und kompensiert werden können z.b. Inkonsistenzen zwischen Adresskonverter und Datenspeicher Block lesen ohne Sperre nicht möglich wenn Inkonsistenzen zwischen logisch zusammengehörenden Blöcken nicht erkannt und kompensiert werden können z.b. im Index (wird hier nicht weiter behandelt) Data Sharing im Cluster mit / / 29 Software AG

30 Cluster Services Cache VII Cluster Services Block ändern ohne Sperre Zielobjekt im Block kann gesperrt sein z.b. Datensatz muss aber nicht gesperrt sein z.b. nächste freie Satznummer Das Schreiben des geänderten Blocks in den Cache schlägt fehl, wenn zwischen dem Validieren und dem Schreibversuch ein anderer Knoten den Block geändert und in den Cache geschrieben hat In diesem Fall den Block neu lesen und die Änderung wiederholen Block lesen und validieren Block ändern Block in Cache schreiben N OK? J Fertig Data Sharing im Cluster mit / / 30 Software AG

31 Cluster Services Cache VIII Cluster Services Geänderte Blöcke sofort in den Cache zu schreiben ist teuer für updateintensive Batch-Programme Viele Blöcke können häufig geändert werden z.b. wenn sie viele Datensätze enthalten Schreiben geänderter Blöcke in den Cache bis Transaktionsende verzögern (verzögertes Publizieren) Geänderte Blöcke sind weiterhin nicht gesperrt! Wenn ein geänderter Block von einem anderem Knoten auch geändert wurde, müssen alle Änderungen wiederholt werden Beschreibungen von allen noch nicht publizierten Änderungen merken Beim Wiederholen von Änderungen können auf einmal andere Blöcke betroffen sein z.b. kein Platz für neuen Satz im ursprünglich vorgesehenen Block Dabei können diese auch zu wiederholende Änderungen haben! Das verzögerte Publizieren von Änderungen ist kompliziert! Data Sharing im Cluster mit / / 31 Software AG

32 Cluster Services Cache IX Cluster Services Verzögertes Publizieren geänderter Blöcke kann scheinbare Inkonsistenzen zwischen zusammengehörenden Blöcken hervorrufen Beispiel: Datensatz mit gegebener ISN (Satznummer) lesen Paralleler Update ist möglich (dirty read) 1. Adresskonverter-Block lesen Datensatz ist angeblich in Block Nr Datenspeicherblock 4711 lesen Datensatz ist nicht im Block! 3. Andere Knoten auffordern, etwaige noch nicht publizierte Änderungen dieser beiden Blöcke in den Cache zu schreiben Auf Antworten warten 4. Operation neu versuchen Wenn sich die beteiligten Blöcke nicht geändert haben, sind sie wirklich inkonsistent zueinander Data Sharing im Cluster mit / / 32 Software AG

33 Konzepte Cluster Services Datenbank enthält mehrere Files File wird durch File-Kontrollblock repräsentiert enthält Verwaltungsinformationen Datensätze stehen im Datenspeicher werden durch ISNs identifiziert ISN = Interne Satznummer Datensätze werden über Adresskonverter gefunden Dateninhalte werden über Index und zugeordnete ISNs gefunden File-Kontrollblock Adresskonverter Index Datenspeicher Data Sharing im Cluster mit / / 33 Software AG

34 Cluster Services Recovery I Cluster Services Zurücksetzen von Transaktionen (Backout, Rollback) funktioniert wie im Einzel- Restart Recovery (Offline Recovery) funktioniert im Wesentlichen wie im Einzel- aber die Datensicherungssätze aller Cluster-Nuklei werden dynamisch in chronologische Reihenfolge gemischt Recovery nach Ausfall eines, aber nicht aller Knoten (Online Recovery) wird nach Ruhigstellen der Überlebenden auf Offline Recovery zurückgeführt an dieser Stelle Verbesserungsbedarf Data Sharing im Cluster mit / / 34 Software AG

35 Cluster Services Architektur Cluster Services z/os A CF z/os B Benutzer XES Lock Cache XES Benutzer Nukleus XCF Nukleus DB DB Work PLOG PLOG Work Seq. PLOG Data Sharing im Cluster mit / / 35 Software AG

36 Cluster Services Recovery II Cluster Services Archive Recovery funktioniert nach dem Mischen der Datensicherungssätze wie vorher alt Zwischenspeicher für Sicherungssätze neu PLOG PLOG PLOGs mischen PLOG Alle Sicherungssätze in chronologischer Folge Seq. PLOG Data Sharing im Cluster mit / / 36 Software AG

37 Cluster Services I Cluster Services Die schwierigsten Komponenten sind am Ende nicht unbedingt diejenigen, die die meisten Probleme bereiten Wenn man Dinge sorgfältig macht, kann man sie auch korrekt hinbekommen Pay attention to all details Performance ist wichtig Insbesondere bei Cluster-Software muss sie schon beim Design berücksichtigt werden Der Overhead für Kommunikation, Synchronisation und Data Sharing kann sehr leicht zu Performance-Problemen führen Es ist wichtig, die Architektur des Systems, auf dem man aufbaut, zu kennen und verstehen Auch sehr schnelle Operationen können problematisch sein Kommunikation mit der Coupling Facility im Mikrosekundenbereich ( mal schneller als ein I/O) aber: verbraucht mehr CPU-Zeit als ein I/O! Data Sharing im Cluster mit / / 37 Software AG

38 Cluster Services II Cluster Services Cluster-Software kann trotz des inhärenten Overheads den CPU- Verbrauch verringern, wenn sie Anfragen von entfernten (remote) Knoten in lokale Anfragen umwandelt Allein der Transport von Anfragen verbraucht CPU-Zeit Der erste Cluster-Services-Kunde verteilte seine Cluster-Nuklei auf 14 bzw. 17 Systeme im! Kunden benutzen ihre Software nicht immer so, wie der Hersteller es erwartet Das Ändern von Blöcken ohne Blocksperren und das Sammeln von Änderungen vor dem Publizieren im Cache haben sich bewährt obwohl die dafür notwendige Logik komplex ist obwohl schon einmal durchgeführte Änderungen gelegentlich wiederholt werden müssen Wenn die Knoten nicht miteinander reden können, funktioniert der ganze Cluster nicht passiert, wenn XCF nicht funktioniert (oder extrem langsam ist) Data Sharing im Cluster mit / / 38 Software AG

39 Cluster Services III Cluster Services Am problematischsten für die Verfügbarkeit eines Clusters ist der Fall, dass ein Knoten auf Anfragen nicht reagiert Risiko: Wenn ein Knoten krank ist, wird der ganze Cluster krank Wie kann man wissen, dass ein anscheinend toter Knoten tatsächlich tot ist?? Recovery ist erst dann erlaubt Das zwangsweise Terminieren eines nicht antwortenden Knotens ist im Prinzip richtig Das Wohl aller (des Clusters) geht über das Wohl eines Einzelnen (eines Knotens)... löst aber nicht das ganze Problem Auch zum Abstürzen braucht ein Knoten CPU-Zeit Was, wenn sein System überlastet ist?? Möglichkeiten zur Milderung (aufwendig): Kommunikation zwischen Knoten verringern gezieltes Recovery je nach fehlgeschlagener Operation Data Sharing im Cluster mit / / 39 Software AG

40 Cluster Services IV Cluster Services Lieber schnell abstürzen und dann schnell und zuverlässig Recovery durchführen... als viel Arbeit darin stecken, Abstürze unter günstigen Umständen zu vermeiden Höhere Verfügbarkeit heißt nicht unbedingt, dass ein Benutzer vom Absturz eines (seines) Knotens nichts mitbekommt,... als vielmehr, dass das System gleich danach weiterhin zur Verfügung steht Global synchronisierte Zeitstempel sind sehr nützlich für Cluster Data Sharing im Cluster mit / / 40 Software AG

41 Cluster Services V Cluster Services Die Versprechungen von Clustern, höhere Verfügbarkeit bessere Performance, sind einhaltbar, aber das ist nicht einfach Die höhere Komplexität erhöht auch die Fehleranfälligkeit und wirkt damit gegen das Verfügbarkeitsziel No single point of failure ist ein anspruchsvolles Ziel Man kann Prozessoren, Speicher, Platten, Netzwerkverbindungen, usw. mehrfach auslegen, aber was ist mit der Software?? den verwendeten Protokollen?? Data Sharing im Cluster mit / / 41 Software AG

42 Zum Schluss... Fragen?... Vielen Dank! Data Sharing im Cluster mit / / 42 Software AG

43 Data Sharing im Cluster mit / / 43 Software AG

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

Datenintegrität und Transaktionskonzept

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

Mehr

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

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

Mehr

27. 03. 2007 IT-Frühstück IT Trend Virtualisierung Hype oder Nutzen? Praxisaspekte

27. 03. 2007 IT-Frühstück IT Trend Virtualisierung Hype oder Nutzen? Praxisaspekte Ole Raether raether@oraservices.de 27. 03. 2007 IT-Frühstück IT Trend Virtualisierung Hype oder Nutzen? Praxisaspekte Inhalt oraservices.de Probleme: Failover Cluster, RAC 24*7 Fazit Was tun? oraservices.de

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Mehr

The Unbreakable Database System

The Unbreakable Database System The Unbreakable Database System Real Application Cluster Unterföhring, 04.2005 M. Kühn 1 Comparisson HA - HA Ziele, DataGuard, HA Oracle, RAC RAC Features - Cache Fusion, TAF, Load Balancing RAC on Solaris

Mehr

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

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

Mehr

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

RAC Architektur und Installation

<Insert Picture Here> RAC Architektur und Installation RAC Architektur und Installation Elmar Ströhmer Michael Künzner Oracle Server Technologies Competence Center Agenda Überblick und Architekturen von HA-Systemen Hardware Die Basis

Mehr

RAC auf Sun Cluster 3.0

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

Mehr

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

z/os System Logger Performance

z/os System Logger Performance z/os System Logger Performance Lahnstein 30.09.2011 Dagmar Fischer Ein Unternehmen der Finanz Informatik A g e n d a» z/os System Logger Performance System Logger Überblick LOGSTREAM Nutzung LOGSTREAM

Mehr

Oracle Automatic Storage Management (ASM) Best Practices

Oracle Automatic Storage Management (ASM) Best Practices Oracle Automatic Storage Management (ASM) Best Practices Markus Michalewicz BU Database Technologies ORACLE Deutschland GmbH 2 Page 1 www.decus.de 1 Agenda ASM Funktionalität und Architektur Storage Management

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

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

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

Mehr

Einführung in z/os Enterprise Computing

Einführung in z/os Enterprise Computing Einführung in z/os Enterprise Computing Prof. Dr. Martin Bogdan Dr. rer. nat. Paul Herrmannn Prof. Dr.-Ing. Wilhelm G. Spruth WS 2009/2010 Teil 12 Sysplex Coupling Facility es 0101 ww6 copyright W. G.

Mehr

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

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

Mehr

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

Enterprise Computing

Enterprise Computing Enterprise Computing Prof. Dr.-Ing. Wilhelm G. Spruth WS 2011/12 Teil 6 Sysplex und Coupling Facility Literatur Wilhelm G. Spruth, Erhard Rahm: Sysplex-Cluster Technologien für Hochleistungs-Datenbanken.

Mehr

MySQL Backup und Restore

MySQL Backup und Restore MySQL Backup und Restore DOAG Konferenz 2013 Nürnberg Oli Sennhauser Senior MySQL Consultant, FromDual GmbH oli.sennhauser@fromdual.com 1 / 22 Über FromDual GmbH FromDual bietet neutral und unabhängig:

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

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

Einführung in z/os und OS/390

Einführung in z/os und OS/390 Einführung in z/os und OS/390 Web-Services und Internet-Anwendungen für Mainframes von Paul Herrmann Wilhelm Gustav Spruth 3., verbesserte und erweiterte Auflage Oldenbourg Verlag München Vorwort VII 1

Mehr

Grid Computing in. komplexen Systemen. mit Blick auf RFID. Günther Stürner Vice President Business Unit Database & STCCs ORACLE Deutschland GmbH

Grid Computing in. komplexen Systemen. mit Blick auf RFID. Günther Stürner Vice President Business Unit Database & STCCs ORACLE Deutschland GmbH Grid Computing in komplexen Systemen mit Blick auf RFID Günther Stürner Vice President Business Unit Database & STCCs ORCLE Deutschland GmbH 2 Datenbanken sind die Basis für jede denkbare IT Lösung Infrastruktur

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

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem

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

Mehr

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

Client/Server-Systeme

Client/Server-Systeme Client/Server-Systeme Prof. Dr.-Ing. Wilhelm Spruth WS 2008/2009 Teil 11 Parallelrechner Sysplex Coupling Facility Symmetrischer Multiprozessor (SMP) CPU CPU CPU tightly coupled Hauptspeicher Cluster loosely

Mehr

Synchronisation von redundanten Datenbeständen

Synchronisation von redundanten Datenbeständen Synchronisation von redundanten Datenbeständen seit 1999 Themenübersicht Mobile Anwendungen Verteilte Datenbanksysteme Synchronisation Lösungsansätze Mobile Anwendungen Erwartungen der Anwender Der App-Stil

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

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

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

Clustering mit Shared Storage. Ing. Peter-Paul Witta paul.witta@cubit.at

Clustering mit Shared Storage. Ing. Peter-Paul Witta paul.witta@cubit.at Clustering mit Shared Storage Ing. Peter-Paul Witta paul.witta@cubit.at Clustering mehrere kleine Rechner leisten gemeinsam Grosses günstige dual intel/amd Server load sharing High Availability combined

Mehr

peer-to-peer Dateisystem Synchronisation

peer-to-peer Dateisystem Synchronisation Ziel Realisierungen Coda Ideen Fazit Literatur peer-to-peer Dateisystem Synchronisation Studiendepartment Informatik Hochschule für Angewandte Wissenschaften Hamburg 30. November 2007 Ziel Realisierungen

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

PowerWeiss Synchronisation

PowerWeiss Synchronisation PowerWeiss Synchronisation 1 Einrichtung der Synchronisation I. Starten des Synchronisations Wizard Seite 3 II. Schritt 1 - Benutzer auswählen Seite 3 III. Schritt 2 - Grundlegende Einstellungen Seite

Mehr

Enterprise Computing

Enterprise Computing Enterprise Computing Prof. Dr.-Ing. Wilhelm G. Spruth Teil 6 Partitionierung NUMA Sharing Disk Storage HP Superdome Cell Board 4 Itanium 2 CPU Chips 32 128 Gbyte I/O Bus mit Kühlern Hauptspeicher Anschlüsse

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

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

Gliederung Datenbanksysteme

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

Mehr

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

Einführung in z/os und OS/390

Einführung in z/os und OS/390 Einführung in z/os und OS/390 Dr. rer. nat. Paul Herrmannn Prof. Dr.-Ing. Wilhelm G. Spruth WS 2006/2007 Teil 11 Parallel Sysplex, Coupling Facility es 0101 ww6 wgs 09-99 zseries Coupling Facility Großrechner

Mehr

Handbuch Datensicherung

Handbuch Datensicherung Copyright 1995-2009 by winvs software AG, alle Rechte vorbehalten Gewähr Urheberrechte Haftung Die in diesem Handbuch enthaltenen Angaben sind ohne Gewähr und können jederzeit ohne vorherige Benachrichtigung

Mehr

Moderne Betriebssysteme. Kapitel 8. Kapitel 8. Folie: 1. Multiprozessorsysteme. Autor: Andrew S. Tanenbaum

Moderne Betriebssysteme. Kapitel 8. Kapitel 8. Folie: 1. Multiprozessorsysteme. Autor: Andrew S. Tanenbaum Moderne Betriebssysteme Kapitel 8 Multiprozessorsysteme Kapitel 8 Folie: 1 Multiprozessorsysteme Autor: Andrew S. Tanenbaum Pearson Studium 2009 2 3 4 5 6 7 Betriebssystemarten für Multiprozessoren Jede

Mehr

Enterprise Computing Einführung in das Betriebssystem z/os. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/13

Enterprise Computing Einführung in das Betriebssystem z/os. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/13 UNIVERSITÄT LEIPZIG Enterprise Computing Einführung in das Betriebssystem z/os Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/13 Verarbeitungsgrundlagen Teil 2 Virtual Storage el0100 copyright

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

Storage-Trends am LRZ. Dr. Christoph Biardzki

Storage-Trends am LRZ. Dr. Christoph Biardzki Storage-Trends am LRZ Dr. Christoph Biardzki 1 Über das Leibniz-Rechenzentrum (LRZ) Seit 50 Jahren Rechenzentrum der Bayerischen Akademie der Wissenschaften IT-Dienstleister für Münchner Universitäten

Mehr

Kapitel 14 Verteilte DBMS

Kapitel 14 Verteilte DBMS Kapitel 14 Verteilte DBMS 14 Verteilte DBMS 14 Verteilte DBMS...1 14.1 Begriff, Architektur und Ziele verteilter Datenbanksysteme...2 14.2 Verteilungsarten...5 14.2.1 Verteilung der Daten...5 14.2.2 Verteilung

Mehr

Recovery- und Buffermanager

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

Mehr

Übersicht. UNIX-Dateisystem (ext2) Super-User unter Linux werden MSDOS: FAT16 und FAT32

Übersicht. UNIX-Dateisystem (ext2) Super-User unter Linux werden MSDOS: FAT16 und FAT32 Übersicht UNIX-Dateisystem (ext2) Super-User unter Linux werden MSDOS: FAT16 und FAT32 Die in diesem Teil vorgestellten Informationen stellen lediglich das Prinzip dar - im Detail ist alles etwas komplizierter...

Mehr

Oracle 12c Real Application Cluster (RAC) und Grid Infrastructure

Oracle 12c Real Application Cluster (RAC) und Grid Infrastructure Oracle 12c Real Application Cluster (RAC) und Grid Infrastructure Seminarunterlage Version: 12.05 Version 12.05 vom 4. Februar 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten.

Mehr

Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008

Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008 Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008 Jörg Rödel Virtualization - Whats out there? Virtualisierung hat bereits längere Geschichte auf x86 Startete mit VMware Setzte

Mehr

Verschiedene Arten des Datenbankeinsatzes

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

Mehr

Oracle Datenbank Architektur nicht nur für Einsteiger. Martin Klier Klug GmbH integrierte Systeme, Teunz

Oracle Datenbank Architektur nicht nur für Einsteiger. Martin Klier Klug GmbH integrierte Systeme, Teunz Oracle Datenbank Architektur nicht nur für Einsteiger Martin Klier Klug GmbH integrierte Systeme, Teunz DOAG Webinar, 08.03.2012 Referent Martin Klier Datenbankadministrator für Fachliche Schwerpunkte:

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

3. Stud.IP-Entwickler-Workshop 2. Juni 2006 Workshop 3c: Stud.IP-Enterprise-Edition André Noack, Frank Elsner

3. Stud.IP-Entwickler-Workshop 2. Juni 2006 Workshop 3c: Stud.IP-Enterprise-Edition André Noack, Frank Elsner 3. Stud.IP-Entwickler-Workshop 2. Juni 2006 Workshop 3c: Stud.IP-Enterprise-Edition André Noack, Frank Elsner Gliederung Das Problem: Skalierbarkeit LAMP Tuning Mehr als ein Server Stud.IP und shared nothing

Mehr

Abschluss Einblick und Ausblick

Abschluss Einblick und Ausblick Abschluss Einblick und Ausblick Prof. Dr. T. Kudraß 1 Benutzer Komponenten eines DBMS (Überblick) I/O-Prozessor Output-Generierung Parser für selbst. oder eingebettete Kommandos Precompiler Autorisierungs-Kontrolle

Mehr

Markus Feichtinger. Power Systems. Der Weg zu POWER! 2009 IBM Corporation

Markus Feichtinger. Power Systems. Der Weg zu POWER! 2009 IBM Corporation Markus Feichtinger Power Systems Der Weg zu POWER! Agenda Motivation Lösung Beispiel Export / Import - Überblick - Migration Beispiel XenoBridge - Überblick - Migration Benefits 2 Motivation Strategisch

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

Solaris im Datacenter Architektur, Implementation und Betrieb

Solaris im Datacenter Architektur, Implementation und Betrieb Solaris im Datacenter Architektur, Implementation und Betrieb Marco Stadler stadler@jomasoft.ch Senior Technical Specialist JomaSoft GmbH 1 2 Inhalt Wer ist JomaSoft? Architektur: Zonen und LDoms Implementation

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

11. Mehrrechner-DBMSe / Datenbankmaschinen

11. Mehrrechner-DBMSe / Datenbankmaschinen 11. Mehrrechner-e / Datenbankmaschinen In der Vergangenheit DB-Maschinen oft auf Basis von Spezial-HW-/SW Schnittstelle Anwendungsprogramm - DB-Maschine oft "nicht hoch" genug Interaktion und Integration

Mehr

Einführung. Kapitel 1 2 / 508

Einführung. Kapitel 1 2 / 508 Kapitel 1 Einführung 2 / 508 Einführung Was ist ein Datenbanksystem (DBS)? Ein System zum Speichern und Verwalten von Daten. Warum kein herkömmliches Dateisystem verwenden? Ausfallsicherheit und Skalierbarkeit

Mehr

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

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

Mehr

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

WISSENSWERTES ÜBER WINDOWS SCALE-OUT FILE SERVER

WISSENSWERTES ÜBER WINDOWS SCALE-OUT FILE SERVER WISSENSWERTES ÜBER WINDOWS SCALE-OUT FILE SERVER AGENDA 01 File Server Lösungen mit Windows Server 2012 R2 02 Scale-out File Server 03 SMB 3.0 04 Neue File Server Features mit Windows Server 2016 05 Storage

Mehr

Verteilte Dateisysteme

Verteilte Dateisysteme Verteilte Dateisysteme Proseminar: Speicher und Dateisysteme Hauke Holstein Gliederung 1/23 - Einleitung - NFS - AFS - SMB Einleitung Was sind Verteilte Dateisysteme? 2/23 - Zugriff über ein Netzwerk -

Mehr

Hochverfügbarkeit mit Windows Server vnext. Carsten Rachfahl Microsoft Hyper-V MVP

Hochverfügbarkeit mit Windows Server vnext. Carsten Rachfahl Microsoft Hyper-V MVP Hochverfügbarkeit mit Windows Server vnext Carsten Rachfahl Microsoft Hyper-V MVP Carsten Rachfahl www.hyper-v-server.de Roling Cluster Upgrade Herausforderung: Update eines Failover Clusters ohne Downtime

Mehr

Infrastrukturanalyse Ihr Weg aus dem Datenstau

Infrastrukturanalyse Ihr Weg aus dem Datenstau Waltenhofen * Düsseldorf * Wiesbaden Infrastrukturanalyse Ihr Weg aus dem Datenstau SCALTEL Webinar am 20. Februar 2014 um 16:00 Uhr Unsere Referenten Kurze Vorstellung Stefan Jörg PreSales & Business

Mehr

Betriebssysteme K_Kap11C: Diskquota, Raid

Betriebssysteme K_Kap11C: Diskquota, Raid Betriebssysteme K_Kap11C: Diskquota, Raid 1 Diskquota Mehrbenutzer-BS brauchen einen Mechanismus zur Einhaltung der Plattenkontingente (disk quotas) Quota-Tabelle enthält Kontingenteinträge aller Benutzer

Mehr

whitepaper CLOUD-ENTWICKLUNG: BESTE METHODEN UND SUPPORT-ANWENDUNGEN

whitepaper CLOUD-ENTWICKLUNG: BESTE METHODEN UND SUPPORT-ANWENDUNGEN whitepaper CLOUD-ENTWICKLUNG: BESTE METHODEN UND SUPPORT-ANWENDUNGEN CLOUD-ENTWICKLUNG: BESTE METHODEN 1 Cloud-basierte Lösungen sind auf dem IT-Markt immer weiter verbreitet und werden von immer mehr

Mehr

Teil VI. Datenbanken

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

Mehr

... 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

A Kompilieren des Kernels... 247. B Lineare Listen in Linux... 251. C Glossar... 257. Interessante WWW-Adressen... 277. Literaturverzeichnis...

A Kompilieren des Kernels... 247. B Lineare Listen in Linux... 251. C Glossar... 257. Interessante WWW-Adressen... 277. Literaturverzeichnis... 1 Einführung................................................ 1 1.1 Was ist ein Betriebssystem?............................... 1 1.1.1 Betriebssystemkern................................ 2 1.1.2 Systemmodule....................................

Mehr

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008

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

Mehr

Verteilte Systeme. Einführung. Prof. Dr. Oliver Haase

Verteilte Systeme. Einführung. Prof. Dr. Oliver Haase Verteilte Systeme Einführung Prof. Dr. Oliver Haase 1 Definition A distributed system is a collection of independent computers that appears to its users as a single coherent system. - Andrew Tanenbaum

Mehr

Replikation und Synchronisation. in mobilen Datenbanksystemen

Replikation und Synchronisation. in mobilen Datenbanksystemen in mobilen Datenbanksystemen 6. Juni 2002 Von Thomas Hoffmann und Sebastian Seidler E-Mail: {hothomas,bastl14w}@minet.uni-jena.de 1 Inhalt Einleitung Was ist Replikation? Was ist Synchronisation? Replikationsverfahren

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

Betriebssysteme K_Kap11B: Files, Filesysteme Datenstrukturen

Betriebssysteme K_Kap11B: Files, Filesysteme Datenstrukturen Betriebssysteme K_Kap11B: Files, Filesysteme Datenstrukturen 1 Files als lineare Liste File angeordnet als verkette Liste von Blöcken Jeder Block enthält Zeiger zum Nachfolger Zeiger = Adresse des Blocks

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

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

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

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

Mehr

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 5 26.11.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1: Erläutern

Mehr

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit 1 Hochverfügbarkeit Lernziele: Network Load Balancing (NLB) Failover-Servercluster Verwalten der Failover Cluster Rolle Arbeiten mit virtuellen Maschinen Prüfungsanforderungen von Microsoft: Configure

Mehr

Verteiltes Persistenz-System. Mykhaylo Kabalkin

Verteiltes Persistenz-System. Mykhaylo Kabalkin Verteiltes Persistenz-System Mykhaylo Kabalkin 01.12.2006 Übersicht Motivation und Problematik Ziel Anforderungen Systemarchitektur erster Entwurf Architekturkomponenten Risiken 01.12.2006 Seminar Ringvorlesung

Mehr

www.raber-maercker.de Herzlich willkommen!

www.raber-maercker.de Herzlich willkommen! www.raber-maercker.de Herzlich willkommen! Raber+Märcker GmbH Hochverfügbarkeit für Dynamics NAV-, Exchange- und SQL-Server Thomas Kuhn Microsoft Certified Solution Developer Teamleiter Server Applications

Mehr