Kapitel 8 Verteilte Datenbanken Flien zum Datenbankpraktikum Wintersemester 2010/11 LMU München 2008 Thmas Bernecker, Tbias Emrich unter Verwendung der Flien des Datenbankpraktikums aus dem Wintersemester 2007/08 vn Dr. Matthias Schubert 8.1 Client-Server-Architektur Übersicht 8.2 Unterstützte Rechnerarchitekturen 8.3 Oracle Parallel Server 8.4 Verteilte Datenbanken LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 2
Client-Server-Architektur Ein Datenbanksystem beinhaltet in der Regel einen Datenbank-Server, der die ihm angetragenen Datenbankperatinen ausführt. In der ORACLE- Architektur bildet die sgenannte ORACLE-Instanz den Kern des Datenbanksystems. Eine ORACLE-Instanz verwaltet genau eine zugehörige Datenbank. Es besteht als eine lgische Trennung zwischen der Datenbank und der verwaltenden Instanz. Eine Instanz kann zu verschiedenen Zeitpunkten an verschiedene Datenbanken gekppelt sein. ORACLE unterscheidet zwei Knfiguratinsvarianten, welche die Kmmunikatin der Anwendungsprzesse mit der Datenbank-Instanz festlegen: Dedicated-Server-Cnfiguratin (DS): An jeden Anwendungsprzess wird ein eigener Server-Przess gebunden, der die Anfrderungen des Anwendungsprzesses bearbeitet. b t Dynamic Multi-Threaded-Server-Cnfiguratin (MTS): Die Anwendungsprzesse kmmunizieren mit einem ORACLE-Dispatcher, der die Anfrderungen in eine Warteschlange in der System Glbal Area (SGA) einreiht. Der Auftrag wird dann durch einen beliebigen vm Dispatcher zugerdneten Server-Przess bearbeitet. LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 3 Die beiden Knfiguratinsvarianten schließen sich dabei nicht gegenseitig aus, sndern können zeitgleich im System laufen. Anwendungsprzesse ORACLE- Datenbankinstanz DS Server-Przess DS Server-Przess Dispatch er S G A DBWR LGWR SMON PMON Hinter rgrundprzes sse ORACLE- Datenbank MTS Bei der Verbindung mit einer ORACLE-Instanz lässt sich die Knfiguratinsvariante einstellen, z.b. (bei entsprechenden Einträgen in der Datei tnsnames.ra ) CONNECT <User>/<Passwrt>@db_mts CONNECT <User>/<Passwrt>@db_ds LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 4
8.1 Client-Server-Architektur Übersicht 8.2 Unterstützte Rechnerarchitekturen 8.3 Oracle Parallel Server 8.4 Verteilte Datenbanken LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 5 Unterstützte Rechnerarchitekturen ORACLE unterstützt im wesentlichen vier Rechnerarchitekturen: Ein-Przessr-System (EP): Ein im allgemeinen leistungsstarkes Rechnersystem mit einem Przessr. Symmetrisches Multi-Przessr-System (SMP): Das Rechnersystem beinhaltet mehrere gleichberechtigte g Przessren, die einen gemeinsamen Hauptspeicher p teilen (Shared-Everything- der Shared-Memry-System). Cluster-System (CS): Das System besteht aus mehreren unabhängigen Rechnern mit jeweils eigenen Hauptspeicher. Auf die Sekundärspeichersysteme (Festplatten) hat allerdings jeder Rechner Zugriff (Shared-Disk-System). d k S t ) Massiv-Parallel-Systeme (MPP): Diese Systeme bieten eine hhe Anzahl vn Einzelprzessren (bis zu mehreren 1000), die über einen eigenen Hauptspeicher und einen eigenen Sekundärspeicher verfügen (Shared-Nthing-System). In der Standardausstattung unterstützt ORACLE swhl EP- als auch SMP- Architekturen. Um CS- und MPP-Architekturen verwenden zu können, ist eine spezielle parallele Erweiterung vn ORACLE erfrderlich (Oracle Parallel Server, kurz OPS). LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 6
8.1 Client-Server-Architektur Übersicht 8.2 Unterstützte Rechnerarchitekturen 8.3 Oracle Parallel Server 8.4 Verteilte Datenbanken LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 7 Oracle Parallel Server Die OPS-Optin srgt dafür, dass ORACLE aus der vrhandenen Rechnerarchitektur ptimalen Nutzen zieht. Jeder Rechner erhält eine ORACLE-Instanz (pr Datenbank auf dem Rechner) mit den jeweiligen Hintergrundprzessen und einer eigenen SGA. Wird eine Datenbank durch mehrere (auf verschiedene Rechner verteilte) ORACLE-Instanzen verwaltet, dann können in Abhängigkeit vn den Anwendungen flgende Vrteile erzielt werden: Ist die Anwendung durch kurze Transaktinen mit wenig CPU- und I/O-Aufwand charakterisiert (z.b. OLTP), dann werden Transaktinen auf die beteiligten Przessren verteilt, wdurch eine Erhöhung des Durchsatzes erreicht wird. Zeichnet sich die Applikatin durch aufwändige Transaktinen mit hhen CPU- und I/O-Ksten aus (z.b. OLAP), kann die Ausführung einer Transaktin auf den beteiligten Przessren parallel verarbeitet werden. Dies führt zu einer Beschleunigung der Anwendung (Speed-Up). Die OPS-Optin bietet eine erhöhte Fehlertleranz gegenüber Rechnerausfällen. Fällt ein Rechner mit einer aktiven ORACLE-Instanz aus, dann stellt ORACLE die Knsistenz der betrffenen Datenbanken durch eine andere Instanz autmatisch wieder her. LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 8
8.1 Client-Server-Architektur Übersicht 8.2 Unterstützte Rechnerarchitekturen 8.3 Oracle Parallel Server 8.4 Verteilte Datenbanken LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 9 Verteilte Datenbanken Sind in einem Rechnerverbund mehrere Datenbanken (mit ihren ORACLE- Instanzen) aktiv, ist der Zusammenschluss zu einer verteilten Datenbank möglich. Im Gegensatz zu einem parallelen Server sind die Daten dauerhaft über die beteiligten Instanzen partitiniert und der Ausfall einer Instanz kann nicht durch eine andere Instanz abgefangen werden. Eine verteilte Datenbank bietet neben dem entfernten Datenbankzugriff nch weitere Unterstützung: SQL-Anfragen können sich auf Tabellen verschiedener Datenbanken beziehen. Smit sind datenbankübergreifende Jins möglich. ORACLE kümmert sich intern um eine geeignete Aufteilung der SQL-Anweisung und das Zusammenführen der Einzelergebnisse zum Gesamtergebnis. Es lassen sich Transaktinen bilden, die Operatinen auf mehreren Datenbanken erfrdern. ORACLE verwaltet bei der Ausführung die beteiligten Rechnerplattfrmen (Windws NT, Unix) und die darunterliegenden Netzwerk-Prtklle. LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 10
Einbettung vn Anwendungen in die verteilte Umgebung Um Anwendungen in die verteilte Umgebung einzubetten, sind flgende Schritte ntwendig: 1. Alle Datenbankinstanzen müssen administrativ dem Datenbanksystem als <DB-Alias> bekannt gemacht werden. Dafür steht die Datei tnsnames.ra zur Verfügung, g, in welche die zu den <DB-Alias> gehörenden Rechneradressen eingetragen werden müssen. 2. Verbinden mit einer Datenbank: CONNECT <User>/<Passwrt>@<DB-Alias> 3. Um vn dem Prgramm aus auch auf andere Datenbanken zuzugreifen, ist ein sgenannter Datenbank-Link erfrderlich. Durch diesen wird die Anwendung mit der entsprechenden Datenbank verbunden: CREATE DATABASE LINK <DB-Link> USING <DB-Alias2>; 4. Vn nun an kann ein SQL-Befehl über <Name>@<DB-Link> Bezug auf Schemabjekte dieser Datenbank (Tabellen, Sichten, Przeduren, etc.) nehmen. LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 11 Sichten und Synnyme Um die Handhabung zu vereinfachen, sind Sichten und Synnyme nützlich. Eine Sicht lässt sich wie flgt definieren, s dass anschließend die Tabelle über <Sicht> direkt, d.h. hne Angabe des Datenbank-Links, angesprchen werden kann. CREATE VIEW <Sicht> AS SELECT * FROM <Tabelle>@<DB-Link>; Ein Synnym kann in ähnlicher Weise eingerichtet werden. Der Synnymname y fungiert anschließend wie ein Tabellenname. CREATE SYNONYM <Synnym> FOR <Tabelle>@<DB-Link>; LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 12
Datenbank-Operatinen Die Datenbank-Operatinen werden vn ORACLE wie flgt auf das verteilte System abgebildet: Einfache verteilte Leseperatinen: Es werden nur Objekte aus genau einer Remte-Datenbank angefragt (es sind keine lkalen Objekte an der Operatin beteiligt). In diesem Fall wird die Anweisung an die entsprechende ORACLE-Instanz weitergereicht. Beispiel: select * frm mitarbeiter@db1 where salary>5000; Kmplexe verteilte Leseperatinen: An der Operatin sind Objekte aus mehreren Datenbanken beteiligt. Der lkale Server zerlegt die SQL- Anweisung in Subbefehle und reicht diese an die entsprechenden ORACLE- Instanzen weiter. Beispiel: select * frm mitarbeiter@db1 m, abteilung@db2 a where... ; LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 13 Verteilte Schreibperatinen sind grundsätzlich durch das Transaktinsknzept abgesichert: Lkale Transaktin: Es werden nur Objekte in der lkalen Datenbank geändert. Die Verarbeitung läuft wie im nicht-verteilten t ilt Fall. Remte Transaktin: Nur Tabellen, die sich auf genau einem Remte- Server befinden, werden verändert. Diese Operatinen werden durch die gewöhnliche Transaktinsverwaltung auf dem Remte-Server verarbeitet. Beispiel: update mitarbeiter@db1 set gehalt = gehalt * 1.2 where salary>5000 ; Verteilte Transaktin: Es werden Tabellen auf mehreren Datenbank-Servern verändert. Die Bearbeitung slcher Transaktinen stützt sich auf das 2- Phasen-Cmmit-Prtkll. LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 14
Transaktinskntrlle ORACLE verwendet hierfür ein 2-Phasen-Cmmit-Prtkll: 1. Phase: Abstimmung der Teilnehmer Die erste Phase besteht aus dem Vrbereiten der Transaktin, in der die beteiligten Instanzen die lkale Transaktin durchführen hne abschließend ein Cmmit abzusetzen. Jede Instanz sendet ein Vte Cmmit der ein Vte Abrt an den Krdinatr und wartet anschließend auf dessen glbale Entscheidung. 2. Phase: Entscheidung des Krdinatrs Der Krdinatr erhält die Ergebnisse aller Teilnehmer und fällt eine glbale Entscheidung. Liefern alle Teilnehmer Vte Cmmit, s entscheidet der Krdinatr cmmit. Liefert (mindestens) ein Teilnehmer Vte Abrt, s entscheidet der Krdinatr abrt. LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 15 Replikatin Im engen Zusammenhang mit verteilten Datenbanken steht das Knzept der Replikatin. Hier werden Daten aus Gründen der besseren Verfügbarkeit der des schnelleren lkalen Zugriffs redundant in mehreren Datenbanken gehalten. Das Datenbanksystem muss dann gewährleisten, dass die redundanten Daten miteinander abgeglichen werden. ORACLE bietet drei Replikatinsmechanismen. Die ersten beiden beruhen auf einem Master/Slave-Prinzip, bei dem die Slave-Datenbank nur lesenden Zugriff erhält. Asynchrne Replikatin: Die redundanten Daten in der Slave-Datenbank werden peridisch auf den aktuellen Stand der Master-Datenbank gebracht. ORACLE bietet hierfür den Schnappschuss-Mechanismus an. Beispiel: CREATE SNAPSHOT <Schnappschuss> REFRESH <Refresh_Klausel> AS... ; LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 16
Synchrne Replikatin: Die redundanten Daten in der Slave-Datenbank werden gleichzeitig mit den Daten in der Master-Datenbank aktualisiert. Synchrne Lese/Schreib-Replikatin: Änderungen sind swhl auf der Slave- als auch auf der Master-Datenbank erlaubt. Die Datenbanken werden nach jeder Änderung auf den neuesten Stand gebracht. Die Synchrnisatin der replizierten Datenbankbjekte wird dabei über interne Trigger realisiert. Diese werden vn ORACLE autmatisch generiert und sind in eine übergreifende Transaktinskntrlle eingebettet (garantieren als knsistente Replikate). Für das Management vn Replikatin bietet ORACLE als Tl den Replicatin Manager an. LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 17