Untersuchung verschiedener Replikationsverfahren unter IBM DB2
Werbung
Untersuchung verschiedener Replikationsverfahren unter IBM DB2 LUW am konkreten Beispiel der Digitalen Bibliothek der Friedrich-Schiller-Universität Jena und des Freistaates Thüringen Studienarbeit Andreas Krug [email protected] Betreuer Dipl.-Math. Ulrike Krönert Dipl.-Inf. Thomas Scheer Dipl.-Dok. Michael Lörzer Thüringer Universitäts- und Landesbibliothek Jena Bibliotheksplatz 2 07743 Jena und Prof. Dr. Klaus Küspert Friedrich-Schiller-Universität Jena Fakultät für Mathematik und Informatik Institut für Informatik Lehrstuhl für Datenbanken und Informationssysteme Ernst-Abbe-Platz 14 07743 Jena 01. Juli 2009 Kurzfassung Das Ziel dieser Studienarbeit liegt in der Untersuchung verschiedener Replikationsverfahren unter dem DBMS IBM DB2 LUW, der Auswahl eines geeigneten Verfahrens für ein konkretes Anwendungsbeispiel und der praktischen Anwendung des Verfahrens. Im ersten Schritt erfolgen hierzu die Begrisklärung der Hochverfügbarkeit und die Auseinandersetzung mit theoretischen Grundlagen der Replikation. Aufbauend auf diesen Grundlagen werden dann die drei betrachteten Replikationsverfahren, d.h. die SQL- und QReplikation sowie das HADR-Verfahren, untersucht. Generell stehen dabei die Architektur und die Funktionsweise der jeweiligen Replikationsumgebung sowie der Replikationsbereich im Fokus. Abgerundet werden die Untersuchungen mit der Betrachtung spezieller Komponenten und Merkmale der Verfahren, wie beispielsweise bei der SQL-Replikation die Zwischenspeichertabellen, bei der Q-Replikation die unterschiedlichen Replikationstypen und bei HADR die verschiedenen Synchronisationsmodi. Im zweiten Schritt erfolgen der Vergleich und die Bewertung der Replikationsverfahren. Auf Grundlage dieser Bewertung und eines denierten Anforderungskatalogs wird ein geeignetes Verfahren für das konkrete Beispiel der Digitalen Bibliothek der Friedrich-SchillerUniversität und des Freistaates Thüringen ausgewählt. Im dritten und letzten Schritt wird der Prozess der Konguration des ausgewählten Verfahrens aufgezeigt und es werden Möglichkeiten zur Verwaltung und Pege skizziert, Verhaltensbeispiele in Ausfallszenarien genannt und über die Erprobung des Verfahrens auf einem Testsystem berichtet. Inhaltsverzeichnis 1 Einleitung 1 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Ziele der Studienarbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.3 Aufbau der Studienarbeit 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Ausgangs- und Zielzustand 3 3 Hochverfügbarkeit 6 4 Theoretische Grundlagen der Replikation 8 4.1 Hardware- und softwarebasierte Replikation 4.2 Klassikation der Replikationsverfahren 5 Replikationsverfahren unter IBM 5.1 5.2 5.3 5.4 SQL-Replikation . . . . . . . . . . . . . . . . . . 8 . . . . . . . . . . . . . . . . . . . . 8 11 DB2 LUW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1.1 Architektur einer SQL-Replikationsumgebung . . . . . . . . . . . . . 11 5.1.2 Funktionsweise 12 5.1.3 Subskriptionsgruppen . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1.4 Zieleinheitstypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1.5 Replikationsarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1.6 Zwischenspeichertabellen . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1.7 Replikationsbereich . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Q-Replikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.2.1 Architektur einer Q-Replikationsumgebung . . . . . . . . . . . . . . 21 5.2.2 Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.2.3 Replikationstypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.2.4 Replikationsbereich . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . High Availability Disaster Recovery (HADR) . . . . . . . . . . . . . . . . . 27 5.3.1 Architektur und Funktionsweise . . . . . . . . . . . . . . . . . . . . . 27 5.3.2 Synchronisationsmodi . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.3.3 Automatic Client Reroute (ACR) . . . . . . . . . . . . . . . . . . . . 32 5.3.4 Replikationsbereich . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Vergleich und Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.4.1 Architektur einer Replikationsumgebung . . . . . . . . . . . . . . . . 36 5.4.2 Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.4.3 Replikationsbereich . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.4.4 Verwaltung und Pege . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.4.5 Performance-Untersuchungen von Ascho 40 i . . . . . . . . . . . . . . . 6 Praktische Umsetzung einer Hochverfügbarkeitslösung mittels eines Replikationsverfahrens 42 6.1 Anforderungsanalyse und Auswahl eines Verfahrens . . . . . . . . . . . . . . 42 6.2 Konguration des HADR-Systems . . . . . . . . . . . . . . . . . . . . . . . 45 6.3 Monitoring, Verwaltung und Pege . . . . . . . . . . . . . . . . . . . . . . . 51 6.4 Verhalten in Ausfallszenarien . . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.4.1 Ausfall des Primärsystems . . . . . . . . . . . . . . . . . . . . . . . . 53 6.4.2 Ausfall des Sekundärsystems . . . . . . . . . . . . . . . . . . . . . . 54 6.4.3 Wartungsmaÿnahmen . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.5 Erprobung auf einem Testsystem . . . . . . . . . . . . . . . . . . . . . . . . 55 7 Zusammenfassung und Ausblick 57 Glossar 59 Literatur 67 Abbildungsverzeichnis 69 Tabellenverzeichnis 71 Quellcodeverzeichnis 73 ii 1 Einleitung 1.1 Motivation Der Einsatz von Datenbankmanagementsystemen (DBMS) im Bereich informationsverarbeitender Anwendungen ist in der Gegenwart nicht mehr wegzudenken. Im Zuge der durch Infrastrukturinvestitionen und technische Fortschritte bedingten wachsenden Nutzeranzahl und Zugangsgeschwindigkeit zu derartigen Anwendungen steigt die Menge an Daten, die durch das DBMS gespeichert und verwaltet werden muss. Auch die Komplexitätserhöhung der zugrunde liegenden Funktionalität darf hierbei nicht auÿer Acht gelassen werden. Die daraus resultierende steigende Lastanforderung an die Server erfordert zudem Maÿnahmen, die sicherstellen, dass die Anwendungen dauerhaft zur Verfügung stehen. In der Gesamtbetrachtung erschlieÿen sich zwei wesentliche Fragen: 1. Wie kann gewährleistet werden, dass Änderungen am Datenbankinhalt jederzeit ausfallsicher gespeichert werden? 2. Durch welche Maÿnahmen kann sichergestellt werden, dass bei einem Ausfall eines Systems die Anwendungen dennoch mit aktuellem Datenbestand erreichbar sind? Zur Beantwortung der beiden Fragen gibt es verschiedene Möglichkeiten und Herangehensweisen. Die mehrfache Speicherung der Daten auf geographisch verteilten Speichersystemen ist dabei ein Bestandteil einer Hochverfügbarkeitslösung. Diese Vorgehensweise wird im Allgemeinen auch als Replikation bezeichnet und in dieser Studienarbeit eingehend behandelt. 1.2 Ziele der Studienarbeit Ein Ziel dieser Studienarbeit liegt in der Untersuchung verschiedener Replikationsverfahren unter dem DBMS IBM DB2 LUW in der Version 9. Hierbei werden unter anderem die Architekturen der Verfahren erklärt und Auskünfte über deren Funktionsweise gegeben. Darauf aufbauend ist ein weiteres Ziel der Studienarbeit die praktische Anwendung eines Replikationsverfahrens am konkreten Beispiel der Digitalen Bibliothek der FriedrichSchiller-Universität Jena und des Freistaates Thüringen. 1.3 Aufbau der Studienarbeit Die vorliegende Studienarbeit umfasst neben dieser Einleitung sechs weitere Kapitel. Das zweite Kapitel liefert eine Übersicht über den Ausgangs- und Zielzustand. In diesem wird unter anderem auch die zugrunde liegende Webanwendung umrissen und die damit verbundene Notwendigkeit einer praktischen Umsetzung eines Replikationsverfahrens aufgezeigt. Das dritte Kapitel beschreibt die Stellung der Replikation im Gesamtkontext des Hoch- verfügbarkeitsbegries im Bereich von Datenbankmanagementsystemen. Es soll damit deutlich gemacht werden, dass die Replikation einen Teil des Gesamtpaketes zur Erreichung einer hohen Verfügbarkeit von Anwendungen darstellt. 1 Das vierte Kapitel beschäftigt sich mit einigen theoretischen Vorbetrachtungen der Re- plikation, insbesondere mit der Frage der Datenussrichtung sowie der Problemstellung, zu welchem Zeitpunkt die geänderten Daten repliziert werden. Das fünfte Kapitel widmet sich drei verschiedenen Replikationsverfahren unter dem IBM DB2 LUW Version 9. So werden hier die Verfahren der SQL-Replikation, Q-Replikation sowie der High Availability Disaster Recovery (HADR ), wobei unter andeDBMS rem Bezug auf die Architektur und Funktionsweise genommen wird, eingehend erklärt. Im sechsten Kapitel liegt die Konzentration auf der Beschreibung der praktischen Um- setzung einer Hochverfügbarkeitslösung mittels eines Replikationsverfahrens. Hier werden anfangs eine Anforderungsanalyse und die daraus resultierende Auswahl eines Verfahrens begründet. Es folgen die Beschreibung der Konguration und erläuternde Worte zur Frage der Verwaltung und Pege des gewählten Replikationsverfahrens. Im Anschluss daran werden verschiedene Ausfallszenarien betrachtet. Das Kapitel schlieÿt mit einer Beschreibung der Erprobung des Verfahrens auf einem Testsystem. Das siebte Kapitel fasst die vorliegende Studienarbeit zusammen und gibt einen Ausblick über weitergehende Möglichkeiten zur Umsetzung einer Hochverfügbarkeitslösung. 2 2 Ausgangs- und Zielzustand Die Thüringer Universitäts- und Landesbibliothek (ThULB) betreibt in Zusammenarbeit mit dem Rechenzentrum der Friedrich-Schiller-Universität Jena seit 1999 eine Digitale Bibliothek namens Die Aufgabe von UrMEL (University Multimedia Electronic Library). UrMEL besteht in der Bündelung der vielfältigen Aktivitäten an der Friedrich-Schiller-Universität Jena zur Bereitstellung multimedialer und historischer Do- UrMEL derzeit die drei Projektkonzeptionen [UrM09] University@UrMEL, Journals@UrMEL und Collections@UrMEL, die auf dem Open-Source-System MyCoRe (siehe dazu auch Abschnitt kumente in gemeinsamen Projekten [UrM09]. Zu diesem Zwecke umfasst 6.5) basieren. Unter University@UrMEL ndet man eine Ansammlung von Hochschuldokumenten wie Dissertationen, Examensarbeiten, Forschungsberichte und Vorlesungsskripte. Es dient zudem als Plattform für die Einrichtung elektronischer Semesterapparate [UrM09]. Auÿerdem werden Audio- wie auch Videoaufnahmen unter anderem von Vorlesungseinheiten zum kostenfreien Abruf zur Verfügung gestellt. Eine Ansammlung digitaler Zeitschriften ist unter Journals@UrMEL einsehbar. Hierun- ter zählen digitalisierte historische Zeitschriften, die auf diesem Wege leichter zugänglich gemacht und darüber hinaus vor dem Verfall geschützt werden, sowie erworbene digitale Zeitschriften von Verlagen und durch die ThULB eigens herausgegebene Zeitschriften. In der dritten Projektkonzeption Collections@UrMEL ndet man eine Reihe von Spezi- alapplikationen zur digitalen und multimedialen Aufbereitung und wissenschaftlichen Erschlieÿung wertvoller Bestände aus Archiven und Handschriftensammlungen [UrM09]. Durch die unterschiedlichen medialen Bestandteile in den drei Projektbereichen von UrMEL werden eine Vielzahl von Dateiformaten verwendet und ein groÿer Datenbestand verwaltet, der zurzeit eine Gröÿe von mehreren Terabytes umfasst. Das zugrunde liegende Open-Source-System MyCoRe benötigt zur Speicherung und Ver- waltung der Informationen ein relationales DBMS. Durch die Verwendung von Hibernate [Hat09], einem objektrelationalen Mapping-Werkzeug, ist es dem Anwender überlassen, welches DBMS eingesetzt wird. Im konkreten Beispiel wird das DBMS Version 9 eingesetzt. Dieses läuft gegenwärtig auf einer Sun XFire 4540 IBM DB2 LUW mit dem Betriebs- system Linux Red Hat Wie in Abbildung 1 zu erkennen ist, erfolgte die Datensicherung bislang durch Online- in der Version 5.1. Backups und eine zusätzliche nächtliche Sicherung mittels der DB2-eigenen Programme db2move und db2look [IBM09]. Diese zusätzliche Sicherung dient dem Szenario eines To- talausfalls, bei dem eine bereits vorbereitete Maschine, das Sekundärsystem, mit den gesicherten Daten als Produktiv- beziehungsweise Primärsystem einspringen kann. Falls eine Recovery nach einem Systemfehler oder gar einem Totalausfall notwendig ist, kann derzeit nicht ausgeschlossen werden, dass in das System neu eingefügte Informationen oder Änderungen an bereits bestehenden Daten verloren gehen. Darüber hinaus besteht die Gefahr der Inkonsistenz zwischen den in der Datenbank abgelegten Informationen auf der einen Seite und den tatsächlichen Daten im Dateisystem auf der anderen Seite. Hiermit ist beispielsweise gemeint, dass Daten in Form von Bildern auf dem Dateisystem zwar vorhanden sind, die Zuordnungen, die in der Datenbank abgelegt wurden, aber verloren gegangen sind. 3 Abbildung 1: Ausgangszustand mit manuellem Einspielen der Datensicherung Der durch diese Studienarbeit zu erreichende Zielzustand ist eine Hochverfügbarkeitslösung im Sinne eines Replikationsverfahrens, um die eben beschriebenen Probleme zu vermeiden und eine Systemumgebung zu schaen, die im Falle eines Ausfalls des Primärsystems zu keiner Unterbrechung der Anwendungen führt und damit neben der Sicherheit der Daten auch gewährleistet, dass die Projekte von Die UrMEL jederzeit verfügbar sind. Abbildung 2 stellt eine Illustration des Zielzustandes dar. Daraus kann entnommen werden, dass im Vergleich zum Ausgangszustand das manuelle Einspielen der Daten auf dem Sekundärsystem entfällt. Durch ein zu wählendes Replikationsverfahren wird dieses nahezu konsistent zum Primärsystem gehalten. Bei einem Totalausfall des Primärsystems springt fortan das Sekundärsystem ein mit aktuellem Datenbestand. Die Rollenverteilung wechselt dadurch: Das ehemalige Sekundärsystem wird zum Primärsystem und bearbeitet nun alle Anfragen des Anwendungsservers. Sobald das eigentliche Primärsystem wieder verfügbar ist, erfolgt eine Synchronisation mit dem aktuellen Primärsystem und die Rollenverteilung entspricht wieder dem ursprünglichen Zustand. Weitergehende Informationen zur Auswahl des Verfahrens und zur Konguration sind im sechsten Kapitel zu nden. Es ist zudem anzumerken, dass der Ausfall des Anwendungsservers nicht Bestandteil der weiteren Ausführungen ist. Es wird also im Betrachtungsbereich der Studienarbeit davon ausgegangen, dass der Anwendungsserver fehlerfrei und ausfallsicher läuft und es hier nicht zu einem Engpass kommen kann. In der Realität muss dieser Fall natürlich mit betrachtet 4 Abbildung 2: Zielzustand mit Replikation werden, da der Anwendungsserver in der jetzigen Form eine Art Flaschenhals darstellt. Denn sobald dieser nicht betriebsbereit ist, ist das ganze System nicht mehr verfügbar. 5 3 Hochverfügbarkeit Der Begri der Hochverfügbarkeit umfasst eine Vielzahl von Kennzahlen und Faktoren, die den dauerhaften Betrieb und die dauerhafte Erreichbarkeit von Anwendungen und Daten gewährleisten. Aus diesem Grund stellt das folgende Kapitel nur einen Einblick in die Thematik dar und erfüllt daher keinen Anspruch auf Vollständigkeit. Allgemein gesehen bezeichnet der Begri der Hochverfügbarkeit die Fähigkeit eines Systems, einen uneingeschränkten Betrieb auch und gerade bei Ausfällen desselben oder einer seiner Komponenten zu gewährleisten, ohne dass es einen unmittelbaren menschlichen Eingri erfordert. Unter der Verfügbarkeit eines Dienstes, im konkreten Beispiel also die Verfügbarkeit des DBMS, versteht man die Wahrscheinlichkeit, dass das DBMS innerhalb eines spezischen Zeitraums funktionstüchtig ist [WG03]. Formal gesehen lässt sich diese Verfügbarkeit wie folgt berechnen: Verfügbarkeit[%] = 1− Ausfallzeit Produktionszeit + Ausfallzeit ∗ 100 Verfügbarkeit ist demnach der Grad, zu dem die vollständige Funktionalität gemäÿ der Spezikation einer Anwendung für den Nutzer vorhanden ist. Verfügbarkeit wird auch als Maÿ zur Bewertung der Zuverlässigkeit einer Anwendung verstanden [Küs85]. Sie ist ein wichtiger Messwert im Bereich hochverfügbarer Systeme. Ein auf Hochverfügbarkeit ausgerichtetes System kann durch die folgenden Eigenschaften nach [Hel04] charakterisiert werden: • Toleranz und Transparenz gegenüber Fehlern, • vorsorgende Build-in-Funktionalitäten, • proaktives Monitoring und schnelle Fehlererkennung, • schnelle Wiederherstellungsmöglichkeiten, • automatisierte Wiederherstellung ohne administrative Eingrie sowie • kein oder geringer Datenverlust. Harvard Research Group (HRG), ein im Marktforschungs- und Beratungssegment tätiAvailability Environment Classication (AEC 0 bis 5) in sechs Verfügbarkeitsklassen ein, die in der folgenden Tabelle Die ges Unternehmen, unterteilt die Hochverfügbarkeit in ihrer 1 überblicksartig dargestellt sind. Die Kategorisierung richtet sich dabei nach der Anzahl der Neunen im Grad der Verfügbarkeit. Im Falle von AEC-5 besteht demnach eine Verfügbarkeit von 99,999%, bei AEC-0 liegt sie unter 90%. Inwieweit eine Anwendung verfügbar ist, richtet sich vor allem danach, in welchem Umfang ungeplante Ausfälle verhindert werden können. Diese Ausfälle werden dabei nach [Hel04] in die folgenden Ursachenklassen kategorisiert: • Katastrophen (z.B. Sturm, Hochwasser oder Brand), 6 HRG-Klasse Bezeichnung Erklärung AEC-0 Conventional Funktion kann unterbrochen werden, Datenintegri- AEC-1 Highly Reliable AEC-2 High Availability tät ist nicht essenziell. Funktion kann unterbrochen werden, Datenintegrität muss jedoch gewährleistet sein. Funktion darf innerhalb festgelegter Zeiten oder zur Hauptbetriebszeit nur minimal unterbrochen werden. AEC-3 Fault Resilient Funktion muss innerhalb festgelegter Zeiten oder während der Hauptbetriebszeit ununterbrochen aufrechterhalten werden. AEC-4 Fault Tolerant Funktion muss ununterbrochen aufrechterhalten werden, der 24*7-Betrieb (24 Stunden, 7 Tage die Woche) muss gewährleistet sein. AEC-5 Disaster Tolerant Funktion muss unter allen Umständen verfügbar sein. Tabelle 1: Verfügbarkeitsklassen der Harvard Research Group • Systemfehler (z.B. unerwartetes Systemversagen), • Fehler durch den Menschen (z.B. fehlerhafte Bedienung und Konguration, versehentliches Entfernen von Systemdaten oder Datenmanipulierung), • logische Fehler der Applikation (z.B. Funktionsfehler) und • Datenkorruptionen. Aber auch geplante Ausfallzeiten können den Grad der Verfügbarkeit reduzieren. Analog zu den ungeplanten Ausfällen können sie nach [Hel04] kategorisiert werden in: • Systempege (z.B. Reorganisation oder Datensicherung), • Wartung der Hardware und • das Einspielen von Upgrades und Patches. Das Ziel der bestmöglichen Minimierung genannter Ausfallzeiten und damit der Erreichung eines möglichst hohen Grades der Verfügbarkeit ergibt sich vor allem aus der Notwendigkeit für hochverfügbare Anwendungen, die aus geschäftlichen Anforderungen auf der einen Seite und gesetzlichen Anforderungen (Langzeitarchivierung, elektronische Verwertbarkeit, Datensicherheit oder Kompatibilität der Daten) auf der anderen Seite resultieren. 7 4 Theoretische Grundlagen der Replikation Im Kontext der Datenverarbeitung bezeichnet die Replikation das Speichern ein und dersel- ben Information auf mehreren unterschiedlichen (möglicherweise auch geographisch verteilten) Speichermedien. Sie gehört zu den Verfahren der Datensicherung und hat im Bereich der Hochverfügbarkeit von DBMS-Produkten eine enorme Bedeutung. Replikationsverfahren werden unter anderem dazu eingesetzt, die Verfügbarkeit der Daten zu erhöhen, die Performance zu steigern und die Last auf die jeweiligen Datenserver zu minimieren. Auch im Segment der verteilten Datenbanken werden Replikationsverfahren angewendet, um sicherzustellen, dass Daten, die in das Primärsystem eingefügt werden oder Änderungsoperationen an diesen zeitnah auf den verschiedenen Datenbanken vorliegen. Damit kann gewährleistet werden, dass auf den verteilten Datenbanken ein identischer Datenbestand vorliegt und somit die Konsistenzbedingungen erfüllt werden. Replikationsverfahren nden zudem Anwendung in Data-Warehouse-Systemen sowie in der Zusammenarbeit zwischen mobilen und stationären Datenbanken [Gol05]. 4.1 Hardware- und softwarebasierte Replikation Grundlegend unterscheidet man zwischen hardwarebasierten und softwarebasierten Replikationsverfahren. Erstgenannte werden über Controller oder Appliances realisiert. Unter einer Appliance versteht man hierbei eine für eine spezische Funktionalität kongurierte Hardwarekomponente. Die zu speichernden Informationen werden so auf direktem Wege auf die verschiedenen Speichermedien übertragen, sodass die beteiligten Speichermedien untereinander einen konsistenten Datenbestand vorweisen können. Sie bieten im Allgemeinen den Vorteil der höheren Performance und reduzieren die Granularität sowie die Entscheidungsbreite, was genau wann repliziert werden muss. Eine bekannte technische Umsetzung ist das Hardware- RAID (Redundant Array of Independent Disks). Softwarebasierte Replikationsverfahren werden demgegenüber durch eigenständige Prozesse oder Teilprozesse des DBMS auf dem Server betrieben. Das bedeutet, dass die Organisation der Datenverteilung durch eine Funktion innerhalb des DBMS, durch das Betriebssystem selbst oder durch externe Programme realisiert wird. Sie sind im Vergleich zu hardwarebasierten Verfahren kostengünstiger, müssen dafür aber im Bereich der Performance Einbuÿen hinnehmen und verursachen ein höheres Datentransferaufkommen. Als bekannte Verfahren seien hier die IBM genannt. Auf diese wird im SQL-Replikation, Q-Replikation und fünften Kapitel näher eingegangen. HADR der Firma Die Wahl eines Verfahrens aus einem der beiden Bereiche steht dabei sehr in Abhängigkeit zu dem spezischen Szenario, da eine Universallösung für die verschiedensten Probleme fehlt. Es ist daher erforderlich, für jedes Szenario anhand einer Anforderungsanalyse das bestmögliche Replikationsverfahren auszuwählen und zu implementieren. Dies führt zu einem Mehraufwand bei der Planung, Implementierung und Pege des Systems. 4.2 Klassikation der Replikationsverfahren Replikationsverfahren lassen sich in Abhängigkeit zweier Parameter klassizieren, welche wiederum die unterschiedlichen Kriterien der Konsistenz beschreiben. Diese Parameter lassen sich nach [GHOS96] wie folgt erfragen: 8 1. Wann werden Änderungsoperationen ausgeführt? 2. In welchem Replikat werden die Änderungsoperationen ausgeführt? Unter einem Replikat versteht man in diesem Falle den Datenbestand einer physischen Speichereinheit innerhalb der Replikationsumgebung, der in der Regel konsistent zu den Datenbeständen aller anderen Replikationsteilnehmer ist. Bezogen auf die erste Frage, wann Änderungsoperationen ausgeführt werden, unterscheidet man ein synchrones von einem asynchronen Verfahren. Beim synchronen Verfahren, welches auch eager genannt wird, gilt eine Änderungsope- ration erst dann als abgeschlossen, wenn sie auf jedem Replikat erfolgreich durchgeführt worden ist. Die Ausführung der Änderungsoperationen erfolgt nahezu zeitgleich auf den verschiedenen Replikaten. Schlägt auf einem Replikat die Änderungsoperation fehl, so gilt die gesamte Änderungsoperation als fehlerhaft. Es werden also entweder alle Replikate aktualisiert oder keines. Aus diesem Grund bezeichnet man dieses Verfahren auch als pessimistische Replikation. Dieser Umstand kann nach [GHOS96] zu gröÿeren Problemen führen. Verwendet man beispielsweise ein System mit n-vielen Replikaten und einer Vielzahl an Änderungsoperationen pro Sekunde, so wird ein nichtlineares Wachstum an durchzuführenden Replikataktualisierungen erreicht. Dies macht deutlich, für welche Gröÿenordnungen sich synchrone Verfahren nicht anbieten. Als Nachteil dieses Verfahrens ist weiterhin der entstehende Kommunikationsoverhead anzusehen, der zwischen den einzelnen Replikationsteilnehmern entsteht und zur Vergröÿerung der Antwortzeit beiträgt. Ein Vorteil des synchronen Verfahrens besteht hingegen in der Erkennung von Konikten vor dem abschlieÿenden Commit. Dadurch ist die direkte Sicherstellung der ACID-Eigenschaften möglich. Im Unterschied dazu steht das asynchrone Verfahren, welches auch als tische Replikation lazy oder optimis- bezeichnet wird. Hier erfolgt die Aktualisierung der Replikate erst nach dem Commit der Änderungsoperation auf einem der Replikate. Das bedeutet zum einen, dass die Antwortzeit geringer ist als bei dem synchronen Verfahren, zum anderen aber auch, dass die Replikate für einen gewissen minimalen Zeitraum inkonsistent zueinander sind. Es gibt hierbei wiederum zwei verschiedene Möglichkeiten, auf welchem Replikat die Primary-Copy -Ansatz und Update-Everywhere -Ansatz [Mun09]. Der Primary-Copy -Ansatz beschreibt eine Replikationsumgebung, bei der ein Replikations- Änderungsoperation durchgeführt werden kann, nämlich der der teilnehmer als Master-System fungiert. Alle anderen Teilnehmer fungieren als sogenannte Slave-Systeme. Ein Master-System ist dadurch charakterisiert, dass es die höchste Priorität in der Umgebung besitzt. Das bedeutet beispielsweise, dass die Änderungsoperationen immer zuerst auf dem Master-System ausgeführt werden. Ist die Änderungsoperation erfolgreich, werden die Änderungsoperationen auf die Slave-Systeme repliziert. Diese Architektur birgt die Gefahr eines sogenannten Single-Point-of-Failure (SPoF), da bei einem Ausfall des Master-Systems als alleiniger Zugrispunkt für Änderungsoperationen diese in dieser Umgebung nicht mehr ausgeführt werden können. Unter einem Single-Point-of-Failure versteht man also eine einzelne Fehlerstelle, die für den Gesamtausfall des Komplettsystems verantwortlich ist. Aus diesem Grund muss darauf geachtet werden, dass im Falle eines Ausfalls des Master-Systems ein beliebiges Slave-System die Funktionalität des MasterSystems übernimmt und damit für einen Fortlauf des Gesamtsystems sorgt. Im Gegensatz dazu steht der Update-Everywhere -Ansatz. In dieser Architektur haben im Prinzip alle Teilnehmer die Stellung eines Master-Systems. Änderungstransaktionen kön- 9 nen somit auf allen Replikationsteilnehmern ausgeführt werden. Dies bedingt im Umkehrschluss allerdings, dass ein komplexer Synchronisationsaufwand entstehen kann, um die Replikate auf einen konsistenten Datenbestand zu bringen. Bereits in den Ausführungen zum ersten Parameter wurde auch der zweite Parameter behandelt, also die Frage, in welchem Replikat die Änderungstransaktionen ausgeführt werden. Dieser unterscheidet zwischen einem unidirektionalen und bidirektionalen Datenuss bei den Replikationsverfahren [Zen07]. Bei einem unidirektionalen Datenuss werden Informationen von einem Primärsystem auf ein oder mehrere Sekundärsysteme übertragen. Der Datenuss geht hier also immer nur in eine Richtung und wird für die Verbreitung oder Zusammenführung von Informationen in der Replikationsumgebung verwendet (siehe dazu Abbildung 3). Abbildung 3: Anwendungsbeispiele des unidirektionalen Datenuss Im Vergleich dazu versteht man unter einem bidirektionalen Datenuss eine Übertragung von Informationen zwischen mehreren Systemen in beiden Richtungen. Diese Art wird insbesondere bei dem Update-Everywhere -Ansatz verwendet. Der bidirektionale Daten- uss kann bei der Synchronisation der verschiedenen Replikationsteilnehmer allerdings zu Konikten führen, wenn verschiedene Änderungsoperationen auf gleichen Informationen zu identischen Zeiten auf den verschiedenen Replikaten ausgeführt werden. Diesen Konikten kann man mit unterschiedlichen Auösungsmechanismen, wie beispielsweise den Timestamp-basierten Verfahren entgegenwirken. Bei dem Timestamp-basierten Verfahren wird entweder dem zeitlich jüngeren oder dem zeitlich älteren Replikat Priorität bei der Koniktauösung gegeben. Man spricht hier auch von mestamp. Latest Timestamp und Earliest Ti- Eine Erweiterung des bidirektionalen Datenusses stellt die Datenussrichtung peer peer-to- dar. Hierbei handelt es sich um einen Datenuss zwischen mehr als zwei Systemen, der dadurch gekennzeichnet ist, dass zwischen jedem beteiligten System eine bidirektionale Datenussrichtung existiert. Es kommuniziert demnach jedes System mit allen anderen beteiligten Systemen. 10 5 Replikationsverfahren unter Das DBMS IBM DB2 LUW IBM DB2 LUW Version 9 unterstützt eine Vielzahl software- und hardwa- rebasierter Replikationsverfahren für die verschiedenen Systemumgebungen. Zu den soft- SQL-Replikation und High Availability Disaster Recovery -Verfahren. Auf diese wird warebasierten Verfahren zählen im Besonderen die Verfahren der Q-Replikation sowie das im Folgenden detailliert eingegangen. Hardwarebasierte Replikationsverfahren unter dem DBMS IBM DB2 LUW Version 9 nden in dieser Studienarbeit keine weitere Beachtung. 5.1 SQL-Replikation Das als SQL-Replikation bezeichnete Datenverteilungsverfahren ist das älteste der drei in dieser Arbeit betrachteten Verfahren unter dem DBMS Unterschied zum HADR-Verfahren, welches im IBM DB2 LUW [IBM99]. Im Abschnitt 5.3 vorgestellt wird, arbeitet die SQL-Replikation auf einer feingranularen Ebene des DBMS. Das bedeutet folglich: Je feingranularer die Ebene, desto weniger Objekte werden durch eine Änderungsoperation innerhalb des Datenbanksystems berührt. Beispielsweise bendet sich eine Operation A auf einer feingranulareren Ebene als die Operation B, falls die Operation A Änderungen nur eine Tabelle betreend durchführt, hingegen die Änderung durch Operation B die Gesamtheit der Tabellen betrit. Weiterhin ist eine Erweiterung der Replikationsumgebung möglich, da es bei der SQL-Replikation mehr als ein Sekundärsystem geben darf. 5.1.1 Architektur einer SQL-Replikationsumgebung Das Verfahren der SQL-Replikation hat die zentrale Aufgabe, bestimmte Daten von einem Primär- auf ein oder mehrere Sekundärsysteme zu replizieren. Die hierfür notwendige Abbildung 4 schematisch dargestellt sind. Der Einfachheit halber wird im weiteren Verlauf Architektur setzt sich dabei aus verschiedenen Komponenten zusammen, die in der dieses Kapitels das Szenario angenommen, dass jeweils ein Primär- und ein Sekundärsys- tem in der Replikationsumgebung vorhanden ist. Abbildung 4: Architektur einer SQL-Replikationsumgebung Auf jedem zur Replikationsumgebung gehörenden Primärsystem ist mindestens ein sogenanntes Capture-Programm installiert. Dieses Hilfsprogramm hat die Aufgabe, Änderungen 11 an Daten, die zur Replizierung vorgesehen sind, zu erkennen, zu prüfen und gegebenenfalls Folgeaktionen auszuführen. Capture-Programme sind mit besonderen Rechten ausgestattete Anwendungsprozesse. Für bestimmte Replikationsumgebungen ist es durchaus sinnvoll, statt einem mehrere Capture-Programme auf dem Primärsystem laufen zu lassen. Hierdurch können beispielsweise die Parallelverarbeitungskapazitäten bei der Replikation erhöht werden, was zu einer höheren Durchsatzrate und einer verbesserten Systemleistung führt. Der Nachteil bei der Ausweitung der Parallelverarbeitung liegt in dem erhöhten Bedarf an CPU-Kapazitäten und einer höheren Anzahl an Verbindungen zum DBMS. Ein weiterer Nutzen der Verwendung mehrerer Capture-Programme besteht in der Möglichkeit, den Datenuss der Replizierung für einzelne Quelleinheiten zu kanalisieren. Das bedeutet, dass sensiblen Quelleinheiten, die eine Replizierung mit möglichst geringer Latenz erfordern, jeweils ein eigenes Capture-Programm zur Verfügung gestellt werden kann. Dies gewährleistet die nahezu sofortige Verarbeitung von zu replizierenden Daten durch das Capture-Programm. Andernfalls könnte es durchaus vorkommen, dass die Daten nicht echtzeitnah repliziert werden können, weil das Capture-Programm in diesem Moment bereits einen anderen Replizierungsauftrag ausführt. Analog zum Capture-Programm gibt es auf jedem zur Replikationsumgebung gehörenden Sekundärsystem ein sogenanntes Apply-Programm. Dieses Hilfsprogramm hat die Aufgabe, Zwischenspeichertabelle zu Änderungen an zu replizierenden Daten aus der sogenannten entnehmen und diese auf dem jeweiligen Zielsystem einzuarbeiten. Zur Architektur einer SQL-Replikationsumgebung gehört zudem noch eine zu jedem Capture- und jedem Apply-Programm zugeordnete Gruppe von Steuertabellen sowie die eben bereits erwähnte Zwischenspeichertabelle. Ausgehend vom Capture-Programm über die Zwischenspeichertabelle und dem Apply-Programm bis zum Sekundärsystem erfolgt der Datenuss unidirektional. Die Architektur der SQL-Replikation legt keine direkte Beschränkung auf das DBMS DB2 LUW IBM fest. So ist es möglich, dass eine Replikation zwischen verschiedenen relatio- nalen DBMS-Produkten realisiert werden kann. Es spielt dabei auch keine Rolle, ob das Primärsystem ein DB2-System ist. Es ist theoretisch und praktisch möglich, dass die für das DBMS IBM DB2 LUW entwickelte SQL-Replikation auch zwischen verschiedenen nicht-DB2-Systemen zum Einsatz kommt. Hierfür bedarf es allerdings dem Einsatz eines dritten Produktes, dem sogenannten DB2 Relational Connect. 5.1.2 Funktionsweise Bei der Einrichtung einer SQL-Replikationsumgebung werden im ersten Schritt die Quelleinheiten registriert. Unter Quelleinheiten versteht man hierbei genau die Daten, die auf das Sekundärsystem repliziert werden sollen. Die Verknüpfung auf diese Daten erfolgt durch die Angabe der Tabellen, in denen sich die zu replizierenden Daten benden oder durch die Angabe der entsprechenden Views. Genauer gesagt erfolgt hierbei die Angabe des Namens und der Schemabezeichnung der jeweiligen Tabelle oder des jeweiligen Views. Die Registrierung der Quelleinheiten kann der Einfachheit halber über einen speziellen Replikations-Wizard in der Steuerzentrale erfolgen. Nach der Registrierung der Quelleinheiten werden die Steuertabellen erstellt. Wie bereits erwähnt ist jedem Capture- beziehungsweise Apply-Programm eine Gruppe von Steuertabellen zugeordnet. Während mehrere Apply-Programme eine Gruppe von Steuertabellen nutzen können, muss jedem Capture-Programm eine eigene Gruppe von Steuertabellen zugeordnet werden. Steuertabellen dienen unter anderem als Wissenszentrale der Programme, 12 geben Aufschluss über die Programmleistung und ermöglichen die Überwachung des Replikationsstatus. Sie bestehen aus statischen wie auch dynamischen Inhalten. So werden in den Steuertabellen die registrierten Quell- und Zieleinheiten verzeichnet, auch die aktuelle Position des Capture-Programms beim sequenziellen Auslesen des Protokolls wird festgehalten. Zusätzlich werden durch die Programme eigens generierte Daten in den Steuertabellen gespeichert, die zur Untersuchung der bereits erwähnten Programmleistung notwendig sind. Im weiteren Fortgang der Einrichtung einer SQL-Replikationsumgebung ist die Zuordnung der Zieleinheiten zu den bereits registrierten Quelleinheiten notwendig. Unter Zieleinheiten versteht man analog zu den Quelleinheiten diejenigen Tabellen, in die die zu replizierenden Daten abgelegt werden sollen. Eine derartige Verknüpfung von Quell- und Zieleinheit wird auch als Subskriptionsgruppe bezeichnet. Diese beinhaltet unter anderem die Adressierung der Quell- und Zieleinheit, d.h. die Zuordnung der jeweiligen Einheiten zu dem jeweiligen Primär- und Sekundärsystem. Jeder Subskriptionsgruppe ist eine Zwischenspeichertabelle zugeordnet, darüber hinaus enthält sie eine Vielzahl weiterer Parameter, die den Ablauf und die Verarbeitung der Replikation beeinussen. Auf diese geht der Abschnitt 5.1.3 detailliert ein. Nach der Ausführung der oben genannten Initialisierungsschritte kann die SQL-Replikation ihre eigentliche Arbeit aufnehmen. Sei einmal angenommen, dass auf dem Primärsystem das DBMS IBM DB2 LUW in Betrieb ist. In diesem Fall wird ein Capture-Programm gestartet. Nach dem erfolgreichen Start wird eine Verbindung zwischen dem CaptureProgramm und dem entsprechenden Apply-Programm auf dem Sekundärsystem hergestellt. Durch einen darauf folgenden Informationsaustausch wird festgestellt, ob sich die Systeme in einem synchronen Zustand benden. Dieser initialen Kommunikation folgt die Erfassung der geänderten Daten in den Quelleinheiten. Hierzu liest das Capture-Programm das DB2-Protokoll sequenziell aus und sucht nach Änderungen an den registrierten Quelleinheiten. Sobald eine Transaktion die Quelleinheit betreend gefunden wird, erfolgt die after image -Wertes aus der Protokolldatei des after images verbirgt sich dabei das durch an die Transaktion gekoppelte Ablegung des in den Hauptspeicher. Hinter dem Begri die Transaktion modizierte Tupel, sozusagen der neue Zustand des Tupels. Analog dazu gibt es die before images, die das Tupel vor der Transaktionsausführung, d.h. vor der eigentlichen Modizierung, beinhalten. Standardmäÿig erfasst und benötigt das CaptureProgramm nur die after image -Werte. Es ist aber bei der Registrierung der Quelleinheiten before image -Werte einzustellen. möglich, die zusätzliche Speicherung der Sobald der Commit-Log-Record (CLR) gefunden wird, entnimmt das Capture-Programm after image -Werte aus dem Hauptspeicher und legt diese die zur Transaktion gehörenden mit zusätzlichen Informationen in der Zwischenspeichertabelle ab. Der genaue Aufbau einer Zwischenspeichertabelle wird in Abschnitt 5.1.6 betrachtet. Wird die Transaktion dage- gen nicht erfolgreich abgeschlossen, sondern zurückgesetzt, nimmt das Capture-Programm die Löschung der entsprechenden image -Werte aus dem Speicher vor. Einen Überblick über die Datenerfassung bei der SQL-Replikation gibt die Falls auf dem Primärsystem ein anderes DBMS als Abbildung 5. IBM DB2 LUW eingesetzt wird, gestal- tet sich die Erfassung der geänderten Daten auf den Quelleinheiten bei der SQL-Replikation etwas anders. Für dieses Szenario sei das Capture-Programm einmal auÿen vor gelassen. Grob betrachtet werden bei der Registrierung einer Quelleinheit auf einem derartigen Primärsystem stattdessen vier Trigger erstellt. Diese Trigger werden jeweils gefeuert, sobald eine INSERT-, UPDATE- oder DELETE-Operation ausgeführt wird. Es handelt sich also um einen INSERT-Trigger, UPDATE-Trigger und DELETE-Trigger. Der vierte Trigger 13 Abbildung 5: Prozess der Erfassung einer Transaktion auf einer registrierten Quelleinheit bei der SQL-Replikation. (1) Die Transaktion wird ausgeführt. (2) Die Transaktion wird im Protokoll verzeichnet. (3) Das Capture-Programm erkennt die Transaktion auf der registrierten Quelleinheit. (4) Die after-image -Werte werden durch das Capture-Programm in den Hauptspeicher gelegt. (5) Die Transaktion wurde laut Log-Eintrag erfolgreich abgeschlossen; das CaptureProgramm entnimmt die Werte aus dem Hauptspeicher. (6) Die Transaktion wurde nicht erfolgreich abgeschlossen die Werte werden gelöscht. (7) Die Transaktion wurde erfolgreich abgeschlossen die Werte werden in die Zwischenspeichertabelle eingetragen. dient der Bereinigung der Zwischenspeichertabelle, sobald die durch die drei erstgenannten Trigger eingetragenen Änderungen auf dem Sekundärsystem eingearbeitet wurden. Nachdem die Werte in die Zwischenspeichertabelle eingetragen wurden, können diese nun durch das Apply-Programm auf dem Sekundärsystem verarbeitet werden. Dazu muss das Apply-Programm logischerweise gestartet sein. Es verarbeitet genau die Eintragungen in der Zwischenspeichertabelle, die ihm durch die Subskriptionsgruppen zugeordnet wurden. Sobald das Apply-Programm mit der Verarbeitung der Einträge in der Zwischenspeichertabelle fertig ist, geht es in einen inaktiven Zustand, der auch als sleep-Modus bezeichnet wird, über. Das bedeutet, dass das Apply-Programm nur dann aktiv ist und damit CPU-Leistung verbraucht, wenn noch nicht verarbeitete Einträge in der Zwischenspeichertabelle vorhanden sind. Die Zuordnung des Apply-Programms zu einer bestimmten Subskriptionsgruppe erfolgt über das sogenannte Apply-Qualikationsmerkmal. Dieses Apply-Qualikationsmerkmal ist eine eindeutige Bezeichnung des Programms, beispielswei- se durch eine Namensgebung, durch welche das Programm identiziert werden kann. Dies ist vor allem dann notwendig, wenn mehrere Apply-Programme ein und dieselbe Gruppe von Steuertabellen verwenden. Die Verarbeitung der Einträge durch das Apply-Programm erfolgt sequenziell. Es gibt zudem zwei Möglichkeiten, wie die zu replizierenden Daten auf dem Sekundärsystem verarbeitet werden. Diese werden im Abschnitt 5.1.5 erklärt. Mit der Verarbeitung der geänderten Daten auf dem Sekundärsystem ist ein sogenannter plikationsdurchlauf abgeschlossen. Die Re- Abbildung 6 gibt einen schematischen Überblick über den Vorgang der Datenreplizierung bei der SQL-Replikation. Wann und wie oft ein Replikationsdurchlauf erfolgt, ist auch vom eingestellten Durchführungsintervall abhängig. Die verschiedenen Wertbelegungen für das Durchführungsintervall werden im folgenden Abschnitt 5.1.3, der sich den Subskriptionsgruppen widmet, dargelegt. 14 Abbildung 6: Prozess der Verarbeitung einer Transaktion auf einer registrierten Zieleinheit bei der SQL-Replikation. (1) Das Apply-Programm liest den entsprechenden Eintrag aus der Zwischenspei- chertabelle. (2) Das Apply-Programm kopiert die entnommenen Werte in die Zieleinheit. 5.1.3 Subskriptionsgruppen Subskriptionsgruppen sind ein elementarer Bestandteil der SQL-Replikation. Ohne sie wäre ein derartiges Verfahren quasi hilos, da es nicht darüber informiert wäre, welche Daten wohin zu replizieren sind. Wie bereits in Abschnitt 5.1.2 angerissen, bestimmt die Subskriptionsgruppe die Zuordnung einer Quelleinheit zur entsprechenden Zieleinheit. Im Grunde kann man die Subskriptionsgruppe auch als Funktion ansehen, die eine Menge von Daten auf eine zweite Menge auf einem anderen System abbildet. Neben der Benennung der Quell- und Zieleinheit bedarf es der Registrierung der Spalten und Zeilen, die zu replizieren sind. Die zu replizierenden Spalten der Quelleinheit müssen zudem auch den entsprechenden Spalten der Zieleinheit zugeordnet werden. Die nun durch die Verknüpfung der Quell- mit der Zieleinheit festgelegten Daten können zu unterschiedlichen Zeitpunkten repliziert werden. Dies wird im Rahmen des rungsintervalls • Intervallsteuerung, • Ereignissteuerung oder • kontinuierliche Replikation. Unter der Durchfüh- deniert, welches drei verschiedenen Typen entsprechen kann: Intervallsteuerung versteht man die Festlegung eines einfachen Intervalls, in wel- chem die Daten zu replizieren sind. Beispielsweise kann angeben werden, dass die durch die Subskriptionsgruppe denierten Daten jede 30 Minuten zu replizieren sind. Das bedeutet, dass alle 30 Minuten ein Replikationsdurchlauf gestartet wird. Das Sekundärsystem liegt im Hinblick auf die Konsistenz des Datenbestandes zeitlich gesehen bei diesem Typ maximal 30 Minuten plus der Zeit für die Durchführung des Replikationsdurchlaufs hinter dem Primärsystem. Die Intervallsteuerung wird beiläug auch als relative Ablaufsteuerung bezeichnet. Demgegenüber wird bei der Ereignissteuerung ein bestimmter Zeitpunkt angegeben, zu dem die Replikation der durch die Subskriptionsgruppe denierten Daten zu erfolgen hat. Dies macht vor allem dann Sinn, wenn ein Datenabgleich zu einem Zeitpunkt erfolgen soll, zu dem das Primärsystem wenig Last zu verarbeiten hat. Unter der Ereignissteuerung versteht man aber auch, dass die Replikation genau dann erfolgen soll, wenn eine bestimmte Operation auf dem Primärsystem erfolgt ist. Dies wird dadurch realisiert, dass 15 der Benutzer oder das Apply-Programm selbstständig einen Eintrag in einer zum ApplyProgramm zugeordneten Steuertabelle vornimmt, der dem bestimmten Ereignis oder der Operation entspricht. Erkennt das Apply-Programm nun beim sequenziellen Verarbeiten der Einträge in der Zwischenspeichertabelle einen Eintrag, der identisch mit dem Eintrag in der Steuertabelle ist, wird ein Replikationsdurchlauf gestartet. Die kontinuierliche Replikation ist eine Methode, bei der ein Replikationsdurchlauf so oft wie möglich, im Prinzip ständig, erfolgt. Dieser Typ ermöglicht also die beste Annäherung an genau den Zustand, in welchem der Datenbestand auf dem Sekundärsystem nahezu identisch zu dem Datenbestand auf dem Primärsystem ist. Neben dem Durchführungsintervall kann auch die Funktion der Datenblockung innerhalb einer Subskriptionsgruppe aktiviert oder deaktiviert werden. Unter der Datenblockung ver- steht man die Möglichkeit, dass die bei einem Replikationsdurchlauf erfassten Änderungen nicht in einem Block, sondern in Gruppen aufgeteilt repliziert werden. Hierfür erfolgt die Angabe eines Zeitraums, der maÿgeblich für die Gruppeneinteilung der Änderungen, d.h. der Gröÿe der Datenblockgruppen, verantwortlich ist. Der Vorteil der Datenblockung liegt unter anderem darin, dass der Bedarf an temporärem Speicherplatz minimiert werden kann, da nur bestimmte Datenblockgruppen repliziert werden und nicht wie bei deaktivierter Datenblockung die Gesamtheit der zu replizierenden Daten. Gleichfalls positive Auswirkungen hat die aktivierte Datenblockung im Falle eines Fehlers bei der Replikation. So müssen bei aktivierter Datenblockung nur die Änderungen, die sich innerhalb der Datenblockgruppe benden, zurückgesetzt werden. Bei deaktivierter Datenblockung werden hingegen alle zum Replikationsdurchlauf zugehörigen Änderungen zurückgesetzt. Angenommen, in einem Zeitraum von 30 Minuten werden auf der Quelleinheit 25 Transaktionen vorgenommen, die alle erfolgreich abgeschlossen werden. Zwischen dem Zeitpunkt t=0 und t=10 erfolgen die ersten 8 Transaktionen, zwischen t=10 und t=20 die nächsten 12 und zwischen t=20 und t=30 die restlichen 5. Bei deaktivierter Datenblockung werden alle 25 Transaktionen innerhalb eines Replikationsdurchlaufs auf dem Sekundärsystem verarbeitet. Ist sie hingegen aktiviert, werden entsprechend des angegebenen Faktors nur genau diejenigen Transaktionen als Block verarbeitet, die sich innerhalb des Zeitraums benden. Im Beispiel bedeutet dies bei dem Faktor 10, dass für die Verarbeitung aller Transaktionen drei Replikationsdurchläufe notwendig wären. Im ersten Durchlauf würden 8, im zweiten 12 und im dritten Durchlauf 5 Transaktionen verarbeitet werden. Bei der Erstellung der Subskriptionsgruppe kann auÿerdem Einuss auf die Manipulation oder Umwandlung der zu replizierenden Daten genommen werden. Hierfür wird festgelegt, dass die zu replizierenden Daten statt in die Zwischenspeichertabelle zuerst an eine gespeicherte Prozedur oder an ein dafür erstelltes SQL-Script übergeben werden. Die Daten werden dann durch die gespeicherte Prozedur oder das SQL-Script manipuliert oder umgewandelt und anschlieÿend an die entsprechende Zwischenspeichertabelle weitergeleitet. Bei der Übergabe der Daten an eine Prozedur muss zudem die Zuordnung zu den Prozedurparametern festgelegt werden. Zu guter Letzt wird auch der Typ der Zieleinheit in der Subskriptionsgruppe festgeschrieben. Die verschiedenen Typen werden im folgenden Abschnitt 5.1.4 erklärt. 5.1.4 Zieleinheitstypen Bei der Erstellung einer Subskriptionsgruppe ist im Zuge der Festlegung der Zieleinheit im Allgemeinen anzugeben, von welchem Typ diese Zieleinheit sein soll. Wird jedoch eine 16 bereits registrierte Zieleinheit ausgewählt, ist die Angabe des Types nicht erforderlich. Im Bereich der SQL-Replikation unterscheidet man grundsätzlich die folgenden fünf Typen: • Benutzerkopie, • Zeitpunktangabe, • Ergebnistabelle, • CCD (Consistent-Change-Data) und • Replikat. Bei dem als Benutzerkopie bezeichneten Zieleinheitstyp handelt es sich um eine auf dem Sekundärsystem schreibgeschützte Tabelle, die im Hinblick auf die Struktur identisch mit der Quelleinheit ist. Es ist zusätzlich möglich, abzuspeichern und berechnete Spalten after image -Werte und before image -Werte zu denieren. Eine notwendige Bedingung ist für Letzteres das Vorhandensein einer Spalte mit Schlüssel- bzw. Unique-Eigenschaft in der Tabelle. Derartige Zieleinheiten werden genau dann verwendet, wenn auf dem Sekundärsystem keine Datenänderungen vorgenommen und die Daten aus der Quelleinheit repliziert werden sollen. Die Tabelle 2 zeigt den Aufbau des Zieleinheitstypes. Spaltenbezeichnung Erklärung Schlüsselspalten Spalten, die eine Schlüssel- bzw. Unique-Eigenschaft aufweisen und deren Einträge repliziert werden sollen. Spalten Sonstige Spalten, deren Einträge repliziert werden sollen und keine Schlüssel- bzw. Unique-Eigenschaft besitzen. Berechnungsspalten Spalten, deren Einträge sich aus SQL-Berechnungsausdrücken ergeben (beispielsweise SUM oder MAX). Tabelle 2: Aufbau des Zieleinheitstypes Benutzerkopie Eine Erweiterung der Benutzerkopie stellt der Zieleinheitstyp Zeitpunktangabe dar. Die Erweiterung besteht hierbei im Vorhandensein einer weiteren Spalte, in der der Zeitpunkt abgespeichert werden kann, zu dem die Datenänderung auf der Quelleinheit erfolgte. Diese Spalte wird auch als Zeitmarkenspalte bezeichnet. Der hierfür notwendige Zeitstempel wird durch das Capture-Programm bei der Registrierung der Änderung in der Zwischenspeichertabelle mit übergeben. Im Gegensatz zu den ersten beiden Zieleinheitstypen steht der dritte Typ, welcher als Ergebnistabelle bezeichnet wird. Hier werden die Daten aus der Quelleinheit nicht zwingend eins zu eins repliziert, sondern alternativ Ergebnismengen, die sich aus der Menge der Daten der Quelleinheit oder aus Berechnungen auf Daten aus der Zwischenspeichertabelle ergeben, auf die Zieleinheit abgebildet. Derartige Ergebnismengen können beispielsweise Summen oder Produkte, Maxima oder Minima darstellen. Grundsätzlich unterscheidet man hierbei zwei Typen der Ergebnistabelle: • Basisergebnistabelle und • CA (Change-Aggregate)-Tabelle. 17 Spaltenbezeichnung Erklärung Spalten Benutzerdenierte Spalten, die die Ergebnisse der Berechnungen aus der Quelleinheit beinhalten. IBMSNAP LLOGMARKER Zeitstempel, der den Beginn der Berechnung der Daten in der Quelleinheit angibt. IBMSNAP HLOGMARKER Zeitstempel, der das Ende der Berechnung der Daten in der Quelleinheit angibt. Tabelle 3: Aufbau des Zieleinheitstypes Basisergebnistabelle Bei der Basisergebnistabelle erfolgt in jedem Replikationsdurchlauf die komplette Berech- nung der Daten auf Grundlage der Quelleinheit, die in der Ergebnistabelle abgespeichert werden. Einen Überblick über den Aufbau einer Basisergebnistabelle gibt die Im Gegensatz dazu werden bei der CA-Tabelle Tabelle 3. nur genau die Werte berechnet, die sich aus den Daten, die in der Zwischenspeichertabelle aufgrund von Änderungen auf der Quelleinheit abgelegt wurden, ergeben. Beispielsweise ist eine CA-Tabelle von Vorteil, wenn berechnet werden soll, wie viele Kundenzugänge eine Dienstleistungsrma innerhalb einer Woche hatte. Es werden in diesem Beispiel einfach die in der Zwischenspeichertabelle abgelegten Änderungsoperationen, die zum Eintrag eines neuen Kunden geführt haben, gezählt und in die CA-Tabelle als Wert eingetragen. Die Tabelle 4 zeigt den Aufbau dieses Zieleinheitstypes. Spaltenbezeichnung Erklärung Schlüsselspalten Spalten, die eine Schlüssel- bzw. Unique-Eigenschaft aufweisen und deren Einträge repliziert werden sollen. Spalten Sonstige Spalten, deren Einträge repliziert werden sollen und keine Schlüssel- bzw. Unique-Eigenschaft besitzen. Berechnungsspalten Spalten, deren Einträge Berechnungsausdrücken ergeben sich aus SQL- (beispielsweise SUM oder MAX). IBMSNAP LLOGMARKER Ältester Zeitstempel, der den Beginn der Berechnung der Daten angibt. IBMSNAP HLOGMARKER Neuester Zeitstempel, der den Beginn der Berechnung der Daten angibt. Tabelle 4: Aufbau des Zieleinheitstypes CA-Tabelle Wie auch die Benutzerkopie und die Zeitpunktangabe ist die Ergebnistabelle schreibgeschützt und eignet sich daher nur für eine einseitige Replizierung vom Primär- auf das Sekundärsystem. Auch in Bezug auf die Zeitmarkenspalte ähnelt dieser Typ der Zeitpunktangabe. Der als CCD bezeichnete Zieleinheitstyp eignet sich besonders zur Überwachung des Re- covery-Protokolls des Primärsystems. So ist es möglich, den Typ der Änderung und die Reihenfolge der Änderungen abzuspeichern, also ob und wann eine Transaktion Daten änderte, entfernte oder neue Daten hinzufügte. Auch dieser Typ ist schreibgeschützt. Die Tabelle 5 zeigt exemplarisch den Aufbau eines derartigen Zieleinheitstypes. Nicht schreibgeschützt ist der fünfte Zieleinheitstyp, welcher auch als Replikat bezeichnet wird. Ein Vorteil dieses Types ist die Verwendbarkeit für eine mehrseitige Replikation. 18 Spaltenbezeichnung Erklärung IBMSNAP INTENTSEQ Folgenummer eines Protokollsatzes zur eindeutigen Kennzeichnung einer Änderungsoperation. IBMSNAP OPERATION Enthält den Typ der Änderungsoperation. I steht hierbei für INSERT, U für UPDATE und D für DELETE. IBMSNAP COMMITSEQ Folgenummer des Commit-Log-Records. IBMSNAP LOGMARKER Zeitpunkt des Commit der Änderungsoperation auf dem Primärsystem. Schlüsselspalten Spalten, die eine Schlüssel- bzw. Unique-Eigenschaft aufweisen und deren Einträge repliziert werden sollen. Spalten Sonstige Spalten, deren Einträge repliziert werden sollen und keine Schlüssel- bzw. Unique-Eigenschaft besitzen. Berechnungsspalten Spalten, deren Einträge Berechnungsausdrücken ergeben sich aus (beispielsweise SQLSUM oder MAX). IBMSNAP AUTHID Optionale Spalte, die die der Änderungsoperation zugeordneten Berechtigungs-ID enthält. Sie gibt die Kennung des Benutzers an, durch den die Änderungsoperation angewiesen wurde. IBMSNAP AUTHTKN Optionale Spalte, die das der Änderungsoperation zugeordnete Berechtigungstoken enthält. Das Berechtigungstoken entspricht dem Namen des Jobs, durch den die Änderungstransaktion hervorgerufen wurde. IBMSNAP REJ CODE Optionale Spalte, die eine Codenummer enthält, die Aufschluss im Falle eines Auftretens eines Koniktes bei der Replikation gibt. Der Code kann die ganzzahligen Werte 0 und 1 annehmen. IBMSNAP UOWID Optionale Spalte, die die Kennung der UoW (Unit-ofWork) enthält. Tabelle 5: Aufbau des Zieleinheitstypes CCD-Tabelle Hiermit ist gemeint, dass Datenänderungen auf allen zur Replikationsumgebung zugehörigen Systemen erfolgen und diese auch repliziert werden können, sofern es sich bei den eigentlichen Zieleinheiten um eben genau diese Typen handelt. Diese Möglichkeit birgt logischerweise auch Koniktpotenzial. Ist dies der Fall, das heiÿt, werden auf zwei unterschiedlichen Systemen gleichzeitig identische Daten geändert, so werden genau diejenigen Daten repliziert, die vom Primärsystem stammen. Das bedeutet, dass im Koniktzustand immer die Daten Priorität haben, die auf dem Primärsystem geändert wurden. Den Aufbau des Zieleinheitstypes zeigt die Tabelle 6. Spaltenbezeichnung Erklärung Schlüsselspalten Spalten, die eine Schlüssel- bzw. Unique-Eigenschaft aufweisen und deren Einträge repliziert werden sollen. Spalten Sonstige Spalten, deren Einträge repliziert werden sollen und keine Schlüssel- bzw. Unique-Eigenschaft besitzen. Tabelle 6: Aufbau des Zieleinheitstypes Replikat 19 5.1.5 Replikationsarten Neben dem Typ der Zieleinheit ist bei der Erstellung der Subskriptionsgruppe auch die Art der Replikation anzugeben. Hierbei gibt es die folgenden zwei Optionen: • Replikation mit Änderungserfassung oder • Replikation mit vollständiger Aktualisierung. Unter der Option Replikation mit Änderungserfassung versteht man die Replizierung nur genau derjenigen Daten, die auch tatsächlich auf der Quelleinheit geändert worden. Dies erfolgt durch das sequenzielle Auslesen der Zwischenspeichertabelle mittels des ApplyProgramms. Wird ein entsprechender Eintrag gefunden, startet das Apply-Programm seine bereits beschriebenen Folgeaktivitäten. Bei der Replikation mit Änderungserfassung unterscheidet man zudem noch zwei Untertypen: die Änderungserfassung bei registrierten Spalten und die Änderungserfassung bei beliebigen Spalten. Der Unterschied zwischen diesen zwei Untertypen liegt darin, dass bei der Änderungserfassung bei registrierten Spalten nur genau dann Daten repliziert werden, wenn Änderungen an Daten erfolgten, die sich in der registrierten Spalte benden. Hingegen werden bei der Spalte Änderungserfassung bei beliebiger alle Daten repliziert, die geändert wurden, unabhängig davon, ob die entsprechende Spalte registriert wurde oder nicht. Bei der Option Replikation mit vollständiger Aktualisierung werden die Zieleinheiten zu einem bestimmten Zeitpunkt mit den Daten der Quelleinheit gefüllt, unabhängig davon, ob jedes einzelne Element der Datenmenge geändert wurde oder nicht. Bei dieser Option entsteht logischerweise relativ schnell eine groÿe Menge an Daten, die unnötig versendet wird. Der Einsatz dieser Option sollte daher gründlich überlegt werden. Allgemein ist anzumerken, dass die Erstbefüllung der Zieleinheit unabhängig von der gewählten Option gleich abläuft. Hierbei wird die Zieleinheit mit den zu replizierenden Daten aus der Quelleinheit befüllt. Es ist zudem möglich, explizit angegeben, durch welches Programm die Befüllung der Zieleinheit vorgenommen werden soll. 5.1.6 Zwischenspeichertabellen Ähnlich den Subskriptionsgruppen nehmen die Zwischenspeichertabellen eine wichtige Rolle innerhalb einer SQL-Replikationsumgebung ein. Über die auch als CD-Tabellen bezeich- neten Zwischenspeichertabellen werden die Änderungen an den zu replizierenden Daten transferiert. Der Begri der CD-Tabelle steht dabei für Change-Data Tables. Zwischenspeichertabellen existieren für jede Paarung aus einer Quell- und einer Zieleinheit. In diesen werden die folgenden Informationen abgelegt: • Protokollfolgenummer der erfassten Transaktion, • Protokollfolgenummer des Commit-Log-Records, • Transaktionstyp (UPDATE, INSERT oder DELETE), • after image -Wert, • before image -Wert. 20 5.1.7 Replikationsbereich Wie bereits im ersten Unterabschnitt zur SQL-Replikation erwähnt, arbeitet diese auf einer feineren Granulatsebene als beispielsweise HADR. Das macht sich vor allem im Replikationsbereich bemerkbar. Während bei HADR fast der gesamte Bereich der eigentlichen Datenbank repliziert werden kann, ist die Replizierung bei der SQL-Replikation auf Tabellen und teilweise auch Views beschränkt. Diese Einschränkung ist gleichzeitig aber auch ein Vorteil. So können auch nur vereinzelte, bestimmte Spalten oder eine gewisse Anzahl an Zeilen, die sich in einem bestimmten Zeilenbereich benden, repliziert werden. Dadurch können Daten, die entweder nie geändert werden oder aus einem beliebigen Grund nicht repliziert werden müssen, bei der Replikation auÿer Acht gelassen werden. Das spart zum einen Verkehrsaufkommen und zum anderen Speicherplatz auf dem Sekundärsystem. 5.2 Q-Replikation IBM DB2 LUW ist die sogenannte QReplikation [IBM05]. Das Q im Namen steht hierbei für Queue und bedeutet im Deutschen so viel wie Warteschlange. Aus dem Namen des Datenverteilungsverfahrens lässt sich also Ein weiteres Replikationsverfahren unter dem DBMS bereits erkennen, wo genau der Unterschied im Vergleich zur bereits vorgestellten SQLReplikation liegt. 5.2.1 Architektur einer Q-Replikationsumgebung Die Architektur einer Q-Replikationsumgebung unterscheidet sich nur gering von der einer SQL-Replikation. Auf den Primär- und Sekundärystemen benden sich mit besonderen Rechten ausgestattete Anwendungsprogramme, die hier als Q-Capture und Q-Apply bezeichnet werden. Zudem ist jedem dieser Anwendungsprogramme wieder eine Gruppe von Steuertabellen zugeordnet. Der wesentliche Unterschied zwischen einer Q- und einer SQL-Replikationsumgebung liegt in der bei der SQL-Replikation bezeichneten Zwischenspeichertabelle. Bei der Q-Replikation ist diese durch ein sogenanntes tem Warteschlangensys- ersetzt. Die Funktionalität des Warteschlangensystems wird sinnvollerweise durch das IBM-eigene Programm WebSphere MQ geliefert. WebSphere MQ zählt hierbei zu den so- genannten nachrichtenorientierten Zwischenanwendungen (auch MOM, Message Oriented Middleware, genannt). Die Aufgaben derartiger Zwischenanwendungen liegen im Aufbau und der Aufrechterhaltung von Kommunikationskanälen zwischen den verschiedenen mit der Zwischenanwendung verbundenen Programmen sowie der Verwaltung und Transferierung von Nachrichten, den sogenannten Messages. Es wird hierbei zwischen drei verschie- denen Kommunikationstypen unterschieden: • Message Passing, • Publish and Subscribe und • Message Queueing. Unter Message Passing versteht man eine direkte Kommunikation der Programme, die über die nachrichtenorientierte Zwischenanwendung miteinander in Verbindung stehen. Der Kommunikationstyp Publish and Subscribe bezeichnet das Versenden von NachrichAbonnenten versteht man hierbei Zielprogramme, ten an sogenannte Abonnenten. Unter 21 die über die Zwischenanwendung die Empfangsbereitschaft von Nachrichten des Herausgebers der Nachricht angemeldet haben. Beim Message Queueing werden die Nachrichten nicht direkt zwischen den Programmen versendet, sondern gelangen nach dem Absenden in ein Warteschlangensystem, von wo aus sie dann durch das Zielprogramm abgerufen und verarbeitet werden. Dieser Typ kommt bei der Q-Replikation zum Einsatz. Im Wesentlichen beinhaltet das Warteschlangensystem mindestens zwei Warteschlangenmanager, deren Aufgabe unter anderem in der Pege und Verwaltung der folgenden Komponenten liegt: • Sendewarteschlange, • Verwaltungswarteschlange, • Empfangswarteschlange und • Übertragungswarteschlange. Auf die einzelnen Aufgaben der verschiedenen Komponenten wird im Abschnitt 5.2.2 nä- her eingegangen. Auf jedem zur Q-Replikationsumgebung zugehörigen System muss mindestens ein Warteschlangenmanager installiert und funktionsfähig sein. Die folgende bildung 7 Ab- stellt eine Q-Replikationsumgebung schematisch dar (vgl. SQL-Replikations- umgebung in Abbildung 4). Abbildung 7: Architektur einer Q-Replikationsumgebung Die bereits in der SQL-Replikationsumgebung vorhandenen Subskriptionsgruppen sind auch bei der Q-Replikation ein elementarer Bestandteil der Replikationsumgebung. Sie werden in diesem Kontext als Q-Subskriptionen bezeichnet. Analog zur SQL-Replikation erfolgt in diesen die Denierung und Zuordnung der Quell- und Zieleinheiten sowie die Festlegung der für dieses Paar zuständigen Q-Capture- und Q-Apply-Programme sowie den zugehörigen Warteschlangenmanagern. 5.2.2 Funktionsweise Die Funktionsweise der Q-Replikation unterscheidet sich nur in geringem Maÿe von der Funktionsweise der SQL-Replikation. Aus diesem Grund widmet sich dieser Abschnitt nur 22 den elementaren Unterschieden und verzichtet auf eine Wiederholung der bereits im Detail in Abschnitt 5.1.2 geschilderten Funktionsweise der SQL-Replikation. Wurde bei der SQL-Replikation eine Änderung an einer registrierten Quelleinheit durch das sequenzielle Auslesen des Recovery-Protokolls erkannt, erfolgte durch das CaptureProgramm die Ablegung des after image -Wertes in den Hauptspeicher des Primärsystems. Wurde die jeweilige Transaktion gemäÿ Log-Eintrag erfolgreich abgeschlossen, legte daraufhin das Capture-Programm den after image -Wert in die Zwischenspeichertabelle ab. after image -Wertes hingegen nicht in eine Bei der Q-Replikation erfolgt die Ablage des Zwischenspeichertabelle, sondern stattdessen in eine Sendewarteschlange. Hierbei wird der Wert nicht als solcher abgelegt, sondern vor der Übertragung an die Sendewarteschlange in eine sogenannte Nachricht umgewandelt. Der Prozess der Erfassung einer Transaktion an einer registrierten Quelleinheit ist in der Abbildung 8 zusammenfassend dargestellt. Abbildung 8: Prozess der Erfassung einer Transaktion auf einer registrierten Quelleinheit. (1) Die Transaktion wird ausgeführt. (2) Die Transaktion wird im Protokoll verzeichnet. (3) Das Q-Capture-Programm erkennt die Transaktion auf der registrierten Quelleinheit. (4) Die after-image -Werte werden durch das Q-Capture-Programm in den Hauptspeicher gelegt. (5) Die Transaktion wurde laut Log-Eintrag erfolgreich abgeschlossen das Q-Capture-Programm entnimmt die Werte aus dem Hauptspeicher. (6) Die Transaktion wurde nicht erfolgreich abgeschlossen die Werte werden gelöscht. (7) Die Transaktion wurde erfolgreich abgeschlossen die Werte werden an den Wandler übergeben. Der Wandler wandelt die Informationen in Nachrichten um. (8) Die Nachrichten werden an die Sendewarteschlange geliefert. Die erstellten Nachrichten werden daraufhin durch die Übertragungswarteschlange an die Empfangswarteschlange weitergeleitet, von wo aus die Nachrichten dann durch das entsprechend für das Quell- und Zieleinheitspaar zugeordnete Q-Apply-Programm abgerufen und verarbeitet werden können. Derartige Nachrichten im Sinne von WebSphere MQ bestehen hierbei aus • Nachrichtenattributen und • Nachrichtendaten. Nachrichtenattribute weisen der Nachricht bestimmte Merkmale zu. Beispielsweise hat jede Nachricht eine eindeutige Nachrichten-ID, die durch WebSphere MQ erzeugt und zugeordnet wird. Desweiteren zählt eine sogenannte Korrelations-ID zu den Attributen. Hierunter versteht man einen Schlüssel, der für die Zuordnung einer oder mehrerer Antwortnachrichten zu der abgesendeten Anforderungsnachricht verwendet wird. 23 Nachrichtendaten verstecken sich im Anwendungsfall der Q-Repligenau die after image -Werte, die bei der SQL-Replikation in die Hinter der Bezeichnung kation unter anderem Zwischenspeichertabellen abgelegt wurden. Die Verwaltung und Übertragung der Nachrichten wird durch den Warteschlangenmanager übernommen (siehe dazu auch Abbildung 7). Diejenigen Nachrichten, die bereits erfolgreich an die Sendewarteschlange übertragen wurden, sind auch im Falle eines Ausfalls des Primärsystems existent. Dem Warteschlangenmanager sind eigene Systemtabellen zugewiesen. Er verwaltet zudem eigene Protokolldateien. Wie bereits angedeutet, erfolgt nach der Ablegung der Nachrichten in die Sendewarteschlange die Übertragung dieser über die Übertragungswarteschlange an die Empfangswarteschlange. Das entsprechende Q-Apply-Programm auf dem Zielsystem ruft die in der Empfangswarteschlange vorhandenen Nachrichten ab, wandelt diese in das SQL-Format um und wendet diese auf den Zieleinheiten an. Es ist an dieser Stelle durchaus möglich, dass ein Q-Apply-Programm mehrere Nachrichten parallel verarbeiten kann, da die Q-ApplyProgramme multithread-fähig sind. Dies ist natürlich nur möglich, wenn keine Abhängigkeiten zwischen den verschiedenen Nachrichten und damit den verschiedenen Transaktionen bestehen. Sollte dies dennoch nicht der Fall sein, werden die Transaktionen sequenziell verarbeitet. Die nachfolgende Abbildung 9 zeigt den Prozess der Datenreplizierung auf der Seite des Sekundärsystems. Abbildung 9: Prozess der Verarbeitung einer Transaktion auf einer registrierten Zieleinheit. (1) (2) Die Nachricht wird an die Empfangswarteschlange geliefert. (3) Das Q-CaptureProgramm ruft die Nachricht aus der Empfangswarteschlange ab. (4) Die Nachricht wird durch den Wandler in das SQL-Format transformiert. (5) Die umgewandelte Nachricht wird auf der registrierten Zieleinheit angewendet. Über die bereits angesprochene Verwaltungswarteschlange werden Informationen durch das Q-Apply-Programm auf dem Sekundärsystem an das jeweilige Q-Capture-Programm auf dem Primärsystem gesendet. Die folgende Abbildung 10 gibt einen grundlegenden Über- blick über die Kommunikation zwischen dem Primärsystem, den Warteschlangenmanagern und dem Sekundärsystem. Abbildung 10 macht deutlich, dass die Übertragungswarteschlange die Elementarkomponente für die Verbindung des Primär- mit dem Sekundärsystem darstellt. Es wird zudem ersichtlich, dass das Warteschlangensystem einen entscheidenden Faktor in Bezug auf die Gesamtperformance der Replikationsumgebung darstellt, da jede zu replizierende Änderung auf den Quelleinheiten auf dem Sekundärsystem den Weg über die verschiedenen Komponenten des Warteschlangensystems zu gehen hat. 24 Abbildung 10: Grundlegender Überblick über die Kommunikation mit den Warteschlangenmanagern. 5.2.3 Replikationstypen Bei der Konstruktion einer Q-Replikationsumgebung und der daran anschlieÿenden Erstellung der Q-Subskriptionen kann zwischen drei verschiedenen Replikationstypen gewählt werden: • Unidirektionale Replikation, • Bidirektionale Replikation sowie • Peer-to-peer Replikation. Der unidirektionale Replikationstyp sorgt für die Replizierung von Transaktionen jeweils nur in eine Datenussrichtung. Das bedeutet, dass Transaktionen auf Daten auf einem Primärsystem immer nur in Richtung der Sekundärsysteme repliziert werden können und nicht umgekehrt. Zieleinheiten werden somit nur durch das Q-Apply-Programm verändert. Dieser Replikationstyp ermöglicht die gesonderte Replizierung bestimmter Spalten oder eines bestimmten Zeilenbereiches. Zudem ist es möglich, Daten aus registrierten Quelleinheiten zur Transformation an gespeicherte Prozeduren zu übergeben, bevor diese durch Umwandlung in eine Nachricht an die Sendewarteschlange geliefert werden. Zwischen dem Primär- und dem Sekundärsystem existiert mindestens ein Warteschlangensystem. Da die Datenussrichtung bei der unidirektionalen Replikation von der Quell- zur Zieleinheit verläuft, bedarf es pro Quell- und Zieleinheitspaar nur eine Q-Subskription. Beim bidirektionalen Replikationstyp ist die Replizierung in beide Richtungen erlaubt. Kon- kret bedeutet dies, dass Transaktionen sowohl auf der registrierten Quelleinheit als auch auf der registrierten Zieleinheit auf die entsprechend zugeordnete Gegeneinheit repliziert werden können. Im Grunde ist die eigentliche Quelleinheit gleichzeitig Zieleinheit und die eigentliche Zieleinheit gleichzeitig auch Quelleinheit. Hierbei gilt es bestimmte Regeln zu beachten, von denen im Folgenden einige genannt sind: 1. Die Quell- und Zieleinheiten müssen priorisiert werden, damit im Koniktfall, d.h. wenn bei einem Quell- und Zieleinheitspaar jeweils der identische Datensatz geändert 25 wurde und repliziert werden soll, eine Einheit vorgezogen und der Konikt behoben werden kann. 2. Die Quell- und Zieleinheiten müssen dieselbe Anzahl von Spalten und Zeilen besitzen. 3. Die Spaltennamen der Quell- und Zieleinheiten müssen identisch sein. Zudem müssen die Datentypen übereinstimmen. 4. Die Namen der Quell- und Zieleinheiten können wie auch die Schemabezeichnungen unterschiedlich sein. Da die Replikation in zwei Richtungen erfolgen kann, bedarf es für jede Datenussrichtung zwischen einer Quell- und einer Zieleinheit jeweils eines zugeordneten Warteschlangensystems. Auch die Q-Subskriptionen müssen jeweils beide Datenussrichtungen abdecken; es gibt also für jedes Quell- und Zieleinheitspaar zwei Q-Subskriptionen. Eine Erweiterung des bidirektionalen Replikationstypes stellt der onstyp peer-to-peer Replikati- dar. Bei diesem werden alle erfolgreich abgeschlossenen Transaktionen auf einem Replikationsteilnehmer an alle anderen Replikationsteilnehmer über die Warteschlangensysteme weitergeleitet. Es gelten zudem die gleichen Regeln wie bei der bidirektionalen Replikation. Zusätzlich werden die zu replizierenden Tabellen um zwei Spalten erweitert. Diese sind eine Spalte zur Speicherung einer Zeitmarke und eine Spalte, in der eine nummerische Zahl abgelegt werden kann. Die Spalte zur Speicherung der Zeitmarke ist vor allem in Koniktsituationen von Bedeutung. Dann wird anhand dieser Spalte der aktuellste Eintrag ermittelt und damit der Konikt aufgelöst. Die zwei zusätzlichen Spalten werden durch Trigger verwaltet, die wiederum bei der Erstellung der Q-Subskriptionen angelegt werden. Die Transaktionen werden auf den Replikationsteilnehmern in asynchroner Verfahrensweise repliziert. Das bedeutet, dass der Datenbestand auf den unterschiedlichen Replikationsteilnehmern möglicherweise erst dann nahezu identisch ist, wenn keine weiteren Transaktionen auf den Replikationsteilnehmern erfolgreich ausgeführt werden. Die Anzahl der Q-Subskriptionen erhöht sich im Vergleich zum bidirektionalen Replikationstyp um den Faktor der Anzahl der Replikationsteilnehmer. Das bedeutet beispielsweise bei einer Replikationsumgebung mit drei Teilnehmern, dass letztendlich sechs QSubskriptionen angelegt werden müssen. Ähnlich ist es bei der Anzahl der Warteschlangensysteme: Zwischen jeder Paarung und in jede Datenussrichtung bedarf es der Zuordnung je eines Warteschlangensystems. 5.2.4 Replikationsbereich Grundsätzlich unterscheidet sich der Replikationsbereich bei der Q-Replikation nur in einem Punkt von dem der SQL-Replikation: dem der Sichten. Während bei der SQLReplikation die Replizierung von Sichten möglich ist, ist dies bei der Q-Replikation nicht der Fall. Darüber hinaus ist der Replikationsbereich abhängig vom gewählten Replikationstyp. So können bei der unidirektionalen Replikation Tabellen wie auch einzelne Spalten oder Zeilen repliziert werden. Die Auswahl bestimmter Spalten über Vergleichselemente ist somit möglich. Beim bidirektionalen Replikationstyp ist die Replizierung bestimmter Zeilen durch Vergleichselemente nicht möglich. Bei der Replikation von bestimmten Spalten oder ganzer Tabellen gibt es dagegen keine Einschränkungen. Gleiches gilt auch für den peer-to-peer Replikationstyp. 26 5.3 High Availability Disaster Recovery (HADR) High Availability Disaster Recovery (HADR) ist ein IBM-eigenes softwarebasiertes Repli- kationsverfahren zur Verbesserung der Hochverfügbarkeit eines DBMS [IBM07a]. Es ist bereits ab der Express Edition (EE) von Nutzung von HADR in der kostenfreien IBM DB2 LUW im Lizenzpaket enthalten. Die Express-C Edition ist auch möglich, allerdings bedarf es hier erst der Lizenzierung des Produktpaketes. 5.3.1 Architektur und Funktionsweise Die Kernaufgabe von HADR liegt in der kontinuierlichen Replizierung von neuen oder veränderten Informationen von einem Primär- auf ein Sekundärsystem. Durch die eigens Automatic Client Reroute ), auf die im Abschnitt 5.3.3 mitgelieferte ACR-Funktionalität ( näher eingegangen wird, ist es zudem möglich, bei einem Ausfall des Primärsystems die clientseitigen Anfragen an das bisherige Sekundärsystem umzuleiten, ohne dass der Benutzer davon Kenntnis nimmt. Das Sekundärsystem wird zusätzlich in die Rolle des Primärsystems gesetzt, was wiederum zur Sicherstellung einer hohen Verfügbarkeit führt. Die Funktionalität des automatisierten Umschaltens muss in der hier betrachteten Version jedoch durch externe Softwarelösungen übernommen werden. Im Folgenden ist mit einem Takeover ein manuelles Umschalten gemeint. Nach der Behebung des Fehlers auf dem Primärsystem ist es möglich, die ursprüngliche Rollenverteilung zwischen den Systemen wiederherzustellen. Allgemein lässt sich zu dieser Konstellation anmerken, dass Anfragen nur an das jeweilige aktuelle Primärsystem möglich sind. Ein direkter Zugri seitens der Anwendungen auf das Sekundärsystem ist somit ausgeschlossen. Die hinter dem HADR-System liegende Architektur als solche zeichnet sich durch ihre klare Strukturiertheit aus. Als HADR-System sei hierbei das Gesamtkonstrukt bestehend aus einem Primär- und Sekundärsystem mit den entsprechenden Datenbanken und der dazugehörigen ACR-Funktionalität bezeichnet. Auf den beiden Systemen bendet sich jeweils mindestens eine Instanz des DBMS IBM DB2 LUW. Es sei angemerkt, dass die HADR- Funktionalität auf der Ebene der Datenbank angesiedelt ist. Das bedeutet, dass in einer Instanz des DBMS mehrere Datenbanken angelegt sein können, von denen entweder eine oder mehrere mittels HADR repliziert werden. Die Grundlage der HADR-Architektur stellt die Transferierung von sogenannten Logical Log Records von einem Primär- auf ein Sekundärsystem über eine zu diesem Zwecke aufgebaute TCP/IP-Verbindung dar. Diese ermöglicht es zudem, dass die beiden Systeme an geographisch unterschiedlichen Lokationen stationiert werden können, was wiederum eine wichtige Anforderung an Hochverfügbarkeitssysteme, insbesondere Disaster Recovery betreend, darstellt. Eine schematische Darstellung einer HADR-Replikationsumgebung zeigt die Abbildung 11. Aufgrund der hohen Bedeutung der Logical Log Records in der HADR-Architektur sollen diese im Folgenden näher erklärt werden. Unter einem Logical Log Record versteht man sinngemäÿ einen durch einen DB2 -Agenten, einen DBMS-eigenen Prozess, erzeug- ten Protokolleintrag. Protokolleinträge enthalten wichtige Informationen über die durchgeführte Transaktion und dienen unter anderem zur Einhaltung der geforderten ACID - Atomicity (Atomarität), Consistency (Konsistenz), Isolation und Durability (Dauerhaftigkeit). Die nachfolgende Tabelle 7 erEigenschaften. ACID steht dabei als Abkürzung für klärt die ACID-Eigenschaften gemäÿ [HSS07]. Protokolleinträge werden genau dann generiert, wenn Transaktionen Änderungen an Tabelleneinträgen vornehmen. Wenn beispielsweise ein Anwendungsprogramm einen bestimmten 27 Abbildung 11: Architektur einer HADR-Replikationsumgebung Eigenschaft Erklärung Atomarität Eine Transaktion wird entweder ganz oder gar nicht ausgeführt. Das bedeutet, dass Transaktionen keine Zwischenzustände nach einem Transaktionsabbruch hinterlassen können. Konsistenz Nach der erfolgreichen Ausführung einer Transaktion muss sich die Datenbank in einem konsistenten, zulässigen Zustand benden. Transaktionen müssen demnach also alle Integritätsbedingungen erfüllen. Isolation Transaktionen werden isoliert ausgeführt. Das bedeutet, dass parallel ausgeführte Transaktionen sich nicht gegenseitig beeinussen können. Dauerhaftigkeit Die Änderung, die durch eine erfolgreich ausgeführte Transaktion herbeigeführt wurde, gilt dauerhaft. Tabelle 7: Erklärung der ACID-Eigenschaften Datensatz aktualisieren möchte (etwa in Form der Aktualisierung einer Tabellenspalte bei einem spezischen Eintrag), so wird die entsprechende Datenseite von der Festplatte in den Buerpool geladen, falls sie nicht bereits in diesem enthalten ist. Der DB2 -Agent liest die entsprechende Seite aus dem Buerpool, ändert die entsprechende Seite und legt diese zurück in den Buerpool. Durch diese Änderung der Seite wird nun ein Protokoll- Logical Log Puer abgelegt. Dieser Protokolleintrag wird im Fortgang durch den DBMS-eigenen Prozess db2loggw in das Logical Log File (Protokolldaeintrag erzeugt und in den tei) geschrieben. Erst nachdem dies erfolgt ist, kann die modizierte Datenseite aus dem Buerpool zurück auf die Festplatte geschrieben werden, so dass im Fehlerfall durch verschiedene Recovery-Verfahren die ACID-Eigenschaften sichergestellt werden können. Diese Vorgehensweise wird auch als Write Ahead Logging (WAL) bezeichnet. Die Funktionsweise von HADR lässt sich in verschiedene Phasen einteilen. Diese sind im Einzelnen die Phase der Initialisierung, die 28 Catch-Up-Phase, die Peer-State-Phase, die Failure-Phase, die Failover-Phase, die Der Gesamtzyklus der Phasen ist in Phase der Reintegration und die Failback-Phase. Abbildung 12 schematisch dargestellt. Nach der Konguration von HADR auf dem Primär- und Sekundärsystem ist das HADRSystem genau dann gestartet, wenn die erste Verbindung zwischen den Datenbanken des Primär- und Sekundärsystems aufgebaut werden konnte, welches gleichzeitig die Hauptaufgabe der db2hadrp Initialisierungsphase darstellt. Fortan spielen die zwei DBMS-eigenen Prozesse und db2hadrs eine entscheidende Rolle, da sie sich in Bezug auf die Abwicklung des Datentransfers zwischen den beteiligten Datenbanken und der Bearbeitung von Systemmeldungen verantwortlich zeichnen. Abbildung 12: Zyklus der verschiedenen Phasen des HADR-Verfahrens Bei der Aktivierung der Datenbank auf dem Primärsystem wird der DBMS-eigene Prozess db2hadrp erzeugt. Dieser liest nun die Kongurationsparameter ein und önet einen Port, um eine Anfrage für einen Verbindungsaufbau durch das Sekundärsystem entgegennehmen zu können. Während dieser Aufbauphase ist keine Verbindung durch einen Client an das Primärsystem erlaubt. Das Primärsystem wartet dabei solange auf den Versuch eines Verbindungsaufbaus, bis die in dem Kongurationsparameter HADR TIMEOUT festgelegte Zeit abgelaufen ist. Konnte hierbei keine Verbindung mit einem Sekundärsystem aufgebaut werden, wird die Datenbankaktivierung abgebrochen. Dieser Umstand kann umgangen werden, indem das HADR-System mit der Erweiterungsklausel FORCE gestartet wird. Das Primärsystem wartet in diesem Falle dann nicht mehr auf den erfolgreichen Aufbau einer Verbindung mit einem Sekundärsystem, sondern startet sofort mit dem Betrieb. Gleichzeitig wird aber ein sogenannter Listener initialisiert, dessen Aufgabe darin besteht, auf dem vorgesehenen Port auf eine Verbindungsanfrage des Sekundärsystems zu warten und diese gegebenenfalls entgegenzunehmen. Das Sekundärsystem kann sich dadurch auch im laufenden Betrieb des Primärsystems nachträglich in dieses einklinken. Sobald der Verbindungsaufbau erfolgreich war, startet das HADR-System seine Funktionalität. Es sei hierbei darauf hingewiesen, dass die erwähnte Erweiterungsklausel FORCE Nachteile mit sich bringt, die im Abschnitt 6.2 erläutert werden. Wurde die Verbindung zwischen den Datenbanken auf dem Primär- und Sekundärsystem erfolgreich aufgebaut, werden daraufhin der Status und die Funktionalität des HADRSystems überprüft. Dazu werden Mitteilungen vom Primär- zum Sekundärsystem über die aufgebaute TCP/IP-Verbindung verschickt. Das Sekundärsystem registriert diese und sendet sie an das Primärsystem zurück. Dieses Verfahren wird bei IBM auch als heartbeat - Mechanismus bezeichnet, da die Mitteilungen metaphorisch als Herzschläge des Systems 29 angesehen werden können. Umgangssprachlich ist dieses Verfahren auch als handshake - Verfahren bekannt. Auf die eben beschriebene Initialisierungsphase folgt die sogenannte (siehe dazu Schritt (1) in Abbildung 12). Catch-Up-Phase In dieser erfolgt der Abgleich der Datenbe- stände beider Systeme. Damit ist gemeint, dass das Primärsystem die notwendigen Protokolleinträge an das Sekundärsystem sendet, sodass beide Datenbanken einen identischen Datenbestand aufweisen. Das Lesen der Protokolleinträge auf dem Primärsystem wird da- db2lfr übernommen, welcher zudem die Protokolleindb2hadrp weiterleitet, die von dieser dann wiederum db2hadrs auf dem Sekundärsystem transferiert werden. bei von dem DBMS-eigenen Prozess träge an den DBMS-eigenen Prozess an den DBMS-eigenen Prozess Das Übermitteln der Protokolleinträge erfolgt genau dann, wenn auf dem Primärsystem die Protokolleinträge in die Protokolldatei geschrieben werden. Der DBMS-eigene Prozess db2hadrs sorgt schlieÿlich dafür, dass die übermittelten Informationen auf dem Sekundär- system eingespielt werden. Der Vorgang der Transferierung der Protokolleinträge wird auch als Log Shipping bezeichnet. Sobald die Transferierung der Protokolleinträge abgeschlossen ist und die beiden Systeme somit einen identischen Datenbestand aufweisen, geht das HADR-System in die nächste Phase, die Prozess Peer-State-Phase, über (Schritt (2)). In dieser wird zuerst der DBMS-eigene db2lfr beendet und anschlieÿend der DBMS-eigene Prozess db2loggw gestartet. Die Hauptaufgabe dieses Prozesses besteht darin, die Protokolleinträge in die Protokolldateien zu schreiben. Im Rahmen der HADR-Funktionalität erhält dieser Prozess eine Zusatzaufgabe, die vorsieht, direkt nach dem Schreiben der Protokolleinträge in die Protokolldatei db2hadrp zu senden mit einem Hinweis darDb2loggw wartet anschlieÿend solange, bis es eine Rückmeldung über den Transferstatus von db2hadrp erhält. Bis es zu dieser Rückmeldung kommt, schickt der DBMS-eigene Prozess db2hadrp die entsprecheneine Mitteilung an den DBMS-eigenen Prozess auf, wo sich die genannten Protokolleinträge genau benden. den Einträge an das Sekundärsystem. Ob die Transferierung erfolgreich war oder nicht, ist dann in der bereits angesprochenen Rückmeldung an Die Tatsache, dass db2loggw db2loggw enthalten. solange wartet, bis es eine Rückmeldung von db2hadrp erhält, ist von enormer Bedeutung. Denn dies kann dazu führen, dass das Primärsystem neue Einfüge- bzw. Änderungsoperationen vorübergehend blockiert. Die verschiedenen Synchronisationsmodi des HADR-Systems lassen jedoch auch andere Abhängigkeitsregeln zu, sodass es nicht in jedem Falle zu Blockierungen kommen muss (siehe dazu auch Abschnitt Seit Beginn der Peer-State-Phase bendet sich das Sekundärsystem in einem rollforward - 5.3.2). Modus. Das bedeutet, dass das Sekundärsystem zum einen wie bereits erwähnt keine Anfragen seitens der Anwendungen auf dem Anwendungsserver entgegennehmen kann und zum anderen, dass die vom Primärsystem empfangenen Protokolleinträge sofort eingearbeitet werden können. Dies wiederum führt dazu, dass sich das Sekundärsystem zu jedem Zeitpunkt in einem einsatzbereiten Zustand mit identischem Datenbestand bendet. Die Peer-State-Phase ist zudem eine andauernde Phase. Sie wird erst unterbrochen, wenn es zu einem Ausfall des Primärsystems oder zu einem Verbindungsabbruch zwischen den beiden Systemen kommt. Dieser Zeitpunkt wird durch die Failure-Phase beschrieben (Schritt (3)). Handelt es sich um einen geplanten Ausfall, springt das HADR-System sofort in die Failover-Phase über (Schritt (4)). Bei einem Ausfall des Primärsystems springt das Failover-Phase über (Schritt (5)). HADR-System ebenso in die 30 In dieser Phase kommt es zu dem sogenannten Takeover. Hiermit ist die Änderung der Rol- lenverteilung im HADR-System gemeint. Das eigentliche Sekundärsystem fungiert fortan als Primärsystem, während das bisherige Primärsystem für die Fehlerbehebung zur Verfügung steht. In diesem Fall muss Sorge dafür getragen werden, dass das bisherige Primärsystem keine aktive Funktionalität innerhalb des HADR-Systems mehr hat, da es sonst zu Konikten kommen kann, die durch das HADR-System nicht selber gelöst werden können. Ist der Takeover erfolgreich abgeschlossen, kann das HADR-System bis auf Weiteres in dieser Konstellation laufen. Es werden in diesem Zeitraum allerdings keine Replizierungsmaÿnahmen durchgeführt. Sobald das bisherige Primärsystem wieder in Stand gesetzt ist, kann es entweder als Sekundärsystem fungieren oder aber wieder als Primärsystem eingesetzt werden. Hierfür muss das bisherige Primärsystem wieder in das HADR-System integriert werden. Dieser Prozess wird als Phase der Reintegration bezeichnet (Schritt (6)). Im Falle, dass das bisherige Primärsystem auch wieder als Primärsystem eingesetzt werden soll, wechselt das HADR-System nun in die Failback-Phase (Schritt (7)), in wel- cher die Wiederherstellung der bisherigen Rollenverteilung erfolgt. Danach setzt wiederum die Catch-Up-Phase ein (Schritt (8)), wodurch sich der Zyklus schlieÿt und wieder die volle HADR-Funktionalität gewährleistet ist. 5.3.2 Synchronisationsmodi Die bereits im vorhergehenden Abschnitt angesprochene Problematik der Wartedauer des DBMS-eigenen Prozesses db2loggw während der Peer-State-Phase zeigt die Bedeutung der verschiedenen Synchronisationsmodi, die das HADR-System zur Verfügung stellt. Man unterscheidet hierbei die folgenden drei verschiedene Synchronisationsmodi: • synchronous, • near-synchronous und • asynchronous. Sie heben sich dadurch voneinander ab, in welcher Abhängigkeit die beiden DBMS-eigenen Prozesse db2loggw und db2hadrp miteinander arbeiten und inwiefern das Gesamtsystem gegenüber einem Datenverlust abgesichert ist. Der synchronous -Modus ist der strengste und sicherste. Der DBMS-eigene Prozess db2loggw db2hadrp eine Rückmeldung über die erfolgreiche Verarbeitung wartet hierbei solange, bis der Protokolleinträge auf dem Sekundärsystem meldet. Erst dann erhält der DBMS-eigene Prozess db2loggw die Erlaubnis, neue Transaktionen auf dem Primärsystem zu verarbeiten. Das bedeutet, dass erst nach Eintreen der genannten Erlaubnis einem COMMIT für weitere Transaktionen stattgegeben wird. Diese stringente Vorgehensweise sorgt für die bestmöglichste Sicherheit vor einem Datenverlust bei einem Ausfall eines Teils des HADR - Systems, birgt jedoch in gleicher Weise auch Nachteile im Hinblick auf die Performance des Gesamtsystems, da db2loggw eben erst dann fortfahren kann, wenn die angesprochene Rückmeldung eingetroen ist. Ein weiterer Modus trägt die Bezeichnung near-synchronous. Dieser ist als Standard vordb2loggw die gesehen. Es ist hierbei bereits ausreichend, wenn der DBMS-eigene Prozess Rückmeldung erhält, dass die Protokolleinträge erfolgreich auf dem Sekundärsystem empfangen wurden. Der Nachteil dieses Modus liegt darin, dass nicht sichergestellt ist, dass 31 die gesendeten Protokolleinträge auch tatsächlich verarbeitet werden konnten, während db2loggw auf dem Primärsystem bereits neue Transaktionen verarbeiten kann. Es kann in diesem Modus also zu einer Abweichung des Datenbestandes auf dem Sekundärsystem kommen. Der dritte Modus schlieÿlich wird als asynchronous bezeichnet. Es ist hier bereits aus- reichend, wenn die Protokolleinträge in Richtung Sekundärsystem abgesendet wurden. Es spielt also keine Rolle, ob die Protokolleinträge auch tatsächlich auf dem Sekundärsystem angekommen sind, geschweige denn erfolgreich verarbeitet werden konnten, während db2loggw auf dem Primärsystem bereits neue Transaktionen verarbeiten kann. Dieser Mo- dus ermöglicht die beste Performance, da nicht auf eine Rückantwort des Sekundärsystems gewartet werden muss, ist aber eben im Blick auf die Datensicherheit auch der schlechteste von den drei betrachteten Modi. Wie auch bei dem near-synchronous -Modus kann es zu Abweichungen im Datenbestand auf dem Sekundärsystem kommen. Die folgende Tabelle 8 stellt abschlieÿend einen Überblick über die drei verschiedenen Synchronisationsmodi des HADR -Systems dar. Modus Erfüllte Bedingung synchronous Protokolleinträge müssen auf dem Sekundärsystem Sicherheit Performance + Se- o o abgesen- + erfolgreich verar- beitet sein. near-synchronous Protokolleinträge müssen das kundärsystem erreicht haben. asynchronous Protokolleinträge müssen det sein. Tabelle 8: Übersicht über die Synchronisationsmodi des HADR-Systems IBM empehlt die Nutzung des synchronous -Modus nur dann, wenn sich die beiden Sys- teme physisch innerhalb einer Umgebung benden, beispielsweise auf direkt verbundenen Einheiten in einem Rack. Unter einem Rack versteht man in diesem Zusammenhang eine Art Haltevorrichtung für Serversysteme, wie man sie in Rechenzentren vorndet. Betreibt Local Area Network ), so wird der near-synchronous -Modus empfohlen. Bei dem Einsatz in einem WAN (Wide Area Network ) empehlt IBM die Verwendung des asynchronous -Modus. man das Primär- und Sekundärsystem über ein LAN ( 5.3.3 Automatic Client Reroute (ACR) Automatic Client Reroute (ACR). Im Falle eines Ausfalls der Verbindung zwischen dem DB2 -Client Ein wichtiger Bestandteil des HADR-Systems ist die DB2-eigene Funktionalität auf der einen Seite und dem Primärsystem auf der anderen Seite sorgt ACR dafür, dass die DB2 -Client auf das bereitstehende Sekundärsystem umgeleitet werden, ohne DB2 -Komponenten kombinierbar, unter anderem mit dem Verfahren der SQL-Replikation, der Tivoli System Automation (TSA) oder aber eben mit HADR. Die Abbildung 13 zeigt das Wirkungsfeld Anfragen des dass es eines manuellen Eingris bedarf. ACR ist mit verschiedenen von ACR. Damit ACR überhaupt nutzbar ist, bedarf es der Eintragung einer alternativen Datenbank, die logischerweise auf einem Sekundärsystem liegt, in den zuständigen Kongurationsparameter der Datenbank auf dem Primärsystem. Der entsprechende Befehl ist dem 1 zu entnehmen. 32 Listing Abbildung 13: Automatic Client Reroute Listing 1: Sekundärsystem eintragen db2 update alternate server for d a t a b a s e DATABASE using hostname HOSTNAME p o r t PORTNUMBER Die Funktionsweise von ACR gliedert sich in verschiedene Teilschritte, die im Zusammenwirken mit dem HADR-System durchlaufen werden. Nachdem die alternative Datenbank in der Konguration der Datenbank auf dem Primärsystem eingetragen wurde und ACR somit startbereit ist, erfolgt bei dem initialen Verbindungsaufbau die Übermittlung der Verbindungsinformationen für das Sekundärsystem an die DB2 -Clients. Zum Starten von DB2 -Client auf dem An- ACR kommt es genau dann, wenn die Verbindung zwischen dem wendungsserver auf der einen Seite und der Datenbank des Primärsystems auf der anderen Seite unterbrochen wird. In diesem Fall gilt das Primärsystem aus Sicht des DB2 -Client als nicht verfügbar. Der DB2 -Client versucht nun abwechselnd eine Verbindung entweder zum Primär- oder zum Sekundärsystem aufzubauen. Damit überhaupt eine Verbindung zum Sekundärsystem aufgebaut werden kann, benötigt der DB2 -Client nun die bereits über- tragenen Verbindungsdaten für das Sekundärsystem. Wenn weiterhin keine Verbindung Takeover. DB2 -Client, einen Verbin- zum Primärsystem aufgebaut werden kann, erfolgt das bereits angesprochene Das nun bereitstehende Sekundärsystem kann den Versuch des dungsaufbau herzustellen, erfolgreich annehmen. In diesem Fall kann das Primärsystem seine Arbeit wieder aufnehmen und mit der Behebung des Fehlers auf dem ursprünglichen Primärsystem begonnen werden. Die Phase, in der der DB2 -Client versucht, nach dem Abbruch der Verbindung mit dem Primärsystem diese wiederherzustellen, stellt einen entscheidenden Zeitfaktor dar. Je länger der DB2 -Client die Wiederherstellung versucht, desto länger kann der Anwendungsserver keine Anfragen an ein funktionierendes System senden beziehungsweise empfangen. Aus diesem Grund ist es notwendig, diesen Zeitfaktor gering zu halten. Dazu stehen eine Reihe von Registervariablen des DBMS IBM DB2 LUW zur Verfügung, die im Folgenden kurz erläutert werden. Die Registervariable DB2TCP CLIENT CONTIMEOUT gibt diejenige Zeit an, die DB2 -Client versucht, eine Verbindung mit dem Primärsystem wiederherzustellen. Ist diese Variable auf Null oder gar nicht gesetzt, so versucht der DB2 -Client unendlich lang der eine Verbindung wiederherzustellen. 33 Die Zeitdauer, wie lange ein Anfrage wartet, wird in DB2 -Client auf die Rückantwort des Primärsystems nach einer DB2TCP CLIENT RVCTIMEOUT festgeschrieben. Erfolgt nach Ablauf der Zeitdauer keine Rückantwort, so gilt die Verbindung zum Primärsystem als fehlerhaft. Die Verbindung gilt auch dann als fehlerhaft, wenn die Beantwortung der Anfrage länger andauert als auf die Rückantwort gewartet werden darf. Aus diesem Grund sollte man diese Variable mit Bedacht setzen. Ist sie nicht gesetzt oder hat den Wert Null, so gibt es keinen Abbruch der Verbindung. Wie oft der DB2 -Client Registervariable eine Wiederherstellung der Verbindung versucht, wird durch die DB2 MAX CLIENT CONNRETRIES deniert. Der Standardwert ist Zehn. Der zeitliche Abstand zwischen den verschiedenen Wiederherstellungsversuchen wird in der Registervariable DB2 CONNRETRIES INTERVAL festgeschrieben. Der Standard- wert beträgt hier 30 Sekunden. Die Nutzung der ACR-Funktionalität bringt allerdings auch eine Reihe von Einschränkungen mit sich, von denen im Folgenden einige genannt werden. In Bezug auf das nutzbare Verbindungsprotokoll kommt so beispielsweise nur TCP/IP in Frage. Auch wird die ACRFunktionalität nicht in allen DB2 -Produkten unterstützt, sondern lediglich in den Produk- ten für Unix-, Linux- und Windows-Betriebssysteme. Die eingestellten Authentizierungsarten des DBMS auf den jeweiligen Systemen müssen zudem genauso übereinstimmen wie die Versionen von IBM DB2 LUW, lediglich unterschiedliche Fix Packs sind hier erlaubt. 5.3.4 Replikationsbereich Nachdem in den vorhergehenden Abschnitten die Architektur und Funktionsweise, die verschiedenen Synchronisationsmodi und das ACR im Mittelpunkt der Betrachtung standen, soll der nun folgende Abschnitt aufzeigen, welche Operationen und Objekte repliziert und welche durch das HADR-System nicht repliziert werden. Zum erstgenannten Fall zählen beispielsweise: • DDL (Data Denition Language) -Operationen, • DML (Data Manipulation Language) -Operationen, • Online-Reorganisation, • Oine-Reorganisation sowie • Metadaten für gespeicherte Prozeduren und benutzerdenierte Funktionen. Unterschiede gibt es hierbei zwischen der Online- und der Oine-Reorganisation. Während bei der Online-Reorganisation das Sekundärsystem nicht in Rückstand geraten kann, weil alle Operationen detailliert protokolliert werden, ist dies bei der Oine-Reorganisation nicht der Fall. Hier kann das Sekundärsystem durchaus in Rückstand geraten, da die einzelnen Operationen für eine Vielzahl von betroenen Zeilen protokolliert werden. Auch in Bezug auf die gespeicherten Prozeduren und benutzerdenierten Funktionen sei darauf hingewiesen, dass nur die Metadaten, also beispielsweise die Erstellungsbefehle, repliziert werden, aber nicht die entsprechenden externen Codes der gespeicherten Prozeduren oder die Objektdateien der benutzerdenierten Funktionen. Diese Objekte müssen 34 manuell auf dem Sekundärsystem unter dem gleichen Pfad wie auf dem Primärsystem abgelegt werden, da die entsprechenden gespeicherten Prozeduren oder benutzerdenierten Funktionen sonst auf dem Sekundärsystem nicht ausführbar sind. Weiterhin werden nicht repliziert: not logged • Tabellen, die mit der Option • BLOBs • Data Links, • UPDATE DB CFG - und UPDATE DBM CFG -Befehle sowie • Recovery und Manipulation der und erstellt wurden, CLOBs, die gröÿer als ein Gigabyte sind, history le. not logged erstellt wurden, haben im laufenden HADR-System ist gemeint, dass ein Zugri auf diese Tabellen nach einem Ta- Tabellen, die mit der Option keine Gültigkeit. Hiermit keover auf das neue Primärsystem zu einer Fehlermeldung führt. BLOBs und CLOBs, die gröÿer als ein Gigabyte sind, werden nicht repliziert, da Ma- nipulationen an diesen Daten in dieser Gröÿe nicht mehr durch das DBMS LUW IBM DB2 protokolliert werden. Der entstehende Speicherbereich wird jedoch auf dem Sekun- därsystem zugeordnet und die entsprechenden Einträge in der Tabelle mit binären Nullen aufgefüllt. 5.4 Vergleich und Bewertung Die vorangegangenen drei Abschnitte des fünften Kapitels haben sich im Detail mit den drei in dieser Studienarbeit betrachteten Replikationsverfahren unter dem DBMS DB2 LUW IBM beschäftigt. So wurden die Architektur der jeweiligen Replikationsumgebung, die Funktionsweise des Verfahrens und spezielle Eigenschaften erläutert. Der folgende vierte Abschnitt soll die Verfahren der SQL-Replikation, Q-Replikation und HADR nun vergleichen und bewerten. Die Verfahren werden hinsichtlich der folgenden vier Kategorien verglichen: • Architektur einer Replikationsumgebung, • Funktionsweise, • Replikationsbereich sowie • Verwaltung und Pege. Der Vergleich schlieÿt mit einem Blick auf die Untersuchungen zu Performance-Unterschieden zwischen der SQL- und der Q-Replikation von John Ascho [Asc05]. Die Bewertung der einzelnen Vergleichspunkte erfolgt mittels eigens denierter Skalenwerte: • + (ja) • o (teilweise) • (nein) 35 5.4.1 Architektur einer Replikationsumgebung Die Architektur einer Replikationsumgebung ist gerade im Hinblick auf die Wahl eines Replikationsverfahrens in Abhängigkeit des gegebenen Szenarios und der daraus resultierenden Problemstellung von enormer Bedeutung. So richtet sich beispielsweise die Anzahl der Sekundärsysteme danach, ob neben der Datenreplizierung auch eine Lastverteilung vorgenommen werden soll oder ob aufgrund der begrenzten nanziellen Möglichkeiten eine Lösung gefunden werden soll, bei der die Anzahl der Sekundärsysteme möglichst gering ist, aber dennoch die erfolgreiche Datenreplizierung gewährleistet werden kann. Die Tabelle 9 gibt einen Überblick über die entsprechenden Vergleichspunkte, die im Folgenden auch bewertet werden. Merkmal SQL-Replikation Q-Replikation HADR Mehrere Primärsysteme erlaubt + + Mehrere Sekundärsysteme erlaubt + + Automatisches + + + + + o o + + Weiterleitung von Anfragen bei geplantem oder ungeplantem Ausfall Lesezugri auf Zieltabellen auf dem Sekundärsystem Schreibzugri auf Zieltabellen auf dem Sekundärsystem Unterstützung der Datenbank- Partitionierung Tabelle 9: Vergleich der Architektur einer Replikationsumgebung Die Verfahren der SQL- und der Q-Replikation haben hinsichtlich der Anzahl der Primärund Sekundärsysteme gegenüber HADR einen Vorteil: Während HADR auf jeweils ein Primär- und ein Sekundärsystem begrenzt ist, kann die Anzahl bei den beiden anderen Verfahren variiert werden. Die automatische Weiterleitung der Anfragen von einem Primärsystem auf ein Sekundärsystem bei einem geplanten oder ungeplanten Ausfall des Primärsystems ist bei allen drei Verfahren durch das bereits unter HADR vorgestellte Automatic Client Reroute realisierbar. SQL- und Q-Replikation ermöglichen zudem einen lesenden und teilweise einen schreibenden Zugri auf die jeweiligen Zieltabellen auf dem Sekundärsystem, sodass diese nicht nur als reine Replikationsziele genutzt werden können. Mit HADR können derartige Zugrismöglichkeiten auf dem Sekundärsystem nicht realisiert werden, da das Sekundärsystem jegliche externe Verbindungsversuche abblockt. Bei der Unterstützung von Datenbank-Partitionierungen gestaltet sich die Lage ähnlich: HADR bietet hier im Gegensatz zur SQL- und Q-Replikation keine Unterstützung. Bezüglich der Architektur einer Replikationsumgebung und der Flexibilität gibt es folglich gröÿere Unterschiede zwischen HADR und den anderen beiden Verfahren. Die SQL- und QReplikation unterscheiden sich hier nicht voneinander. Dies ändert sich zumindest teilweise in der nächsten Kategorie, der Funktionsweise. 5.4.2 Funktionsweise Unter der Kategorie Funktionsweise steckt zum einen die Frage, welcher Bereich der Da- tenbank durch das jeweilige Verfahren berührt wird, und zum anderen, in welchen Syn- 36 chronisationsmodi die Daten repliziert werden können und welche Datenussrichtungen unterstützt werden. Die Synchronisationsmodi stellen hierbei einen elementaren Faktor dar, der wesentlich zur Entscheidung für ein Verfahren in Abhängigkeit des Szenarios und der Problemstellung beiträgt. Handelt es sich beispielsweise um zeitkritische Änderungsoperationen, so ist es nicht förderlich, wenn das Primärsystem eine Änderungsoperation erst dann als erfolgreich abgeschlossen betrachtet, wenn diese auch auf dem Sekundärsystem repliziert wurde. Im Gegensatz dazu ist es beispielsweise bei Änderungsoperationen, die weniger zeitkritischer Natur sind, durchaus wünschenswert, wenn eine Änderungsoperation erst dann auf dem Primärsystem als erfolgreich abgeschlossen betrachtet wird, wenn sichergestellt ist, dass diese auch auf dem Sekundärsystem repliziert wurde. In diesem Falle kann gewährleistet werden, dass immer ein identischer Datenbestand auf mindestens einem zweiten System vorhanden ist. Die Tabelle 10 zeigt die Vergleichspunkte der Kategorie Funktionsweise, die im Folgenden auch wieder bewertet werden. Merkmal Keine SQL-Replikation Q-Replikation HADR Registrierungspicht für + Explizite Zuordnung von Quell- zu + + + + + + Quell- und Zieleinheiten Zieleinheiten Datenumwandlung durch Replikationsverfahren Direkter Versand der Replikationsdaten von Primär- auf Sekundärsystem Parallele Verarbeitung der Replikationsdaten auf dem Sekundärsystem Synchrone Replikation + Asynchrone Replikation + + + Near-synchrone Replikation + Unidirektionaler Datenuss + + + Bidirektionaler Datenuss + + Peer-to-peer Datenuss + + Tabelle 10: Vergleich der Funktionsweise Der Vorteil von HADR im Vergleich zur SQL- und Q-Replikation liegt in der Tatsache, dass die zu replizierenden Quelleinheiten nicht erst registriert werden müssen. Das erspart am Anfang eine Menge Kongurationsaufwand, wirkt sich aber negativ in anderen Bereichen aus, wie der expliziten Zuordnung von Quell- zu bestimmten Zieleinheiten. Dieses ist wiederum bei der SQL- und Q-Replikation möglich. Hierdurch können Daten nicht nur einfach repliziert, sondern auch in eine andere Tabellenstruktur überführt werden. Bei der Replizierung können die Daten auÿerdem transformiert werden. Beispielsweise können so Daten, die die Kosten für ein bestimmtes Objekt in einer bestimmten Währung charakterisieren, während der Replizierung in eine andere Währung umgerechnet werden. Dies erspart das zusätzliche Umrechnen der Währung auf Anwendungsebene und ermöglicht eine wie in diesem Fall Domänen-spezische Datenaufteilung und -haltung. HADR bietet diese Möglichkeit der Datentransformation im eigentlichen Sinne nicht. 37 Hinsichtlich dem Untersuchungsmerkmal Direkter Versand der Replikationsdaten von Pri- mär- auf Sekundärsystem gibt es Unterschiede zwischen allen drei Verfahren. Während die Informationen über die zu replizierenden Daten bei HADR direkt vom Primär- auf das Sekundärsystem transferiert werden, erfolgt bei der SQL- wie auch der Q-Replikation der Transfer über eine Zwischenspeichertabelle beziehungsweise über das Warteschlangensystem. Ein weiterer Untersuchungspunkt ist die parallele Verarbeitung der Transaktionen auf den jeweiligen Sekundärsystemen. Hier unterscheiden sich die SQL- und die Q-Replikation voneinander. Das Q-Apply-Programm kann durch seine multithread-Fähigkeit die Nachrichten aus der Empfangswarteschlange parallel verarbeiten. Diese Funktionalität hat das ApplyProgramm bei der SQL-Replikation nicht. Das ist im Übrigen auch einer der Gründe, warum die Performance bei der Q-Replikation besser ist im Vergleich zur SQL-Replikation. Es sei hierbei auf den Abschnitt 5.4.5 verwiesen, der sich mit den Performance-Untersu- chungen von Ascho beschäftigt. Wie bereits erwähnt, unterscheiden sich die Verfahren bezüglich der Synchronisationsmodi. HADR bietet hier die gröÿtmögliche Flexibilität, da man zwischen drei Modi, nämlich der synchronen, asynchronen und near-synchronen Replikation, wählen kann. Die SQL- wie auch die Q-Replikation unterstützen hingegen nur die asynchrone Replikation. In punkto Datenussrichtung ähnelt das Bild dem der Synchronisationsmodi. Alle drei Verfahren unterstützen den unidirektionalen Datenuss als Standardrichtung. Die bidirektionale und peer-to-peer Datenussrichtung werden aber nur von der SQL- und Q-Replikation unterstützt. 5.4.3 Replikationsbereich Die dritte Vergleichskategorie bezieht sich vor allem auf den Datenbereich, der durch die Verfahren repliziert werden kann. Für die Auswahl des am besten geeigneten Verfahrens ist der Replikationsbereich folglich ebenso von Bedeutung wie die bisherigen zwei Kategorien. Einen Überblick der Vergleichspunkte gibt die folgende Merkmal Tabelle 11. SQL-Replikation Q-Replikation HADR Geltungsbereich Datenbank + Geltungsbereich Tabellen + + + Geltungsbereich Views + + Spaltenspezische Replikation + + Zeilenspezische Replikation + o INSERT, UPDATE, DELETE + + + CREATE, TRUNCAT, + Metadaten für gespeicherte Proze- + + ALTER, DROP duren Metadaten für benutzerdenierte Funktionen Tabelle 11: Vergleich des Replikationsbereichs Der Geltungsbereich eines Replikationsverfahrens bezeichnet genau denjenigen Bereich, in dem Änderungsoperationen oder andere Aktivitäten durch das Replikationsverfahren er- 38 fasst und auf die Sekundärsysteme repliziert werden. Beispielsweise umfasst HADR als einziges Verfahren den Bereich Datenbank. Die beiden anderen Replikationsverfahren be- schränken sich auf eine niedrigere Granulatsebene des DBMS, dem Bereich der Tabellen oder der Views, wobei die Q-Replikation nur den Bereich der Tabellen abdeckt. Nun können zu replizierende Daten nicht nur nach Tabelle oder View ausgewählt werden, sondern auch in Form von sogenannten Untermengen, d.h. durch eine Spalten- oder Zeilenauswahl. HADR unterstützt hierbei keine der beiden Replikationsformen. Tabellen werden mittels HADR also entweder ganz oder gar nicht repliziert. Für eine spaltenspezische Replikation können sowohl die SQL- als auch die Q-Replikation verwendet werden. Hingegen bietet nur die SQL-Replikation eine vollständige Unterstützung der zeilenspezischen Replikation an. Die Q-Replikation unterstützt die letztgenannte Replikationsform nur teilweise, da es hierbei auch davon abhängt, welche Datenussrichtung gewählt wurde. Keine Unterschiede gibt es hinsichtlich der DML-Statements (INSERT, UPDATE und DELETE). Im Bereich der DDL-Statements (CREATE, ALTER, TRUNCATE, DROP) ist erkennbar, dass nur HADR derartige Operationen repliziert. Gleiches trit auch auf die Replizierung von Metadaten für gespeicherte Prozeduren und für benutzerdenierte Funktionen zu. Anhand dieser Vergleichskategorie wird bereits deutlich, dass HADR im Vergleich zu den anderen beiden Verfahren vollständiger ist im Hinblick auf den Umfang der zu replizierenden Daten; die beiden anderen Verfahren haben aber Vorteile vorzuweisen, wenn es um die Spezialisierung der zu replizierenden Daten geht. 5.4.4 Verwaltung und Pege Die Eignung eines Verfahrens hängt neben der Frage der Architektur, der Funktionsweise oder aber der Frage, welcher Bereich vom jeweiligen Verfahren abgedeckt wird, natürlich auch davon ab, wie groÿ der Aufwand für die Installation der Software, Pege und Verwaltung des Verfahrens ist. Die Verwaltung und Pege Tabelle 12 gibt einen Überblick über die Kategorie und zeigt die jeweiligen Vergleichspunkte, die im Folgenden auch bewertet werden. Merkmal SQL-Replikation Q-Replikation HADR Niedriger Installationsaufwand + + Niedriger Einrichtungsaufwand + Ein- + + + Leistungsüberwachung + + + Assistent-Unterstützung zur richtung Tools zur vorhanden Tabelle 12: Vergleich der Verwaltung und Pege eines Verfahrens Positiv herauszustellen ist bei der SQL-Replikation und HADR der relativ geringe SoftwareInstallationsaufwand. Beide Verfahren sind bereits in einer herkömmlichen DB2-Version integriert und es bedarf keiner weiteren Software-Installationsschritte, wenn bereits eine DB2-Version installiert wurde. Auch das Verfahren der Q-Replikation ist bereits in einer herkömmlichen DB2-Version integriert, allerdings ist hier ein zusätzlicher SoftwareInstallationsschritt für das Warteschlangensystem notwendig. Hierfür kann beispielsweise das Programm WebSphere MQ eingesetzt werden. 39 Der Aufwand zur Einrichtung eines Verfahrens variiert hingegen stark. Bei HADR dauert die Einrichtung nur wenige Minuten, während man bei den anderen beiden Verfahren längere Zeit in Anspruch nehmen muss. Dies ist durch den hohen Zeitaufwand für die Registrierung der Quell- und Zieleinheiten und der Zuordnung dieser untereinander begründet. Die Einrichtung der Replikationsumgebung inklusive der Registrierung und Zuordnung der zu replizierenden Einheiten kann bei allen drei Verfahren über einen Assistenten erfolgen. Das ist für den Benutzer komfortabler als die Einrichtung über die Konsole und bietet gleichzeitig einen schnellen und anschaulichen Überblick über den aktuellen Einrichtungsstatus. Der Nachteil der Assistenten liegt allerdings in deren etwas langsamen Ausführbarkeit, welches wiederum jeweils von der Serverleistung abhängt. Entsprechend des Aufwands, der für die Einrichtung aufgebracht werden muss, gestaltet sich auch der Aufwand für die Pege der jeweiligen Replikationsumgebung. So muss beispielsweise bei der SQL- und Q-Replikation jeweils immer die entsprechende Subskriptionsgruppe angefasst werden, wenn Änderungen am Sekundärsystem erfolgen, sei es ein Austausch der Maschine durch eine andere und damit die Zuweisung auf neue Zieleinheiten. Bei HADR dagegen ist der Aufwand überschaubar: Die neue Maschine ist einfach als neues Sekundärsystem in die HADR-Umgebung aufzunehmen. Ebenfalls für alle drei Verfahren positiv ist das Vorhandensein von Tools, die zur Leistungsüberwachung eingesetzt werden können. Als Beispiele seien hier das der HADR Statusmonitor Replication Center und genannt. 5.4.5 Performance-Untersuchungen von Ascho Nach der Fertigstellung und Veröentlichung des WebSphere Information Integrator 8.2 und dem neuen Replikationsverfahren Q-Replikation im Jahre 2005 wurden durch ein Team unter Führung von John Ascho zahlreiche Performance-Untersuchungen durchgeführt, deren Ergebnisse in diesem Abschnitt kurz angerissen werden sollen. John Ascho ist Leiter der Abteilung WebSphere Information Integrator Performance bei IBM. Der Gesamtbericht über die Untersuchungen kann unter [Asc05] nachgelesen werden. Im Rahmen der Untersuchungen wurden auf einer AIX- und einer z/OS-Umgebung Messungen durchgeführt. In diesem Abschnitt wird auf die Ergebnisse der Erstgenannten zurückgegrien. Sie umfassten unter anderem Angaben zur: • Latenz in Abhängigkeit zur Durchsatzrate, • CPU-Belastung bei der Replikation, • Auswirkung der multithread-Fähigkeit des Q-Apply-Programms auf die Durchsatzrate, • Auswirkung des bidirektionalen und peer-to-peer-Datenusses auf die Performance und • Auswirkung des bidirektionalen und peer-to-peer-Datenusses auf die CPU-Belastung. Aschos Team kam in gegebener Untersuchungsumgebung zu dem Ergebnis, dass die Latenz bei der Q-Replikation erst bei ungefähr 13000 Zeilen pro Sekunde ansteigt, bei der SQL-Replikation hingegen bereits bei etwa 5500 Zeilen pro Sekunde. Dabei ist der Anstieg 40 bei der SQL-Replikation gröÿer als bei der Q-Replikation. Als Grund dafür nannte Ascho die Reduzierung der Logging-Aktivitäten im Zusammenhang mit der Zwischenspeichertabelle bei der SQL-Replikation, die bei der Q-Replikation durch das Warteschlangensystem ersetzt wird. Aber auch die multithread-Fähigkeit sorgt grundlegend für eine Erhöhung der Durchsatzrate bei nahezu gleichbleibender und relativ geringer Latenz. Ein weiterer Grund ist die Verringerung der CPU-Belastung. Hierbei kam das Team um Ascho zu dem Ergebnis, dass die CPU-Kosten bei der Q-Replikation auf dem Primärsystem pro Zeilenreplizierung um etwa zwei Drittel geringer sind als bei SQL-Replikation. Die CPU-Kosten für eine Zeilenreplizierung auf dem Sekundärystem sind bei der Q-Replikation hingegen etwa ein Drittel teurer als bei der SQL-Replikation, da durch die Kommunikation mit der Empfangswarteschlange und dem Umwandeln der Nachricht in das SQL-Format mehr Aufwand betrieben wird. In der Gesamtbetrachtung ergibt sich eine geringe CPU-Kostengröÿe bei der Q-Replikation, die um etwa ein Drittel kleiner ist als die bei der SQL-Replikation. 41 6 Praktische Umsetzung einer Hochverfügbarkeitslösung mittels eines Replikationsverfahrens Das vorliegende Kapitel erklärt den Entscheidungsprozess für die Auswahl eines geeigneten Replikationsverfahrens und gibt Aufschluss darüber, wie das ausgewählte Verfahren konguriert, gewartet und gepegt wird. Das Kapitel schlieÿt mit einem Bericht über die Erprobung des Verfahrens auf einem Testsystem. 6.1 Anforderungsanalyse und Auswahl eines Verfahrens Für die bereits im zweiten Kapitel kurz erläuterte Digitale Bibliothek namens UrMEL betreibt die Thüringer Universitäts- und Landesbibliothek in Zusammenarbeit mit dem Rechenzentrum der Friedrich-Schiller-Universität Jena einen Datenbankserver mit dem DBMS IBM DB2 LUW in Version 9. Um die Handhabung der Datensicherung im Fall eines Ausfalls des Datenbankservers zu optimieren und insbesondere die Ausfallzeit des Primärsystems möglichst gering zu halten, wurden im Rahmen dieser Studienarbeit drei verschiedene Replikationsverfahren betrachtet. Das Ziel dieser Studienarbeit liegt unter anderem in dem Aunden eines geeigneten Replikationsverfahrens. Die im konkreten Beispiel vorliegende Replikationsumgebung weist eine Vielzahl an Anforderungen auf, die bei der Auswahl des gesuchten Verfahrens von zentraler Bedeutung sind und das Grundgerüst der Analyse zur Auswahl eines geeigneten Verfahrens bilden. Das Grundgerüst setzt sich dabei aus den folgenden Anforderungskategorien zusammen, die im Folgenden auch erklärt werden: Die • Installation der Software, • Architektur der Replikationsumgebung, • Einrichtung und Konguration des Verfahrens, • Replikationsbereich des Verfahrens, • Verwendbarkeit des Sekundärsystems, • Replikationssicherheit, • Performance des Replikationsprozesses, • Ausfalldauer des Primärsystems sowie • Lizenzierungskosten. Installation der Software sollte möglichst ohne gröÿeren Aufwand umsetzbar sein. Durch die Nutzung des DBMS IBM DB2 LUW erfolgt hier bereits eine Einschränkung für die in Frage kommenden Verfahren. Das Verfahren sollte deshalb, falls es nicht aus der Produktfamilie von DB2 stammt, kompatibel zu diesem sein, da ein Wechsel des DBMS nicht vorgesehen ist. Die installierte Version sollte durch das Verfahren unterstützt werden. Die Architektur der Replikationsumgebung umfasst zwei Datenbankserver. Diese sind ein Primär- und ein Sekundärsystem, welches als Replikationsziel genutzt werden soll. Es ist im Hinblick auf die Architektur demzufolge nicht relevant, ob das Verfahren nur ein 42 oder mehrere Sekundärsysteme unterstützt. Das Verfahren sollte aber in jedem Fall die Lokations-unabhängige Stationierung der Datenbankserver unterstützen, da nur so eine wirkliche Hochverfügbarkeitslösung mittelfristig erreicht werden kann. Ein weiterer wichtiger Punkt ist das Existieren eines sogenannten Connection Pools. Unter einem Connection Pool versteht man ein Verwaltungssystem für Datenbankverbindungen. Eine zentrale Aufgabe eines Connection Pools besteht in dem Vorhalten und Parken der Verbindungen, falls sich diese nicht in Verwendung benden. Sie werden bei Bedarf aktiviert, so dass nicht ständig neue Datenbankverbindungen hergestellt werden. Bei der Nutzung eines Anwendungsservers ist das Verwalten von Verbindungen zur Datenbank recht teuer, weswegen man derartige Verwaltungssysteme zu Rate zieht. Das Replikationsverfahren sollte daher in jedem Fall die Nutzung eines Connection Pools unterstützen. Einrichtung und Konguration des Verfahrens. Komplexe Einrichtungs- und Kongurationsvorgänge sind rein aus ZeitEine weitere wichtige Kategorie ist der Aufwand für die gründen zu vermeiden. Das Verfahren sollte mit möglichst wenig Zeitaufwand einzurichten sein und auch in Fehlerfällen möglichst zeitnah die eigene Funktionalität wieder aufnehmen können. Auch in Bezug auf den Replikationsbereich sollte das Verfahren einen groÿen Umfang an Operationen replizieren können. Es wird hier Wert auf die Gesamtheit gelegt und nicht auf die Spezialisierung auf einzelne Bereiche. Je vollständiger das Verfahren die Operationen repliziert, desto besser ist das Verfahren für das konkrete Beispiel. Verwendbarkeit des Sekundärsystems. Grundsätzlich spielt es keine zentrale Rolle, ob das Sekundärsystem für AnfraEine etwas geringer priorisierte Kategorie ist die der gen seitens der Anwendungen zur Verfügung steht. Es wird aber auch nicht abgelehnt. Die Verfügbarkeit des Sekundärsystems für derartige Anfragen würde den Vorteil mit sich bringen, dass das Replikationsverfahren gleichzeitig auch zur Lastreduktion beitragen könnte, indem derartige Anfragen auf beide Datenbankserver verteilt werden und das Replikationsverfahren für den Austausch der jeweiligen Datenänderungen sorgt. Gleichzeitig führt diese Möglichkeit aber auch zu einer Reihe von Koniktszenarien, die hierbei auftreten können, falls auf dem Sekundärsystem Schreibzugrie erfolgen. Aus diesem Grund ist die Verwendbarkeit des Sekundärsystems für derartige Anfragen keine Bedingung, die das Replikationsverfahren zwingend erfüllen muss. In diesem Zusammenhang steht auch die Kategorie der Replikationssicherheit. Die An- forderung an das Verfahren sieht hierbei vor, dass gewährleistet sein sollte, dass Transaktionen, die auf dem Primärsystem erfolgreich verarbeitet wurden, auch auf dem Sekundärsystem erfolgreich verarbeitet werden und so im Falle des Ausfalls des Primärsystems die Datenänderungen auf dem Sekundärsystem vorhanden sind. In gleichem Maÿe soll diese Anforderung aber nicht dazu führen, dass die Performance der Anwendungen unter den Replikationsverfahren wesentlich leidet. Das Verfahren muss demzufolge im Hinblick auf diese Kategorie einen Kompromiss zwischen der Replikationssicherheit und der Verschlechterung der Performance nden. Ein Grund für die Realisierung eines Replikationsverfahrens im konkreten Beispiel ist der Umstand, dass bisher die Datensicherung durch Online-Backups und das Aufspielen auf ein Sekundärsystems durch nächtliche Sicherungen erfolgte. Mit dieser Vorgehensweise ist der Datenbestand auf dem Sekundärsystem immer älter (teils deutlich älter) als auf dem Primärsystem, was im Falle eines Totalausfalls des Primärsystems zu Datenverlust führen würde. Eine Anforderung an das Verfahren ist also die Reduzierung der Ausfallzeit auf ein akzeptables Maÿ. Das bedeutet, dass das Sekundärsystem jederzeit über einen möglichst identischen Datenbestand verfügen und die Inbetriebnahme des Sekundärsystems im Falle eines Totalausfalls des Primärsystems nur eine sehr geringe Zeit in Anspruch nehmen sollte. 43 Die letzte Kategorie ist die der Lizenzierungskosten. Das Verfahren sollte nach Möglich- keit keine weiteren Lizenzierungskosten verursachen und bereits im Produktpaket enthalten sein. Auf Grundlage der soeben erklärten Anforderungskategorien wurden den in dieser Studienarbeit betrachteten Replikationsverfahren sogenannte Eignungsnoten zugeordnet. Eig- nungsnoten haben die Aufgabe, die Eignung eines Verfahrens in Abhängigkeit der entsprechenden Anforderungskategorie zu einem konkreten Beispiel in Form von Skalenwerten von 1 bis 3 anzugeben. Die Eignungsnote 1 entspricht hierbei der bestmöglichen Eignung, die Eignungsnote 3 entspricht der schlechtmöglichsten Eignung und die Eignungsnote 2 entspricht dem Mittelwert, d.h. das Verfahren eignet sich nur bedingt in Bezug auf die Anforderungskategorie. Die Zuordnung der Eignungsnoten für die einzelnen Anforderungskategorien und Replikationsverfahren ist in Anforderungskategorie Tabelle 13 dargestellt. SQL-Replikation Q-Replikation HADR Installation der Software 1 2 1 Architektur der Replikationsumge- 1 1 1 2 2 1 Replikationsbereich des Verfahrens 2 2 1 Verwendbarkeit 1 1 3 Replikationssicherheit 2 2 1 Performance des Replikationsprozes- 2 1 1 Ausfalldauer des Primärsystems 2 2 1 Lizenzierungskosten 1 1 1 bung Einrichtung und Konguration des Verfahrens des Sekundärsys- tems ses Tabelle 13: Eignungsnoten der Replikationsverfahren Auf Grundlage der Auswertung dieser Eignungsnoten wurde für das konkrete vorliegende Beispiel das Replikationsverfahren HADR ausgewählt. Die Wahl von HADR lässt sich hierbei wie folgt begründen: Die Vorteile von HADR im Vergleich zu den anderen beiden Verfahren nden sich vor allem in den Anforderungskategorien des Replikationsbereiches, der Replikationssicherheit und insbesondere der Ausfalldauer des Primärsystems. Der Geltungsbereich von HADR liegt auf der Ebene der Datenbank, weshalb der Replikationsbereich vom Umfang her am gröÿten ist. Die beiden anderen Verfahren haben in dieser Anforderungskategorie eher Vorteile, wenn es um die Spezialisierung geht, d.h. wenn nur eine spezielle Untermenge von Daten für die Replizierung vorgesehen ist. Aufgrund der Möglichkeit der synchronen Replizierung von Daten bei HADR genieÿt das Verfahren auch in der Kategorie der Replikationssicherheit Vorteile gegenüber der SQL- und Q-Replikation. Letztgenannte Verfahren unterstützen nur die asynchrone Replikation. Nahezu dominierenden Charakter erfährt HADR in der Anforderungskategorie der Ausfalldauer des Primärsystems. Durch die Möglichkeit des zeitnahen Umschaltens des bisherigen Sekundärsystems zum neuen Primärsystem verkürzt sich die Ausfallzeit auf ein sehr kleines Zeitintervall, da zusätzliche manuelle Eingrie neben dem eigentlichen Umschalten nicht notwendig sind. Innerhalb der HADR-Umgebung steht somit ein funktionsfähiges System zur Verfügung, welches im Ausfallszenario die Rolle des Primärsystems sofort übernehmen kann. 44 6.2 Konguration des HADR-Systems Voraussetzungen Bevor mit der Konguration des HADR-Systems begonnen werden kann, müssen einige Punkte auf ihre Erfülltheit hin überprüft werden. So ist eine Grundvoraussetzung für das Aufsetzen eines HADR-Systems die vollständige Installation des DBMS LUW IBM DB2 auf dem Primär- und Sekundärsystem. Auf die Beschreibung der Grundinstallation wird hierbei allerdings verzichtet, da dies den Umfang der Studienarbeit sprengen würde. Nützliche Hinweise sind zum Beispiel unter [OGT07] nachzulesen. Auch ist die HADRFunktionalität zwar bereits ab der Express-C Edition im Produktpaket enthalten, aber erst ab der Express Edition ohne zusätzliche Lizenzierung nutzbar. In allen anderen Fällen muss sie also optional zum Lizenzpaket hinzu erworben werden. Die Betriebssysteme und deren aktuelle Version auf dem Primär- und Sekundärsystem sollten übereinstimmen. Die Versionen können hierbei für eine kurze Zeit unterschiedlich sein, insbesondere im Falle des Einspielens von System-Updates. Die eingesetzte DB2Version plus Level sollte auf beiden Systemen ebenso identisch sein. Im Falle des Einspielens von Upgrades können sich aber auch hier die Versionen kurzzeitig unterscheiden. Auch sollte auf beiden Systemen entweder eine 32Bit- oder eine 64Bit-Software eingesetzt werden. Es wird darüber hinaus sehr empfohlen, dass die beiden Systeme eine gleichartige Architektur einsetzen und im Hinblick auf die Gröÿe des Arbeitsspeichers ähnliche Werte aufweisen. Bei der Wahl der Netzwerkstruktur sollte darauf geachtet werden, dass die hergestellte TCP/IP-Verbindung über ein leistungsstarkes Netzwerk führt, damit die TCP/IPVerbindung nicht den Charakter eines Flaschenhalses annimmt und damit im Worst-Case zu einer Blockierung des HADR-Systems führt. Auf den Einsatz einer Firewall sollte weitestgehend verzichtet werden. Im Hinblick auf die Kongurationsparameter des DBMS und der Datenbanken sei darauf hingewiesen, dass hier eine identische Wertbelegung seitens IBM empfohlen wird. Auch die Gröÿe des Puers sollte auf beiden Systemen identisch sein. Die Namen der im HADR-System operierenden Datenbanken müssen ebenso übereinstimmen. Daraus folgt, dass die Datenbanken in unterschiedlichen Instanzen angelegt sein müssen. Zudem müssen die Tabellenräume strukturgleich sein; gemeint ist hierbei der Typ und die Gröÿe des Tabellenraums, die Pfadangabe der Container wie auch die Gröÿe und der Dateityp der selbigen. Auÿerdem sollte der für Log-Dateien vorgesehene Speicherplatz auf beiden Systemen in der Gröÿe gleich sein. Eine Umgebung mit partitionierten Datenbanken wird von HADR nicht unterstützt. Obige Voraussetzungen sind von elementarer Natur für das reibungslose Funktionieren der HADR-Umgebung und einer möglichst hohen Performance. Das Sekundärsystem muss jederzeit in der Lage sein, die vom Primärsystem generierte Transaktionslast zu verarbeiten. Im Falle eines Wechsels des Sekundär- zu einem Primärsystem muss es zudem in der Lage sein, die Anfragelast zu bewerkstelligen. Da auch Änderungen an den Systemeinstellungen, wie beispielsweise das Modizieren des Buerpools, auf das Sekundärsystem repliziert werden, ist eine Gleichheit beispielsweise der Speichergröÿen notwendig. 45 Konguration Nachdem die Voraussetzungen geprüft wurden und die Erfülltheit dieser festgestellt wurde, kann mit der eigentlichen Konguration des HADR-Systems begonnen werden. LUW IBM DB2 bietet hierbei zwei verschiedene Wege an, das System entsprechend zu kongurieren: • Konguration über den graschen Assistenten der Steuerzentrale • Konguration über die Kommandozeile. oder Beide Wege haben ihre Vor- und Nachteile. Der grasche Assistent der Steuerzentrale eignet sich vor allem für Einsteiger der HADR-Thematik und ermöglicht einen relativ guten Überblick über die bereits ausgeführten und noch ausstehenden Kongurationsschritte. Auch erläutern zahlreiche Hinweistexte, welche Aktionen im Detail und warum diese ausgeführt werden. Ein Nachteil des graschen Assistenten liegt zum einen darin, dass dieser als Prozess des Instanzeneigentümers auf dem operierenden System ausgeführt wird. Aus diesem Grund ist es erforderlich, dass der Instanzeneigentümer die Rechte für die Manipulation der Datei /etc/services besitzt, damit die entsprechenden Dienste und Ports eingetragen bzw. geändert werden können, die für die reibungslose Kommunikation der beiden Systeme notwendig sind. Andernfalls können diese elementaren Schritte nicht durch den Assistenten durchgeführt werden und es bedarf eines manuellen Eingris des Administrators oder eines Nutzers, der die entsprechenden Befugnisse hat. Die Dienstnamen und Ports müssen dabei auf beiden Systemen eingetragen werden. Ein weiterer Nachteil liegt in der Behäbigkeit der Steuerzentrale. Der grasche Assistent macht im Allgemeinen einen eher langsamen Eindruck und wirkt in seiner Ausführbarkeit sehr träge. Dies kann aber von System zu System recht unterschiedlich sein. Dieser Nachteil kann durch die Nutzung der Kommandozeile umgangen werden, die sich jedoch weniger einsteigerfreundlich gestaltet. Konguration über den graschen Assistent der Steuerzentrale Im Folgenden wird zunächst die Konguration mittels des graschen Assistenten der Steuerzentrale betrachtet. Dieser wird über die Steuerzentrale mit der Aktivierung des Kontextmenüs der zu replizierenden Datenbank gestartet, in dem man in diesem den Eintrag High Availability Disaster Recovery markiert und im darauf erscheinenden Untermenü den Eintrag Set Up aktiviert. Der Assistent durchläuft daraufhin die folgenden zehn Schritte. Nach einer einführenden Information des Nutzers im Schritt Modus. ersten Schritt, erfolgt im zweiten die Bestätigung des gewählten Primärsystems und die Einstellung des Logging- IBM DB2 LUW archival logging circular logging (Umlaufprotokollierung). Letztgenanntes wird bietet zwei verschiedene Logging-Verfahren an: (Archivprotokollierung) und als Standardverfahren bei der Anlegung von Datenbanken eingesetzt. Hierbei wird ein Ring von aktiven Log-Dateien verwendet, welche fortlaufend beschrieben werden, um eine Recovery nach einem Systemausfall oder einem Transaktionsfehler durchzuführen. Änderungsoperationen, die nach der Erstellung eines Backups durchgeführt wurden, sind bei diesem Verfahren im Falle eines Ausfalls nicht wiederherstellbar. Zudem kann ein Backup der Datenbank nur erstellt werden, wenn sich diese im Im Gegensatz dazu steht das archival logging. Oine -Modus bendet. Bei diesem Verfahren werden permanent neue Log-Dateien erzeugt, wodurch wiederum ein rollforward -Modus der Datenbank mög- lich ist und damit die durch HADR geforderte Bedingung erfüllt wird. Bei einem Ausfall 46 der Datenbank können so die Änderungsoperationen bis zu einem beliebigen Zeitpunkt nachgefahren werden. Insbesondere können im Unterschied zum circular logging auch die Änderungsoperationen nach dem Erstellungszeitpunkt des Backups nachgefahren werden. Weitergehende Informationen zu den beiden Verfahren sind unter [IBM06a] nachlesbar. Ist statt des geforderten archival logging das circular logging aktiviert, bedarf es eines Zwiarchival logging wird man im zweiten Unterschritt schenschrittes: Nach der Auswahl des zur Bearbeitung der archivierten Logs befragt. Hier hat man die Möglichkeit zwischen drei manuelle Archivierung der Log-Dateien, die Archivierung mittels einer User-Exit-Routine und die automatische Archivierung durch DB2. Nach dieser Auswahl folgen die Festlegung der Verfahren zur Archivierung der Log-Dateien zu wählen. Diese sind im Einzelnen die Anzahl der primären und sekundären Log-Dateien und die Gröÿe der selbigen. Im nächsten Unterschritt erfolgt dann die Angabe des Speicherortes der Log-Dateien. Zudem kann man die zusätzliche Spiegelung der Log-Dateien aktivieren, sodass diese zusätzlich gesichert werden. Die Umstellung des Logging-Verfahrens vom circular logging zum archival logging erfordert die Erstellung eines Backups der Datenbank. Aus diesem Grund muss in einem weiteren Unterschritt der Speicherort für das Backup angegeben werden. Darüber hinaus ist es möglich, weitere optionale Parameter für das Backup einzustellen. Hierunter zählen unter anderem die Aktivierung der Backup-Komprimierung und die Höhe der Parallelität. Nach der erfolgreichen Umstellung des Logging-Verfahrens auf das sich im archival logging schlieÿt dritten Schritt nun die Auswahl des Sekundärsystems an. Hierbei wählt man das entsprechende Sekundärsystem und die dazugehörige Instanz auf diesem aus. Ist auf dem Sekundärsystem noch keine Instanz angelegt, kann man diese mit Hilfe des Assistenten nebenläug erzeugen. Wurde die bereits vorhandene oder erstellte Instanz selektiert, hat man nun erneut die Wahl zwischen verschiedenen Möglichkeiten, wie die Datenbank auf dem Sekundärsystem initialisiert werden soll. Eine Möglichkeit ist dabei die Initialisierung der Sekundärdatenbank durch die Auswahl eines Backups der Primärdatenbank. Hierbei wählt man aus einer Liste von bereits in der Vergangenheit erstellten Backup das entsprechende Backup aus. Falls noch kein Backup vorhanden ist, kann dies mit Hilfe des Assistenten ebenfalls erzeugt werden. Diese Möglichkeit entspricht der Standardauswahl und wird seitens IBM für einen problemlosen Einstand in die HADR-Thematik empfohlen. Eine weitere Möglichkeit ist die Initialisierung der Sekundärdatenbank durch die Nutzung einer auf dem Sekundärsystem bereits vorhandenen Datenbank. Der vierte Schritt entspricht bei der Auswahl der eben beschriebenen Möglichkeit, die Sekundärdatenbank durch ein Backup zu initialisieren, der Auswahl und Angabe des entsprechenden Backups. Im darauf folgenden fünften Schritt wird man nun dazu aufgefor- dert, den Quellort der Backup-Datei anzugeben oder ob die ausgewählte Backup-Datei auf das Sekundärsystem transferiert werden soll. Im sechsten Schritt können zusätzlich Objekte angegeben werden, die nicht im Backup enthalten sind, wie beispielsweise benutzerdenierte Funktionen oder gespeicherte Prozeduren, die aber dennoch auf das Sekundärsystem transferiert werden sollen. Die Festlegung der für den Aufbau der TCP/IP-Verbindung notwendigen Parameter erfolgt im siebten Schritt. Hierbei sei darauf hingewiesen, dass, falls der Instanzeigentümer /etc/services besitzt, die Dienstnamen /etc/services auf beiden Systemen eingetragen nicht die entsprechenden Schreibrechte für die Datei inklusive der Ports manuell in die Datei werden müssen. 47 Der Vorteil der Nutzung von ACR im HADR-System liegt in der automatischen Umleitung der Anfragen der Anwendungen an das Sekundärsystem im Falle eines Ausfalls des Pri- achten Schritt die entsprechenden Paramater eingestellt. Die im Abschnitt 5.3.2 erwähnten Synchronisationsmodi können im neunten Schritt märsystems. Hierzu werden im ausgewählt werden. Darüber hinaus kann konguriert werden, nach wie vielen Sekunden die Verbindung als fehlerhaft gewertet wird. zehnte Schritt zeigt abschlieÿend eine Zusammenfassung der ausgewählten Einstel- Der lungen. Nach einer Prüfung dieser kann man entweder zu den einzelnen Schritten zurück navigieren, um entsprechende Änderungen vorzunehmen, oder aber die Konguration abschlieÿen und die Änderungen durch den Assistenten ausführen lassen. Hat man sich für Letzteres entschieden, erscheint eine Übersichtstabelle, auf der man die aktuellen Aktivitäten und den Status derer nachvollziehen kann. Nachdem alle Aktionen erfolgreich ausgeführt wurden, kann überprüft werden, ob HADR tatsächlich gestartet wurde und die vorgesehene Funktionalität ausführt. Hierfür aktiviert man wie bereits am Anfang der High Availability Disaster Recovery aus und aktiviert im erscheinenden Untermenü den Eintrag verwalten beziehungsweise manage. Es önet sich daraufhin der HADR-Statusmonitor, der den Konguration das Kontextmenü der Primärdatenbank, wählt den Eintrag scheinbar aktuellen Status und die laufenden Aktivitäten des HADR-Systems anzeigt. Konguration über die Kommandozeile Die entsprechende Konguration per Kommandozeile erfolgt ebenfalls in zehn Schritten. Um eine optimale Vorgehensweise zu ermöglichen, ist es ratsam, sich mittels zweier Terminalfenster auf dem Primär- und Sekundärsystem zeitgleich anzumelden, um die entsprechenden Befehle relativ komfortabel absenden zu können. Im ersten Schritt werden die Kongurationsparameter der Datenbank überprüft und notfalls auf die geforderten Werte gesetzt. Gefordert ist an dieser Stelle das bereits erwähnte archival logging. Es wird aktiviert, indem der Parameter LOGRETAIN auf recovery gesetzt wird (siehe Listing 2). Zudem ist es erforderlich, dem Parameter LOGINDEXBUILD den Wert On zuzuweisen, damit Operationen wie die Index-Erstellung, Index-Neuerstellung und Reorganisation protokolliert werden (siehe db2 Listing 3). Listing 2: Archival Logging aktivieren update database configuration f o r DATABASE using logretain recovery db2 update Listing 3: Protokollierung erweitern mit LOGINDEXBUILD database logindexbuild Im on configuration f o r DATABASE using zweiten Schritt erfolgt die Erstellung eines Backups (siehe Listing 4) und die Transfe- rierung des erstellten Backups auf das Sekundärsystem. Es ist hierbei sehr praktisch, wenn man den genauen Zeitpunkt der Backup-Erstellung erfasst, da man diesen Zeitpunkt bei der Einspielung des Backups auf dem Sekundärsystem benötigt. Nach der Erstellung des Backups wird dieser als TIMESTAMP bezeichnete Zeitpunkt als formatierter String angezeigt. Die Formatierung entspricht dabei der Form YYYYMMDDHHMMSS, wobei YYYY für das Jahr, MM für die numerische Monatsangabe, DD für die numerische Tagesangabe, HH für Stunden, MM für Minuten und SS für Sekunden steht. 48 Listing 4: Backup einer Datenbank erstellen db2 backup d a t a b a s e DATABASE t o / p a t h / t o / backup / d i r e c t o r y Nachdem die erstellte Backup-Datei auf das Sekundärsystem transferiert wurde, kann im dritten Schritt diese nun auf dem Sekundärsystem eingespielt werden. Der entsprechende Befehl ist dem Listing 5 zu entnehmen. Listing 5: Einspielen eines Backups db2 restore taken d a t a b a s e DATABASE at TIMESTAMP Mit der Option replace replace history le from / p a t h / t o / backup / f i l e / s o u r c e history file wird die Datei des Recovery-Protokolls auf dem Se- kundärsystem mit der Datei des Recovery-Protokolls aus dem Backup ersetzt. Zu jeder Datenbank wird eine derartige Datei erstellt. Sie wird automatisch aktualisiert, wenn entsprechende Operationen durchgeführt werden. Hierunter zählen unter anderem das Sichern, Wiederherstellen oder Manipulieren einer Datenbank oder von Tabellenbereichen oder das Reorganisieren einer Tabelle. Die Einträge dieser Datei lassen sich mit dem Befehl history list anzeigen. Bei jeder Erstellung eines Backups wird eine Kopie dieser Recovery- Protokolldatei erstellt und dem Backup beigefügt. Für weiterführende Informationen über die Datei des Recovery-Protokolls sei auf [IBM06a] verwiesen. Zu diesem Zeitpunkt benden sich nun identische Datenbanken auf dem Primär- und Sekundärsystem. Im folgenden die Nutzung von ACR vierten Schritt werden die entsprechenden Parameter für gesetzt. Hierzu ist es erforderlich, dass sowohl auf dem Primär- als auch auf dem Sekundärsystem der schieht durch den Befehl aus 7 auf dem Sekundärsystem. alternate server -Parameter modiziert wird. Dies ge- Listing 6 auf dem Primärsystem und den Befehl aus Listing Listing 6: Modifzieren von alternate server auf dem Primärsystem db2 update alternate server for d a t a b a s e DATABASE using hostname HOSTNAME_SECONDARY p o r t PORTNUMBER Listing 7: Modifzieren von alternate server auf dem Sekundärsystem db2 update alternate server for d a t a b a s e DATABASE using hostname HOSTNAME_PRIMARY p o r t PORTNUMBER Anschlieÿend müssen im fünften und sechsten Schritt noch die Dienste und die dazu- /etc/services auf beiden Systemen manuell eingetraIBM die Dienstnamen DB2 HADR 1 und DB2 HADR 2 mit den dazugehörigen Portnummern 55001 und 55002 vorgeschlagen. gehörigen Portnummern in die Datei gen werden. Als Standard werden hier seitens Die Einstellung der Kongurationsparameter auf dem Primärsystem erfolgt im Schritt. Listing 8 Wie dem siebten zu entnehmen ist, werden hier die HADR-Parameter ge- setzt und eine Verbindung zur Primärdatenbank aufgebaut. Im Anschluss daran wird die Primärdatenbank in den sogenannten quiesce -Modus gesetzt. Solange eine Datenbank in diesem Modus ist, können nur privilegierte Nutzer wie beispielsweise der Datenbankadministrator auf die Datenbank zugreifen. Die Option force connections bedeutet, dass alle sonstigen Verbindungen ohne Rückfrage zurückgesetzt werden. Im Anschluss daran wird der quiesce -Modus wieder aufgehoben und die eigens hergestellte Verbindung zur Daten- bank zurückgesetzt. 49 Listing 8: Modifzieren der HADR-Parameter auf dem Primärsystem db2 update db cfg f o r DATABASE HOSTNAME_PRIMARY db2 db2 update update db cfg f o r DATABASE db cfg f o r DATABASE HOSTNAME_SECONDARY db2 db2 update update db cfg f o r DATABASE db cfg f o r DATABASE using using using using using hadr_local_host h a d r _ l o c a l _ s v c DB2_HADR_1 hadr_remote_host h a d r _ r e m o t e _ s v c DB2_HADR_2 hadr_remote_inst INSTANCE_SECONDARY db2 update db c f g f o r DATABASE using update db c f g f o r DATABASE using connect t o DATABASE q u i e s c e d a t a b a s e immediate f o r c e db2 unquiesce db2 db2 db2 db2 Im connect hadr_syncmode SYNC hadr_timeout 3 connections database reset achten Schritt werden die HADR-Parameter auf dem Sekundärsystem gesetzt. Die Listing 9 zu entnehmen. entsprechenden Befehle sind dem Listing 9: Modifzieren der HADR-Parameter auf dem Sekundärsystem db2 update db cfg f o r DATABASE HOSTNAME_SECONDARY db2 db2 update update db cfg f o r DATABASE db cfg f o r DATABASE HOSTNAME_PRIMARY db2 db2 update update db cfg f o r DATABASE db cfg f o r DATABASE INSTANCE_PRIMARY db2 db2 update update db cfg f o r DATABASE db cfg f o r DATABASE using using using using using using using hadr_local_host h a d r _ l o c a l _ s v c DB2_HADR_2 hadr_remote_host h a d r _ r e m o t e _ s v c DB2_HADR_1 hadr_remote_inst hadr_syncmode SYNC hadr_timeout 3 Die Konguration des Primär- und Sekundärsystems ist damit abgeschlossen. Im neunten zehnten Schritt kann nun die HADR-Funktionalität gestartet werden. Wichtig ist Listing 10) und im Anschluss daran das Primärsystem (siehe Listing 11) gestartet. und hierbei die Startreihenfolge. Zuerst wird das Sekundärsystem (siehe Listing 10: Starten von HADR auf dem Sekundärsystem db2 deactivate db2 start hadr d a t a b a s e DATABASE on d a t a b a s e DATABASE as standby Listing 11: Starten von HADR auf dem Primärsystem db2 deactivate db2 start hadr d a t a b a s e DATABASE on d a t a b a s e DATABASE as primary Eine weitere Möglichkeit, das HADR-System zu starten, liegt in der bereits erwähnten Erweiterungsklausel FORCE. Bei Nutzung des Befehls aus Listing 12 wird das Primärsystem sofort gestartet, auch wenn keine Verbindung zum Sekundärsystem hergestellt wurde. Das bringt Vorteile, wie sie bereits in Abschnitt 5.3.1 erläutert wurden, aber auch Nachteile 50 mit sich. Einer dieser Nachteile liegt in der Ignorierung des autorestart -Parameters. Die- ser Parameter regelt das Verhalten des DBMS im Falle eines abnormalen Beendens der Datenbank. Ist der autorestart -Parameter auf on gesetzt, startet das DBMS bei Bedarf automatisch das Dienstprogramm zum Neustarten der Datenbank. Dieses Verhalten ist insbesondere dann von Vorteil, wenn eine Recovery nach einem Systemabsturz durchgeführt werden muss. Andernfalls muss die Datenbank durch einen expliziten Aufruf des Dienstprogramms durch die jeweilige Anwendung oder des Recovery-Programms neugestartet werden. Listing 12: Starten von HADR mit der Erweiterungsklausel FORCE db2 deactivate db2 start hadr d a t a b a s e DATABASE on d a t a b a s e DATABASE as primary by force Eine abschlieÿende Übersicht über die erwähnten Kongurationsparameter ist in der folgenden Tabelle 14 zu nden. Parametername Erklärung logretain Gibt an, ob Protokolle beibehalten werden sollen oder nicht. Der Parameter muss auf recovery gesetzt sein, wenn archival logging aktiviert sein soll. logindexbuild Gibt an, ob Operationen wie die Index-Erstellung, Index- Neuerstellung und Reorganisation protokolliert werden oder nicht. hostname port Gibt den Hostnamen und den zugehörigen Port an. hadr local host Gibt den Namen oder die IP-Adresse des lokalen Hosts an. Dieser wird für die Kommunikation der beiden Systeme benötigt. hadr local svc Gibt den Dienstnamen oder die zugehörige Portnummer an, für die entsprechende Verbindungsanfragen auf dem lokalen Host akzeptiert werden. hadr remote host Gibt den Namen oder die IP-Adresse des fernen (remote) Hosts an. Dieser wird für die Kommunikation der beiden Systeme benötigt. hadr remote svc Gibt den Dienstnamen oder die zugehörige Portnummer an, für die entsprechende Verbindungsanfragen auf dem fernen (remote) Host akzeptiert werden. hadr remote inst Gibt den Namen der Instanz auf dem fernen (remote) Host an. hadr syncmode Gibt den aktivierten Synchronisationsmodus an. Dieser Parameter kann die Werte SYNC, NEARSYNC oder ASYNC annehmen. hadr timeout Gibt die Wartezeit in Sekunden an, bis eine Anfrage als fehlerhaft gewertet wird. Tabelle 14: Übersicht über die Kongurationsparameter 6.3 Monitoring, Verwaltung und Pege Es gibt verschiedene Möglichkeiten, den aktuellen Status der HADR-Umgebung abzurufen, das HADR-System zu verwalten oder zu pegen. Der Abschnitt gibt einen kurzen Einblick in die folgenden Methoden zum Monitoring, zur Verwaltung und Pege: • Snapshot, 51 • db2pd, • HADR-Statusmonitor der Steuerzentrale, • administrative Views und Tabellen sowie • db2diag. Hinter dem Begri wird. Dieser ist in db2 get Snapshot verbirgt sich ein Befehl, der auf der Kommandozeile abgesetzt Listing 13 dargestellt. Listing 13: Snapshot-Befehl snapshot for database on DATABASE Die daraufhin dargestellten Informationen entsprechen den aktuellen Statusinformationen der HADR-Umgebung. So wird angezeigt, welche Rolle das System inne hat, auf welchem der Snapshot-Befehl abgesetzt wurde (also ob Primär- oder Sekundärsystem). Auch der aktuelle Status, der gewählte Synchronisationsmodus, der aktuelle Verbindungsstatus und die Anzahl der verlorenen Heartbeats werden angezeigt wie auch Informationen über festgeschriebene Kongurationsparameter, die in Abschnitt 6.2 bereits erklärt wurden. Zudem ndet man Informationen über die aktuelle Protokolldatei, die aktuelle Protokollseite und die aktuelle Log Sequence Number (LSN) auf dem Primär- und Sekundärsystem. Letztlich wird der derzeit vorhandene Dierenzwert zwischen dem Sekundär- und dem Primärsystem in Bytes angezeigt. Dieser Wert gibt an, um wie viel Bytes das Sekundär- hinter dem Primärsystem zurückliegt. Im optimalen Fall ist dieser Wert gleich Null. Den gleichen Informationsbestand zeigt in anders aufbereiteter Form der Befehl aus ting 14. Listing 14: db2pd −d DATABASE Lis- db2pd -Befehl −h a d r Der HADR-Statusmonitor der Steuerzentrale stellt den gleichen Informationsbestand wie die zwei vorhergehenden Befehle in grasch aufbereiteter Form zur Verfügung. Zudem ermöglicht der Statusmonitor das Starten und Stoppen der HADR-Funktionalität auf dem jeweiligen System. Auch das Ausführen eines geplanten oder erzwungenen Takeovers ist (per Klick) möglich. Durch das Einstellen der Aktualisierungsrate des Statusmonitors kann der Prozess der Datenreplizierung verfolgt werden. Der Nachteil des HADR-Statusmonitors liegt wie gewohnt in seiner behäbig wirkenden Ausführbarkeit. Eine weitere Möglichkeit zum Auslesen der aktuellen Informationen über den Zustand der HADR-Umgebung bieten die administrativen Views und Tabellen. Über diese ist es möglich, mit einfachen SQL-Abfragen die aktuellen Informationen in entsprechend aufbereiteter Form abzufragen. Den Inhalt dieser Views und Tabellen kann man auch bequem über die Steuerzentrale einsehen. Auch eine Änderung der Paramater der HADR-Umgebung ist über die Steuerzentrale wie auch die Kommandozeile möglich. Es sei hierbei auf den Abschnitt 6.2 verwiesen. Die vierte Möglichkeit zur Überwachung und Verwaltung der HADR-Umgebung bietet die db2diag -Protokolldatei. In dieser ndet man zwar nicht den Informationsbestand, den man über die bisher betrachteten Befehle und Programme erhält, sie eignet sich aber hervorragend zur Fehlersuche und -analyse. So kann anhand der Einträge in dieser Protokolldatei beispielsweise nachvollzogen werden, wann und weshalb sich der HADR-Status geändert hat. 52 6.4 Verhalten in Ausfallszenarien Während der Laufzeit der Replikationsumgebung kann es zu verschiedenen Ausfallszenarien kommen, in denen die HADR-Umgebung verschiedene Verhaltensweisen zeigt. Der Administrator hat je nach Art des Ausfalls unterschiedliche Vorgänge einzuleiten, damit die Erreichbarkeit eines Primärsystems gewährleistet ist. Dies ist gerade aufgrund der fehlenden Funktionalität des automatisierten Takeovers (vgl. Abschnitt 5.3.1) von hoher Bedeutung. Es werden im Fortlauf die folgenden Ausfallszenarien betrachtet: • Ausfall des Primärsystems, • Ausfall des Sekundärsystems sowie • Wartungsmaÿnahmen. 6.4.1 Ausfall des Primärsystems Der Ausfall des Primärsystems zieht verschiedene Konsequenzen nach sich. Abhängig vom ausgewählten Synchronisationsmodus kann es zu Datenverlusten kommen. Dies kann insbesondere genau dann der Fall sein, wenn der asynchrone Synchronisationsmodus ausgewählt wurde, da die Transaktionen auf dem Primärsystem auch dann erfolgreich verarbeitet wurden, wenn die entsprechenden Protokolleinträge das Sekundärsystem gar nicht erst erreicht haben. Die nun durch den Administrator auszuführenden Schritte sind abhängig vom Status der HADR-Umgebung zum Zeitpunkt des Ausfalls. Benden sich die Systeme im Peer-State- Listing 15) Modus, so erfolgt das Anstoÿen eines manuellen Takeovers ( auf dem Se- kundärsystem. Dadurch wechselt das Sekundärsystem den Status und wird zum neuen Primärsystem. Es übernimmt somit auch dessen Aufgaben. Durch die ACR-Funktionalität werden die Anfragen der Anwendungen automatisch an das neue Primärsystem umgeleitet. Listing 15: Befehl zum Ausführen eines manuell erzwungenen Takeovers auf dem Sekundärsystem db2 takeover hadr on d a t a b a s e DATABASE by force Entscheidend für das weitere Vorgehen in Bezug auf das bisherige Primärsystem ist das Deaktivieren sämtlicher Funktionalitäten des bisherigen Primärsystems innerhalb der HADRUmgebung, sofern das bisherige Primärsystem noch erreichbar ist. Dies kann entweder durch das Deaktiveren der Datenbank oder dem Stoppen der Instanz erfolgen. Hierfür ist unbedingt Sorge zu tragen, da es sonst zu Konikten (wie beispielsweise dem Vorhandensein zweier Primärsysteme) innerhalb der Replikationsumgebung kommen kann, die nicht eigenständig durch HADR aufgelöst werden können. HADR selbst sorgt bei entsprechender Belegung bestimmter Parameter (siehe hierzu Abschnitt 6.2) dafür, dass es nicht zu einer derartigen Koniktsituation kommen kann, indem es die Aktivierung der Datenbank auf dem bisherigen Primärsystem untersagt. Als nächstes erfolgt die Reintegration des bisherigen Primärsystems. Hierfür ist eine Behebung des Fehlers oder der Fehler erforderlich, die zum Ausfall des Systems geführt haben. Ist die Behebung erfolgt, kann der Befehls aus Listing 16 auf dem bisherigen Primärsys- tem abgesetzt werden. Durch diesen wird es als Sekundärsystem in die HADR-Umgebung eingebunden. 53 Listing 16: Befehl zum Einbinden des bisherigen Primärsystems als Sekundärsystem in die HADR-Umgebung db2 start hadr on d a t a b a s e DATABASE as standby Sobald sich die HADR-Umgebung wieder in der Peer-State-Phase bendet, kann die bisherige Rollenverteilung durch das Absenden des Befehls aus Listing 17 auf dem aktuellen Sekundärsystem wiederhergestellt werden. Listing 17: Befehl zum Ausführen eines manuellen Takeovers auf dem Sekundärsystem db2 takeover hadr on d a t a b a s e DATABASE Bendet sich die HADR-Umgebung zum Zeitpunkt des Ausfalls des Primärsystems nicht im Peer-State-Modus, bedeutet dies, dass möglicherweise das Sekundärsystem nicht über den aktuellen Datenbestand des Primärsystems verfügt. Erfolgt in diesem Fall das Absenden des Befehls aus Listing 15, hat dies einen Datenverlust zur Folge. Aus diesem Grund sollte jeder Versuch unternommen werden, den Fehler auf dem Primärsystem zu beheben und dieses wieder als Primärsystem in die HADR-Umgebung einzubinden. Dies hat zwar eine entsprechende Ausfallzeit zur Folge, verhindert jedoch den bereits erwähnten Datenverlust, da noch nicht alle Daten auf das Sekundärsystem zum Ausfallzeitpunkt repliziert wurden. Entscheidet man sich dennoch für einen erzwungen Takeover und funktioniert damit das bisherige Sekundärsystem zum neuen Primärsystem um, ist die Reintegration des bisherigen Primärsystems nur in Form des Einspielens eines Backups des bisherigen Sekundärsystems möglich. Das Problem hierbei ist, dass das bisherige Primärsystem einen aktuelleren Datenbestand als das bisherige Sekundärsystem hat. In dieser Konstellation ist eine Einbindung als Sekundärsystem nicht möglich. Die Schritte zur Reintegration des bisherigen Primärsystems sind das Erzeugen eines aktuellen Backups des aktuellen Primärsystems, das Einspielen dessen auf dem bisherigen Primärsystem mit der das Absenden des Befehls aus Rollforward -Option und Listing 16 auf dem bisherigen Primärsystem. Sobald sich die HADR-Umgebung im Peer-State-Modus bendet, kann die bisherige Rollenverteilung wiederhergestellt werden. 6.4.2 Ausfall des Sekundärsystems Der Ausfall des Sekundärsystems ist auf den ersten Blick weniger problematisch als der Ausfall des Primärsystems. Ein Nachteil, der entsteht, ist, dass in der Zeit, in der das Sekundärsystem nicht zur Verfügung steht, keine Datenänderungen auf dieses repliziert werden können. Das Primärsystem nimmt von der Nicht-Erreichbarkeit des Sekundärsystems Kenntnis, da keine Statusmeldungen mehr auf dem Primärsystem ankommen. Dies führt im Fortgang dazu, dass das Primärsystem den HADR-Status disconnected annimmt, d.h. keine Verbindung mehr zum Sekundärsystem hat. Sobald das Sekundärsystem wieder verfügbar ist, muss die HADR-Umgebung in gewohnter Vorgehensweise mit den bekannten Befehlen neu gestartet werden. Sollte diese Vorgehensweise nicht zum Erfolg führen, bleibt als letzte Instanz die Möglichkeit des Einspielens eines Backups des Primärsystems auf dem Sekundärsystem mit der Rollforward -Option erhalten. Danach kann die HADR-Umgebung wie gewohnt gestartet werden. 54 6.4.3 Wartungsmaÿnahmen Die Wartung des Primärsystems erfolgt mittels eines geplanten Takeovers. Durch diesen wird das aktuelle Primärsystem zum neuen Sekundärsystem und kann aus der HADRUmgebung ausgeklinkt werden. Das bisherige Sekundärsystem wird zum neuen Primärsystem und übernimmt für die Ausfallzeit des bisherigen Primärsystems dessen Aufgaben. Nach erfolgter Wartung des bisherigen Primärsystems kann dieses wieder als Sekundärsystem in die HADR-Umgebung eingeklinkt werden. Benden sich die beiden Systeme im Peer-State-Modus, kann die eigentliche Rollenverteilung der beiden Systeme wiederhergestellt werden. 6.5 Erprobung auf einem Testsystem Nach der Auswahl des HADR-Verfahrens für das vorliegende Beispiel und damit für die konkrete Replikationsumgebung erfolgte die Erprobung des Verfahrens auf einer Testumgebung, die die eigentliche Systemumgebung simulierte. Zu diesem Zwecke wurden auf einem Server zwei virtuelle Server erstellt, die die Bezeichnungen ten. Auf der replidb1, replidb1 und replidb2 inne hat- die als Primärsystem fungierte, wurde wie auch auf der die die Funktion des Sekundärsystems übernahm, jeweils eine Testdatenbank für replidb2, MyCoRe erstellt. MyCoRe stellte in der Testumgebung die Anwendung dar, die für die Erzeugung von Anfragen an die Datenbankserver zuständig war. MyCoRe ist ein System zur Entwicklung von Dokumenten- und Publikationsservern, Archivanwendungen, Sammlungen von Digitalisaten oder vergleichbaren Repositorien. An der Entwicklung von MyCoRe ist unter anderem auch die Thüringer Universitäts- und Landesbibliothek beteiligt. Für weitere Informationen zu dieser Anwendung sei auf [MyC09] verwiesen. Im Rahmen der Erprobung wurden die folgenden Vorgänge und Szenarien getestet: • Konguration der HADR-Umgebung, • Starten und Stoppen der HADR-Funktionalität auf dem Sekundär- und Primärsystem, • Takeover (geplant) zur Wartung des Primärsystems, • Takeover (erzwungen) bei Ausfall des Primärsystems durch höhere Gewalt, • Takeover (erzwungen) bei Ausfall des Primärsystems nach Verlust der Verbindung, • Verhalten des Primärsystems bei Ausfall des Sekundärsystems, • Reintegration des Primärsystems nach Ausfall durch höhere Gewalt und anschlieÿenden erzwungenen Takeover, • Reintegration des Primärsystems nach Verlust der Verbindung und anschlieÿenden erzwungenen Takeover sowie • Funktionalität von ACR in Verbindung mit einem Connection Pool. Während der Erprobung wurde teilweise Last auf dem Datenbankserver erzeugt, um das Verhalten der HADR-Umgebung unter diesen Umständen erproben zu können und die 55 ACR-Funktionalität zu überprüfen. Hierzu kam ein Lastprogramm auf Basis von OpenSource-Werkzeugen zum Einsatz, für das im Rahmen einer Studienarbeit [Sch09] an der Thüringer Universitäts- und Landesbibliothek Lasttest-Szenarien für MyCoRe entwickelt wurden. 56 7 Zusammenfassung und Ausblick Im Rahmen dieser Studienarbeit wurden drei verschiedene Replikationsverfahren unter dem DBMS IBM DB2 LUW mit dem Ziel untersucht, eine Hochverfügbarkeitslösung für die Datenbankserver der Digitalen Bibliothek der Friedrich-Schiller-Universität Jena und des Freistaates Thüringen zu realisieren. Die Notwendigkeit für dieses Vorhaben begründet sich in der bisherigen Vorgehensweise zur Sicherung des Datenbestandes. Durch die Erfassung des Ausgangszustandes wurde deutlich, dass bei einem Ausfall des Primärsystems auf dem dann zum Einsatz kommenden Sekundärsystem kein identischer Datenbestand vorzunden beziehungsweise herstellbar wäre. Dies liegt unter anderem daran, dass nur einmal pro Tag durch eine nächtliche Sicherung ein Online-Backup auf dem Sekundärsystem eingespielt wird und damit alle Transaktionen verloren gehen, die nach dem Online-Backup auf dem Primärsystem ausgeführt wurden. Als Grundlage für die Untersuchung der verschiedenen Replikationsverfahren folgte nach der Feststellung des Ausgangszustandes und der Denierung des Zielzustandes die Erfassung theoretischer Grundlagen zur Hochverfügbarkeit und Replikation. Hierbei wurde der Hochverfügbarkeitsbegri samt Einteilung in Verfügbarkeitsklassen beleuchtet. Der Einteilung der Replikationsverfahren in hardware- und softwarebasierte Verfahren folgten Ausführungen über die Klassikation von Replikationsverfahren. Der Schwerpunkt der Untersuchungen lag auf den Replikationsverfahren der SQL-Replikation, Q-Replikation und HADR. In diesen wurden die zentralen Unterschiede der Verfahren deutlich, aber auch die Gemeinsamkeiten vor allem der SQL- und Q-Replikation konnten aufgezeigt werden. Der wesentlichste Unterschied zwischen den beiden letztgenannten Verfahren liegt in der Transferierung der Änderungsinformationen: Während bei der SQLReplikation eine Zwischenspeichertabelle als verbindendes Kommunikationselement dient, übernimmt diese Aufgabe bei der Q-Replikation das Warteschlangensystem. Dieser Unterschied trägt auch dazu bei, dass in Bezug auf die Performance die Q-Replikation deutliche Vorteile gegenüber der SQL-Replikation besitzt. Ein deutlicher Unterschied bezüglich der Architektur der Replikationsumgebung konnte zwischen diesen beiden Verfahren und HADR registriert werden. Unter HADR werden die Änderungsinformationen direkt von dem Primär- auf das Sekundärsystem durch das als Log Shipping bezeichnete Verfahren transferiert. Darin liegt auch der Grund für den groÿen Vorteil des Verfahrens: Der Replikationsbereich umfasst eine groÿen Umfang an Operationen; SQL- und Q-Replikation unterstützen in diesem Punkt deutlich weniger Operationen. Dieser Unterschied führt auch zu der Erkenntnis, dass HADR für umfangreiche, die Gesamtheit betreende Replikationsumgebungen besser geeignet ist, die anderen beiden Verfahren ihre Vorteile aber geltend machen, wenn es um die Replizierung spezieller Untermengen oder aber die Replizierung auf mehr als nur ein Sekundärsystem geht. Nach der Beleuchtung der Architekturen, Funktionsweisen und spezischen Eigenschaften der Replikationsverfahren wurde im Rahmen einer Anforderungsanalyse das geeignetste Verfahren für das konkrete Anwendungsbeispiel der Digitalen Bibliothek gesucht. Hierfür wurden eine Vielzahl an Anforderungskategorien aufgestellt und anhand dieser die drei Replikationsverfahren mittels Eignungsnoten bewertet. Als Ergebnis der Betrachtung (der Eignungsnoten) wurde das HADR-Verfahren als das Geeignetste ausgewählt. Im Fortgang wurde das HADR-Verfahren in Bezug auf die Konguration hin betrachtet und die Möglichkeiten zum Monitoring, zur Verwaltung und Pege genannt. Zur Überprüfung der Eignung des Verfahrens für das konkrete Anwendungsbeispiel und zur Festigung der Auswahlentscheidung folgten Erprobungsdurchläufe auf einem Testsystem. Hierzu wurden 57 die wichtigsten Szenarien auch unter Erzeugung zusätzlicher Last auf dem Datenbankserver simuliert. Zum Zeitpunkt der Fertigstellung dieser Studienarbeit war das HADR-Verfahren im Falle der Digitalen Bibliothek noch nicht im produktiven Einsatz. Dieses ist demnach im Nachgang der Studienarbeit noch umzusetzen. Auch die Automatisierung des Takeover könnte Bestandteil einer weiteren Betrachtung sein, da dies in der verwendeten DB2-Version nicht unterstützt wird. Es gibt hierfür einige Möglichkeiten, wie die Automatisierung praktisch umgesetzt werden könnte. Als Beispiele seien an dieser Stelle die (TSA) [IBM07b] oder das Open-Source-Projekt 58 Tivoli System Automation Linux HA [Rob09] genannt. Glossar ACID ACID steht für Atomicity, Consistency, Isolation und Durability und beschreibt damit die in einem DBMS für Änderungsoperationen geforderten Transaktionseigenschaften. ACR Automatic Client Reroute. Funktionalität, die das automatische Weiterleiten von Datenbankanfragen von einem Primär- auf ein Sekundärsystem ermöglicht. ACR kann unter anderem mit HADR, SQL- und Q-Replikation kombiniert werden. AEC Availability Environment Classication. Von der HRG entwickelte Klassikation der Hochverfügbarkeit in sechs verschiedene Verfügbarkeitsklassen. Appliance Hardwarekomponente, die für eine spezische Funktionalität konguriert ist und darauf abzielt, dass für den Betrieb dieser möglichst keine Eingrie des Benutzers erforderlich sind. Apply-Programm Hilfsprogramm des DBMS bei der SQL-Replikation. Es dient zum Verarbeiten von durchgeführten Änderungsoperationen auf registrierten Zieleinheiten. Archival logging Archivprotokollierung. Verfahren zur Protokollierung. Protokolleinträge werden fortlaufend in neue Protokolldateien geschrieben, die wiederum archiviert werden und zur Wiederherstellung und Zurücksetzen von Änderungsoperationen verwendet werden können. Backup Sicherungsdatei(en) eines bestimmten Objektbereichs, die zur Wiederherstellung der Systemumgebung beziehungsweise des bestimmten Objektbereichs im Fehlerfall dient /dienen. BLOB Binary Large Object. Datentyp, der eine Bytefolge enthält, deren Gröÿe bezogen auf IBM DB2 LUW im Bereich zwischen 0 Byte und 2 Gigabyte (minus 1 Byte) liegt. BLOBs können beispielsweise Bild-, Audio- oder Videodaten enthalten. Buerpool Puerpool. Physischer Speicherbereich im Arbeitsspeicher des Datenbankservers, der beim Lesen von Daten von der Festplatte oder beim Ändern von Daten zum Zwischenspeichern von Tabellen- und Indexdatenseiten verwendet wird [IBM06b]. CA-Tabelle Change-Aggregate-Tabelle. Replikationszieleinheitstyp, der zum Ablegen von Infor- mationen, die auf dem Informationsbestand der Zwischenspeichertabellen beruhen, dient. CA-Tabellen gehören zum Replikationszieleinheitstyp der Ergebnistabellen. 59 Capture-Programm Hilfsprogramm des DBMS bei der SQL-Replikation. Es dient zum Aunden von durchgeführten Änderungsoperationen auf registrierten Quelleinheiten. CCD-Tabelle Consistent-Change-Data. Replikationszieleinheitstyp zum Ablegen von Protokollin- formationen. CCD-Tabellen können auch zur Prüfung von Protokollinformationen eingesetzt werden. Circular logging Umlaufprotokollierung. Verfahren zur Protokollierung. Protokolleinträge werden fortlaufend in eine bestimmte Anzahl von Protokolldateien geschrieben. Es kommt bei diesem Verfahren zur zyklischen Überschreibung und damit Wiederbenutzung von Protokolldateien. CLOB Character Large Object. Datentyp, der eine Zeichenfolge enthält, deren Gröÿe im Bereich zwischen 0 Byte und 2 Gigabyte (minus 1 Byte) liegt. CLR Commit-Log-Record. Entspricht genau dem Protokolleintrag, der die erfolgreiche Durchführung einer (Änderungs-)Transaktion beschreibt. Commit Ein Commit signalisiert die erfolgreiche Verarbeitung einer Änderungstransaktion. D-Eigenschaften Das Ergebnis dieser Änderungstransaktion ist gemäÿ der ACI dauerhafter Natur ( Durability/Dauerhaftigkeit). von Connection Pool Verwaltungssystem für Datenbankverbindungen. Es werden eine Reihe von Datenbankverbindungen zur Verfügung gestellt und bereit gehalten, die bei Bedarf zur Ausführung von SQL-Anweisungen in Anspruch genommen werden. Der Vorteil eines Connection Pools liegt in der Vermeidung der kostenintensiven Vorgänge wie dem wiederholten Aufbau und dem Schlieÿen einer Datenbankverbindung. Nicht in Verwendung stehende Verbindungen werden nicht geschlossen, sondern für eine spätere Benutzung geparkt. Detailierte Informationen sind auch unter [MSH02] zu nden. Controller Elektronische Einheit, die Bestandteil einer Hardwareumgebung ist und unterschiedliche Vorgänge steuert oder regelt. Data-Warehouse-System Datenlager. Zentrale, integrierte Datensammlung, die zur Analyse und Auswertung einer Vielzahl an Informationen dient. Datenblockung Möglichkeit zur Steuerung und Optimierung des Replikationsdurchlaufs bei der SQLReplikation. 60 Datenussrichtung Bezeichnet die Richtung, in welcher sich die Daten zwischen verschiedenen Systemen bewegen. Es wird grundsätzlich zwischen der unidirektionalen, bidirektionalen und der peer-to-peer Datenussrichtung unterschieden. DB2 LUW DB2 Linux, Unix and Windows. Datenbankmanagementsystem der Firma IBM. DBMS Datenbankmanagementsystem. DDL Data Description Language beziehungsweise Data Denition Language. Datendeni- tionssprache (CREATE, ALTER, DROP). DML Data Manipulation Language. Datenbearbeitungssprache (SELECT, INSERT, DE- LETE oder UPDATE). Ereignissteuerung Typ des Durchführungsintervalls bei der SQL-Replikation, bei dem ein Replikationsdurchlauf beispielsweise bei Eintreten eines bestimmten Ereignisses gestartet wird. Fix Pack Ein Fix Pack ist eine Sammlung von verschiedenen Korrekturmaÿnahmen, um vorhandene Fehler in Programmen zu beheben. HADR High Availability Disaster Recovery. Replikationsverfahren der Firma IBM für das DBMS DB2 LUW. Das Verfahren dient der Realisierung einer Hochverfügbarkeitslösung und verwendet das sogenannte Log Shipping zur Transferierung von Protokoll-einträgen. Heartbeats Nachrichten, die zwischen zwei Systemen verschickt werden, um die gegenseitige Erreich- beziehungsweise Verfügbarkeit der Systeme zu überprüfen. Hibernate Ein Open-Source-Persistenz-Framework für Java mit der Funktionalität eines objektrelationalen Mapping-Werkzeuges. Hochverfügbarkeit Die Fähigkeit eines Systems, einen uneingeschränkten Betrieb auch und gerade bei Ausfällen desselben oder einer seiner Komponenten zu gewährleisten, ohne dass es eines unmittelbaren menschlichen Eingris erfordert. HRG Harvard Research Group. Ein im Marktforschungs- und Beratungssegment tätiges Unternehmen. 61 Intervallsteuerung Typ des Durchführungsintervalls bei der SQL-Replikation, bei dem ein Replikationsdurchlauf jede x Minuten gestartet wird. Konsistenz Zustand, in dem die Widerspruchsfreiheit innerhalb der Datenbank gewährleistet ist. Das bedeutet, dass alle in der Datenbank enthaltenen Daten die Konsistenzbedingungen erfüllen. Konsistenz ist eine der vier geforderten ACID-Eigenschaften. Kontinuierliche Replikation Typ des Durchführungsintervalls bei der SQL-Replikation, bei dem ein Replikationsdurchlauf genau dann und somit zeitnah gestartet wird, wenn Daten zur Replizierung vorliegen. Latenz Zeit der Verzögerung, bis eine auf dem Primärsystem durchgeführte Änderungsoperation auf dem Sekundärsystem repliziert ist. Linux Red Hat Bekannte Linux-Distribution der Firma Red Hat. Linux-HA Linux High Availability. Open-Source-Produkt zur Realisierung einer Hochverfügbarkeitslösung unter Linux. Linux-HA kann unter anderem dazu eingesetzt werden, den Takeover bei HADR zu automatisieren. Log Shipping Verfahren zur Transferierung von Protokolleinträgen von einem Primär- auf ein Sekundärsystem. Die Protokolleinträge werden auf dem Sekundärsystem nachgefahren, sodass dieses nach dem Prozess des Nachfahrens über den entsprechenden Aktualitätsgrad des Primärsystems verfügt. Das Verfahren des Log Shipping kommt bei HADR zum Einsatz. Logging Protokollierung. Verfahren zur Aufzeichnung des Zeitpunktes, der Reihenfolge und des von der Operation betroenen Elements. Protokollierung ist wichtig für das Wiederherstellen und Zurücksetzen von Änderungsoperationen. Logical Log File Protokolldatei. Protokolleinträge werden in einer Protokolldatei abgelegt, die wiederum auf der Festplatte abgelegt wird. Logical Log Puer Protokollpuer. Physischer Speicherbereich im Arbeitsspeicher des Datenbankser- vers, in dem Protokolleinträge vor dem Schreiben in eine Protokolldatei abgelegt werden. 62 Logical Log Record Protokolleintrag. Protokolleinträge enthalten Informationen über das modizierte Tupel, wie beispielsweise den Zustand vor und nach der Änderungsoperation. LSN Log Sequence Number. Eine LSN dient der eindeutigen Identizierung von entspre- chenden Protokolleinträgen in einer Protokolldatei. Master Ein aktiv agierender Teilnehmer in Form eines Rechners in einem Rechnerverbund. Ein Master-Rechner besitzt spezielle Zugrisrechte, um auf Datenmengen auf SlaveRechnern unaufgefordert zugreifen zu können. Monitoring Prozess des Überwachens und Prüfens einer Systemumgebung unter anderem im Hinblick auf die Leistung, Performance und Stabilität der jeweiligen Systemumgebung. MyCoRe My Content Repository. MyCoRe ist ein System zur Entwicklung von Dokumentenund Publikationsservern, Archivanwendungen, Sammlungen von Digitalisaten oder vergleichbaren Repositorien. Patch Kleines Software-Paket, welches Maÿnahmen zur Fehlerbehebung für ausführbare Programme beinhaltet. Primärsystem Aktives System in einer Replikationsumgebung, welches die Anfragen des Anwendungsservers verarbeitet und die entsprechenden Antworten versendet. Q-Apply-Programm Hilfsprogramm des DBMS bei der Q-Replikation. Es dient zum Verarbeiten von durchgeführten Änderungsoperationen auf registrierten Zieleinheiten. Q-Apply-Programme sind multithread-fähig, d.h. sie können Verarbeitungsschritte parallel ausführen. Q-Capture-Programm Hilfsprogramm des DBMS bei der Q-Replikation. Es dient zum Aunden von durchgeführten Änderungsoperationen auf registrierten Quelleinheiten. Q-Replikation Replikationsverfahren der Firma IBM unter anderem für das DBMS DB2 LUW. Die Besonderheit des Verfahrens liegt in der Verwendung der Warteschlangensysteme, durch deren Hilfe die Änderungsoperationen auf den Quelleinheiten in Form von Messages auf die Zieleinheiten repliziert werden. 63 Rack Ein Rack ist eine Art Haltevorrichtung, die vorzugsweise in Rechenzentren zum Einsatz kommt. In einem solchen Rack können mehrere Rechner untergebracht werden, die einen Rechnerverbund oder Teil eines Solchen bilden. RAID Redundant array of independent disks. Es dient der Organisation mehrerer physischer Festplatten eines Rechners zu einem logischen Laufwerk. RAID-Systeme dienen unter anderem zur Realisierung einer höheren Datensicherheit bei einem Ausfall einzelner Festplatten oder der Erhöhung der Datendurchsatzrate. Recovery Wiederherstellung. Bezeichnet den Vorgang der Wiederherstellung von Daten im Fehlerfall. Replikat Replikat bezeichnet die Menge der Einheiten, die auf einem System zur Replizierung beziehungsweise die auf einem System als Replikationsziel gekennzeichnet sind. Replikation Vorgehensweise der mehrfachen Speicherung von Daten auf (geographisch) verteilten Speichersystemen. Replikationsdurchlauf Vorgang der Replizierung von Änderungsoperationen, die auf Quelleinheiten ausgeführt wurden, auf die entsprechenden Zieleinheiten. Rollforward-Modus Modus, der das Nachfahren von Änderungsoperationen erlaubt. Bendet sich eine Datenbank in diesem Modus, werden alle Protokolleinträge, die die Datenbank in diesem Zeitraum erreichen, nachgefahren. Bei HADR bendet sich das Sekundärsystem in diesem Modus. Im Rollforward-Modus sind keine anderen Datenbankanweisungen und -zugrie möglich. Schlüsseleigenschaft Eigenschaft einer Entität, die zur eindeutigen Identizierung dient. Sekundärsystem Meist passives System in einer Replikationsumgebung, welches als Replikationsziel für Ausfallszenarien zur Verfügung steht. Im Falle eines Ausfalls des Primärsystems nimmt das Sekundärsystem die Rolle des Primärsystems ein und bearbeitet fortan die einkommenden Anfragen des Anwendungsservers. Slave Ein passiv agierender Teilnehmer in Form eines Rechners in einem Rechnerverbund, der ohne die Erlaubnis des Master-Rechners keine Zugriserlaubnisse auf andere Rechner im Rechnerverbund besitzt. 64 SPoF Single Point of Failure. Beschreibt die Eigenschaft einer Komponente, deren Ausfall zum Ausfall des gesamten Systems führen kann. SQL Structured Query Language. Abfragesprache zur Denition, Abfrage und Manipulation von Daten sowie zur Rechteverwaltung und Transaktionskontrolle in relationalen DBMS-Produkten. SQL-Replikation Replikationsverfahren der Firma IBM unter anderem für das DBMS DB2 LUW. Die Besonderheit des Verfahrens liegt in der Verwendung der sogenannten Zwischenspeichertabellen, durch deren Hilfe die Änderungsoperationen auf Quelleinheiten auf die Zieleinheiten repliziert werden. Sun XFire Server-Produkt der Firma SUN. Synchronisation Prozess des Abgleichs zweier Systeme untereinander. Ein System wird mit einem anderen synchronisiert, indem die Datenmengen auf einen identischen Stand gebracht werden. Takeover Ein Takeover bezeichnet bei HADR das Umschalten des Sekundärsystems zum neuen Primärsystem. Das bisherige Sekundärsystem übernimmt in diesem Fall die Aufgabe des bisherigen Primärsystems, indem es die Anfragen der Anwendungen verarbeitet. Timestamp Zeitstempel. Ein Zeitstempel dient der Feststellung der möglichst genauen Ausfüh- rungszeit beispielsweise einer Änderungsoperation oder aber einer Änderung an Kongurationsparametern. Trigger Datenbankobjekt, das einer Tabelle oder einem View zugeordnet ist und eine Regel deniert. Ein Trigger führt bestimmte Aktionen aus, wenn ein vordeniertes Ereignis eintritt. TSA Tivoli System Automation. Softwareprodukt der Firma IBM. Es dient der Überwa- chung der Verfügbarkeit von Systemen in einem Rechnerverbund. TSA ermöglicht zudem die automatische Herstellung von gewünschten Systemzuständen. Unique-Eigenschaft Eigenschaft einer Entität, die dafür sorgt, dass die Werte der Entität nicht als Duplikate auftreten können. 65 UoW Unit of Work. Eine UoW bezeichnet eine wiederherstellbare Folge von Änderungs- operationen in einem Anwendungsprozess und stellt damit eine andere Bezeichnung für eine Transaktion dar. Verfügbarkeit Grad, zu dem die vollständige Funktionalität einer Anwendung für den Nutzer vorhanden ist. WAL Write Ahead Logging. Verfahrensweise bei der Durchführung von Änderungstransaktionen. Eine Änderungstransaktion kann erst dann festgeschrieben werden, wenn die dazugehörigen Protokolleinträge erzeugt und persistent gemacht wurden. WebSphere MQ Softwareprodukt der Firma IBM. WebSphere MQ ist eine nachrichtenorientierte Anwendung, die im Falle der Q-Replikation für die Transferierung und Verwaltung der entsprechenden Messages sorgt. WebSphere MQ Messages Nachrichten, die Informationen über die Änderungsoperationen auf der Quelleinheit enthalten. Diese Nachrichten werden über das Warteschlangensystem der QReplikation gesendet und auf dem Sekundärsystem verarbeitet. 66 Literatur [Asc05] John Ascho. Performance Analysis - WebSphere Information Integrator. IBM Corp., 10.05.2005. [GHOS96] J. Gray, P. Helland, P. O`Neil und D. Shasha. The dangers of replication and a solution. [Gol05] Proc. of SIGMOD Conf, Seiten 173182, 1996. Christoph Gollmick. Konzept, Realisierung und Anwendung nutzerdenierter Replikation in mobilen Datenbanksystemen. Dissertation, Institut für Informatik, Friedrich-Schiller-Universität Jena, November 2005. [Hat09] Red Hat. Hibernate. https://www.hibernate.org/, letzter Aufruf: 01.07.2009. [Hel04] Andrea Held. Oracle 10g Hochverfügbarkeit. Addison-Wesley, 1. Auf lage, Ok- tober 2004. [HSS07] A. Heuer, G. Saake und K. Sattler. Datenbanken: Konzepte und Sprachen. Mitp-Verlag, 3. Auf lage, 2007. My Mother Thinks I am a DBA! Cross-Platform, Multi-Vendor, Distributed Relational Data Replication with IBM DB2 DataPropagator and IBM DataJoiner Made Easy! IBM Corp., 1. Auf lage, Juni 1999. [IBM99] IBM. [IBM05] IBM. [IBM06a] IBM. WebSphere Information Integrator Q Replication: Fast Track Implementation Scenarios. IBM Corp., 1. Auf lage, April 2005. Datenrecovery und hohe Verfügbarkeit, Handbuch und Referenz. SW TSC Germany, Juli 2006. [IBM06b] IBM. DB2 Version 9 Systemverwaltung: Optimierung. SW TSC Germany, August 2006. [IBM07a] [IBM07b] [IBM09] High Availability and Scalability Guide for DB2 on Linux, UNIX, and Windows. IBM Corp., 1. Auf lage, September 2007. IBM. Tivoli System Automation for Multiplattforms - Installation and Conguration Guide. IBM Corp., 2.3. Auf lage, 2007. IBM. IBM. IBM DB2 Database für Linux, UNIX und Windows - Informationszentrale. http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp, letzter Aufruf: 01.07.2009. [Küs85] Fehlererkennung und Fehlerbehandlung in Speicherungsstrukturen von Datenbanksystemen. Springer-Verlag Berlin Heidelberg, 1. Auf lage, Klaus Küspert. 1985. [MSH02] [Mun09] Stefan Middendorf, Reiner Singer und Jörn Heid. Referenz für die JavaTM-2-Plattform. Florian Munz. Programmierhandbuch und dPunkt-Verlag, 3. Auf lage, 2002. Einsatz von Replikation. http://wwwlgis.informatik.uni- kl.de/archiv/wwwdvs.informatik.uni-kl.de/courses/seminar/ SS2004/ausarbeitung14.pdf, letzter Aufruf: 01.07.2009. [MyC09] MyCoRe. Mycore. http://www.mycore.de/, letzter Aufruf: 01.07.2009. 67 [OGT07] [Rob09] J. Orhanovic, I. Grodtke und M. Tiefenbacher. rung, Handbuch und Referenz. Alan Robertson. DB2-Administration: Einfüh- Addison-Wesley, 1. Auf lage, Dezember 2007. Linux-ha. http://www.linux-ha.org/, letzter Aufruf: 01.07.2009. [Sch09] Oliver Schimratzki. Leistungstests auf Basis von Open Source Werkzeugen für das Content Repository Framework Mycore. Studienarbeit, Institut für Informatik, Friedrich-Schiller-Universität Jena, Mai 2009. [UrM09] UrMEL. Urmel - University Multimedia Electronic Library. http://www.urmeldl.de/content/below/home.xml, letzter Aufruf: 01.07.2009. [WG03] [Zen07] Joachim Weiÿ und Walter Greulich. Der Brockhaus Computer und Informationstechnologie. Fachlexikon für Hardware, Software, Multimedia, Internet, Telekommunikation. Brockhaus. Leipzig, Mannheim, 1. Auf lage, 2003. Christian Zentgraf. Evaluation of a design for ecient log-based replication using a pseudo-view interface over the log. Diplomarbeit, Institut für Informatik, Friedrich-Schiller-Universität Jena, November 2007. 68 Abbildungsverzeichnis 1 Ausgangszustand mit manuellem Einspielen der Datensicherung . . . . . . . 4 2 Zielzustand mit Replikation . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3 Anwendungsbeispiele des unidirektionalen Datenuss . . . . . . . . . . . . . 10 4 Architektur einer SQL-Replikationsumgebung . . . . . . . . . . . . . . . . . 11 5 Prozess der Erfassung einer Transaktion auf einer registrierten Quelleinheit bei der SQL-Replikation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 14 Prozess der Verarbeitung einer Transaktion auf einer registrierten Zieleinheit bei der SQL-Replikation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7 Architektur einer Q-Replikationsumgebung . . . . . . . . . . . . . . . . . . 22 8 Prozess der Erfassung einer Transaktion auf einer registrierten Quelleinheit. 23 9 Prozess der Verarbeitung einer Transaktion auf einer registrierten Zieleinheit. 24 10 Grundlegender Überblick über die Kommunikation mit den Warteschlangenmanagern. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 11 Architektur einer HADR-Replikationsumgebung . . . . . . . . . . . . . . . . 28 12 Zyklus der verschiedenen Phasen des HADR-Verfahrens . . . . . . . . . . . 29 13 Automatic Client Reroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 69 70 Tabellenverzeichnis 1 Verfügbarkeitsklassen der Harvard Research Group . . . . . . . . . . . . . . 2 Aufbau des Zieleinheitstypes Benutzerkopie 3 Aufbau des Zieleinheitstypes Basisergebnistabelle 4 Aufbau des Zieleinheitstypes CA-Tabelle 5 Aufbau des Zieleinheitstypes CCD-Tabelle 6 Aufbau des Zieleinheitstypes Replikat . . . . . . . . . . . . . . . . . 7 17 . . . . . . . . . . . . . . 18 . . . . . . . . . . . . . . . . . . 18 . . . . . . . . . . . . . . . . . 19 . . . . . . . . . . . . . . . . . . . . 19 7 Erklärung der ACID-Eigenschaften . . . . . . . . . . . . . . . . . . . . . . . 28 8 Übersicht über die Synchronisationsmodi des HADR-Systems . . . . . . . . 32 9 Vergleich der Architektur einer Replikationsumgebung . . . . . . . . . . . . 36 10 Vergleich der Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . 37 11 Vergleich des Replikationsbereichs . . . . . . . . . . . . . . . . . . . . . . . . 38 12 Vergleich der Verwaltung und Pege eines Verfahrens . . . . . . . . . . . . . 39 13 Eignungsnoten der Replikationsverfahren . . . . . . . . . . . . . . . . . . . . 44 14 Übersicht über die Kongurationsparameter . . . . . . . . . . . . . . . . . . 51 71 72 Quellcodeverzeichnis 1 Sekundärsystem eintragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2 Archival Logging aktivieren . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3 Protokollierung erweitern mit LOGINDEXBUILD . . . . . . . . . . . . . . . 48 4 Backup einer Datenbank erstellen . . . . . . . . . . . . . . . . . . . . . . . . 49 5 Einspielen eines Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 6 Modifzieren von alternate server auf dem Primärsystem 49 7 Modifzieren von alternate server auf dem Sekundärsystem . . . . . . . . . . 49 8 Modifzieren der HADR-Parameter auf dem Primärsystem . . . . . . . . . . 50 9 Modifzieren der HADR-Parameter auf dem Sekundärsystem . . . . . . . . . 50 10 Starten von HADR auf dem Sekundärsystem . . . . . . . . . . . . . . . . . 50 11 Starten von HADR auf dem Primärsystem . . . . . . . . . . . . . . . . . . . 50 12 Starten von HADR mit der Erweiterungsklausel FORCE . . . . . . . . . . . 51 13 Snapshot-Befehl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 14 db2pd -Befehl 52 15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Befehl zum Ausführen eines manuell erzwungenen Takeovers auf dem Sekundärsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Befehl zum Einbinden des bisherigen Primärsystems als Sekundärsystem in die HADR-Umgebung 17 53 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Befehl zum Ausführen eines manuellen Takeovers auf dem Sekundärsystem . 54 73 74 Erklärung Ich erkläre, dass ich die vorliegende Studienarbeit selbstständig und nur unter Verwendung der angegebenen Quellen und Hilfsmittel angefertigt habe. Geraberg/Jena, 01. Juli 2009 75
