Verteilte Datenbanken - DBS
Werbung
Kapitel 8 Verteilte Datenbanken Folien zum Datenbankpraktikum Wintersemester 2010/11 LMU München © 2008 Thomas Bernecker, Tobias Emrich unter Verwendung der Folien des Datenbankpraktikums aus dem Wintersemester 2007/08 von Dr. Matthias Schubert 8 Verteilte Datenbanken Übersicht 8 1 Client 8.1 Client-Server-Architektur Server Architektur 8.2 Unterstützte Rechnerarchitekturen 8.3 Oracle Parallel Server 8 4 Verteilte Datenbanken 8.4 LMU München – Folien zum Datenbankpraktikum – Wintersemester 2010/11 2 8 Verteilte Datenbanken Client-Server-Architektur o Ein Datenbanksystem beinhaltet in der Regel einen Datenbank-Server, der die ihm angetragenen Datenbankoperationen ausführt. In der ORACLEArchitektur bildet die sogenannte ORACLE-Instanz den Kern des Datenbanksystems. o Eine ORACLE ORACLE-Instanz Instanz verwaltet genau eine zugehörige Datenbank. Es besteht also eine logische Trennung zwischen der Datenbank und der verwaltenden Instanz. Eine Instanz kann zu verschiedenen Zeitpunkten an gekoppelt pp sein. verschiedene Datenbanken g o ORACLE unterscheidet zwei Konfigurationsvarianten, welche die Kommunikation der Anwendungsprozesse mit der Datenbank-Instanz festlegen: • • Dedicated-Server-Configuration (DS): An jeden Anwendungsprozess wird ein eigener Server-Prozess gebunden, der die Anforderungen des A Anwendungsprozesses d b b it t bearbeitet. Dynamic Multi-Threaded-Server-Configuration (MTS): Die Anwendungsprozesse kommunizieren mit einem ORACLE-Dispatcher, der die Anforderungen in eine Warteschlange in der System Global Area (SGA) einreiht. einreiht Der Auftrag wird dann durch einen beliebigen vom Dispatcher zugeordneten Server-Prozess bearbeitet. LMU München – Folien zum Datenbankpraktikum – Wintersemester 2010/11 3 8 Verteilte Datenbanken Die beiden Konfigurationsvarianten schließen sich dabei nicht gegenseitig aus, sondern können zeitgleich im System laufen. Anwendungsprozesse ORACLEDatenbankinstanz DS Server-Prozess DBWR DS S Server-Prozess P LGWR Dispatcher S G A SMON Hinterrgrundprozes sse o ORACLEDatenbank PMON MTS o Bei der Verbindung mit einer ORACLE-Instanz ORACLE Instanz lässt sich die Konfigurationsvariante einstellen, z.B. (bei entsprechenden Einträgen in der Datei ’tnsnames.ora’) CONNECT <User>/<Passwort>@db_mts CONNECT <User>/<Passwort>@db_ds LMU München – Folien zum Datenbankpraktikum – Wintersemester 2010/11 4 8 Verteilte Datenbanken Übersicht 8 1 Client 8.1 Client-Server-Architektur Server Architektur 8.2 Unterstützte Rechnerarchitekturen 8.3 Oracle Parallel Server 8 4 Verteilte Datenbanken 8.4 LMU München – Folien zum Datenbankpraktikum – Wintersemester 2010/11 5 8 Verteilte Datenbanken Unterstützte Rechnerarchitekturen o ORACLE unterstützt im wesentlichen vier Rechnerarchitekturen: • • • • Ein-Prozessor-System Ein Prozessor System (EP): Ein im allgemeinen leistungsstarkes Rechnersystem mit einem Prozessor. Symmetrisches Multi-Prozessor-System (SMP): Das Rechnersystem beinhaltet mehrere g gleichberechtigte g Prozessoren, die einen g gemeinsamen Hauptspeicher p p teilen (Shared-Everything- oder Shared-Memory-System). Cluster-System (CS): Das System besteht aus mehreren unabhängigen Rechnern mit jeweils eigenen Hauptspeicher. Auf die Sekundärspeichersysteme (Festplatten) h t allerdings hat ll di jjeder d R Rechner h Z Zugriff iff (Sh (Shared-Disk-System). d Di k S t ) Massiv-Parallel-Systeme (MPP): Diese Systeme bieten eine hohe Anzahl von Einzelprozessoren (bis zu mehreren 1000), die über einen eigenen Hauptspeicher und einen eigenen Sekundärspeicher verfügen (Shared-Nothing-System) (Shared-Nothing-System). o In der Standardausstattung unterstützt ORACLE sowohl EP- als auch SMPArchitekturen Um CS- und MPP-Architekturen verwenden zu können Architekturen. können, ist eine spezielle parallele Erweiterung von ORACLE erforderlich (Oracle Parallel Server, kurz OPS). LMU München – Folien zum Datenbankpraktikum – Wintersemester 2010/11 6 8 Verteilte Datenbanken Übersicht 8 1 Client 8.1 Client-Server-Architektur Server Architektur 8.2 Unterstützte Rechnerarchitekturen 8.3 Oracle Parallel Server 8 4 Verteilte Datenbanken 8.4 LMU München – Folien zum Datenbankpraktikum – Wintersemester 2010/11 7 8 Verteilte Datenbanken Oracle Parallel Server o Die OPS-Option sorgt dafür, dass ORACLE aus der vorhandenen Rechnerarchitektur optimalen Nutzen zieht. Jeder Rechner erhält eine ORACLE-Instanz (pro Datenbank auf dem Rechner) mit den jeweiligen Hintergrundprozessen und einer eigenen SGA. o Wird eine Datenbank durch mehrere (auf verschiedene Rechner verteilte) ORACLE-Instanzen verwaltet, dann können in Abhängigkeit von den Anwendungen folgende Vorteile erzielt werden: • • Ist die Anwendung durch kurze Transaktionen mit wenig CPU CPU- und I/O-Aufwand I/O Aufwand charakterisiert (z.B. OLTP), dann werden Transaktionen auf die beteiligten Prozessoren verteilt, wodurch eine Erhöhung des Durchsatzes erreicht wird. Zeichnet sich die Applikation durch aufwändige Transaktionen mit hohen CPUCPU und I/O-Kosten aus (z.B. OLAP), kann die Ausführung einer Transaktion auf den beteiligten Prozessoren parallel verarbeitet werden. Dies führt zu einer Beschleunigung der Anwendung (Speed-Up). o Die OPS-Option bietet eine erhöhte Fehlertoleranz gegenüber Rechnerausfällen. Fällt ein Rechner mit einer aktiven ORACLE-Instanz aus, dann stellt ORACLE die Konsistenz der betroffenen Datenbanken durch eine andere Instanz automatisch wieder her. LMU München – Folien zum Datenbankpraktikum – Wintersemester 2010/11 8 8 Verteilte Datenbanken Übersicht 8 1 Client 8.1 Client-Server-Architektur Server Architektur 8.2 Unterstützte Rechnerarchitekturen 8.3 Oracle Parallel Server 8 4 Verteilte Datenbanken 8.4 LMU München – Folien zum Datenbankpraktikum – Wintersemester 2010/11 9 8 Verteilte Datenbanken Verteilte Datenbanken o Sind in einem Rechnerverbund mehrere Datenbanken (mit ihren ORACLEInstanzen) aktiv, ist der Zusammenschluss zu einer verteilten Datenbank möglich. Im Gegensatz zu einem parallelen Server sind die Daten dauerhaft über die beteiligten Instanzen partitioniert und der Ausfall einer Instanz kann nicht durch eine andere Instanz abgefangen werden. o Eine verteilte Datenbank bietet neben dem entfernten Datenbankzugriff noch weitere Unterstützung: • • • SQL-Anfragen SQL A f können kö sich i h auff Tabellen T b ll verschiedener hi d D Datenbanken t b k beziehen. Somit sind datenbankübergreifende Joins möglich. ORACLE kümmert sich intern um eine geeignete Aufteilung der SQL-Anweisung und das Zusammenführen der Einzelergebnisse zum Gesamtergebnis. Gesamtergebnis Es lassen sich Transaktionen bilden, die Operationen auf mehreren Datenbanken erfordern. ORACLE verwaltet bei der Ausführung die beteiligten Rechnerplattformen (Windows NT, Unix) und die darunterliegenden Netzwerk-Protokolle. LMU München – Folien zum Datenbankpraktikum – Wintersemester 2010/11 10 8 Verteilte Datenbanken Einbettung von Anwendungen in die verteilte Umgebung Um Anwendungen in die verteilte Umgebung einzubetten, sind folgende Schritte notwendig: 1. Alle Datenbankinstanzen müssen administrativ dem Datenbanksystem als <DB-Alias> bekannt gemacht werden. Dafür steht die Datei ’tnsnames.ora’ g g, in welche die zu den <DB-Alias> g gehörenden zur Verfügung, Rechneradressen eingetragen werden müssen. 2. Verbinden mit einer Datenbank: CONNECT <User>/<Passwort>@<DB-Alias> 3. Um von dem Programm aus auch auf andere Datenbanken zuzugreifen, ist ein sogenannter Datenbank-Link Datenbank Link erforderlich. erforderlich Durch diesen wird die Anwendung mit der entsprechenden Datenbank verbunden: CREATE DATABASE LINK <DB-Link> USING <DB-Alias2>; 4. Von nun an kann ein SQL-Befehl über <Name>@<DB-Link> Bezug auf Schemaobjekte dieser Datenbank (Tabellen, Sichten, Prozeduren, etc.) nehmen. LMU München – Folien zum Datenbankpraktikum – Wintersemester 2010/11 11 8 Verteilte Datenbanken Sichten und Synonyme o Um die Handhabung zu vereinfachen, sind Sichten und Synonyme nützlich. o Eine Sicht lässt sich wie folgt definieren, definieren so dass anschließend die Tabelle über <Sicht> direkt, d.h. ohne Angabe des Datenbank-Links, angesprochen werden kann. CREATE VIEW <Si <Sicht> ht> AS SELECT * FROM <T <Tabelle>@<DB-Link>; b ll >@<DB Li k> o Ein Synonym kann in ähnlicher Weise eingerichtet werden. Der y y fungiert g anschließend wie ein Tabellenname. Synonymname CREATE SYNONYM <Synonym> FOR <Tabelle>@<DB-Link>; LMU München – Folien zum Datenbankpraktikum – Wintersemester 2010/11 12 8 Verteilte Datenbanken Datenbank-Operationen Die Datenbank-Operationen werden von ORACLE wie folgt auf das verteilte System abgebildet: o Einfache verteilte Leseoperationen: Es werden nur Objekte aus genau einer Remote-Datenbank angefragt (es sind keine lokalen Objekte an der Operation beteiligt). In diesem Fall wird die Anweisung an die entsprechende ORACLE-Instanz weitergereicht. Beispiel: select * from mitarbeiter@db1 where salary>5000; o Komplexe verteilte Leseoperationen: An der Operation sind Objekte aus mehreren Datenbanken beteiligt. Der lokale Server zerlegt die SQLAnweisung in Subbefehle und reicht diese an die entsprechenden ORACLEInstanzen weiter. Beispiel: select * from mitarbeiter@db1 m, abteilung@db2 a where ... ; LMU München – Folien zum Datenbankpraktikum – Wintersemester 2010/11 13 8 Verteilte Datenbanken Verteilte Schreiboperationen sind grundsätzlich durch das Transaktionskonzept abgesichert: o Lokale Transaktion: Es werden nur Objekte in der lokalen Datenbank geändert. ä d t Di Die V Verarbeitung b it lä läuft ft wie i iim nicht-verteilten i ht t ilt Fall. F ll o Remote Transaktion: Nur Tabellen, die sich auf genau einem Remotep werden durch die Server befinden, werden verändert. Diese Operationen gewöhnliche Transaktionsverwaltung auf dem Remote-Server verarbeitet. Beispiel: update mitarbeiter@db1 set gehalt = gehalt * 1.2 where salary>5000 ; o Verteilte Transaktion: Es werden Tabellen auf mehreren Datenbank-Servern verändert. Die Bearbeitung solcher Transaktionen stützt sich auf das 2Phasen-Commit-Protokoll. LMU München – Folien zum Datenbankpraktikum – Wintersemester 2010/11 14 8 Verteilte Datenbanken Transaktionskontrolle ORACLE verwendet hierfür ein 2-Phasen-Commit-Protokoll: o 1. 1 Phase: Abstimmung der Teilnehmer Die erste Phase besteht aus dem Vorbereiten der Transaktion, in der die beteiligten Instanzen die lokale Transaktion durchführen ohne abschließend ein i C Commit it abzusetzen. b t JJede d IInstanz t sendet d t ein i „Vote V t Commit” C it” oder d ein i „Vote Abort” an den Koordinator und wartet anschließend auf dessen globale Entscheidung. o 2. Phase: Entscheidung des Koordinators Der Koordinator erhält die Ergebnisse aller Teilnehmer und fällt eine globale Entscheidung Liefern alle Teilnehmer „Vote Entscheidung. Vote Commit Commit”, so entscheidet der Koordinator „commit”. Liefert (mindestens) ein Teilnehmer „Vote Abort”, so entscheidet der Koordinator „abort”. LMU München – Folien zum Datenbankpraktikum – Wintersemester 2010/11 15 8 Verteilte Datenbanken Replikation o Im engen Zusammenhang mit verteilten Datenbanken steht das Konzept der Replikation. Hier werden Daten aus Gründen der besseren Verfügbarkeit oder des schnelleren lokalen Zugriffs redundant in mehreren Datenbanken gehalten. Das Datenbanksystem muss dann gewährleisten, dass die redundanten Daten miteinander abgeglichen werden. o ORACLE bietet drei Replikationsmechanismen. Die ersten beiden beruhen auf einem Master/Slave-Prinzip, bei dem die Slave-Datenbank nur lesenden Zugriff g erhält. • Asynchrone Replikation: Die redundanten Daten in der Slave-Datenbank werden periodisch auf den aktuellen Stand der Master-Datenbank gebracht. ORACLE bietet hierfür den Schnappschuss-Mechanismus Schnappschuss Mechanismus an. an Beispiel: CREATE SNAPSHOT <Schnappschuss> REFRESH <Refresh_Klausel> AS ... ; LMU München – Folien zum Datenbankpraktikum – Wintersemester 2010/11 16 8 Verteilte Datenbanken • • Synchrone Replikation: Die redundanten Daten in der Slave-Datenbank Slave Datenbank werden gleichzeitig mit den Daten in der Master-Datenbank aktualisiert. Synchrone Lese/Schreib-Replikation: Änderungen sind sowohl auf der Slave- als auch auf der Master-Datenbank erlaubt. erlaubt Die Datenbanken werden nach jeder Änderung auf den neuesten Stand gebracht. o Die Synchronisation der replizierten Datenbankobjekte wird dabei über interne Trigger realisiert. Diese werden von ORACLE automatisch generiert und sind in eine übergreifende Transaktionskontrolle eingebettet (garantieren also konsistente Replikate). Replikate) Für das Management von Replikation bietet ORACLE als Tool den Replication Manager an. LMU München – Folien zum Datenbankpraktikum – Wintersemester 2010/11 17
