Studienarbeit. Andreas Krug Betreuer. Dipl.-Math. Ulrike Krönert Dipl.-Inf. Thomas Scheer Dipl.-Dok. Michael Lörzer.

Größe: px
Ab Seite anzeigen:

Download "Studienarbeit. Andreas Krug anfrage@andreaskrug.de. Betreuer. Dipl.-Math. Ulrike Krönert Dipl.-Inf. Thomas Scheer Dipl.-Dok. Michael Lörzer."

Transkript

1 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 Betreuer Dipl.-Math. Ulrike Krönert Dipl.-Inf. Thomas Scheer Dipl.-Dok. Michael Lörzer Thüringer Universitäts- und Landesbibliothek Jena Bibliotheksplatz 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 Jena 01. Juli 2009

2 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 Q- Replikation 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-Schiller- Universitä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.

3 Inhaltsverzeichnis 1 Einleitung Motivation Ziele der Studienarbeit Aufbau der Studienarbeit Ausgangs- und Zielzustand 3 3 Hochverfügbarkeit 6 4 Theoretische Grundlagen der Replikation Hardware- und softwarebasierte Replikation Klassikation der Replikationsverfahren Replikationsverfahren unter IBM DB2 LUW SQL-Replikation Architektur einer SQL-Replikationsumgebung Funktionsweise Subskriptionsgruppen Zieleinheitstypen Replikationsarten Zwischenspeichertabellen Replikationsbereich Q-Replikation Architektur einer Q-Replikationsumgebung Funktionsweise Replikationstypen Replikationsbereich High Availability Disaster Recovery (HADR) Architektur und Funktionsweise Synchronisationsmodi Automatic Client Reroute (ACR) Replikationsbereich Vergleich und Bewertung Architektur einer Replikationsumgebung Funktionsweise Replikationsbereich Verwaltung und Pege Performance-Untersuchungen von Ascho i

4 6 Praktische Umsetzung einer Hochverfügbarkeitslösung mittels eines Replikationsverfahrens Anforderungsanalyse und Auswahl eines Verfahrens Konguration des HADR-Systems Monitoring, Verwaltung und Pege Verhalten in Ausfallszenarien Ausfall des Primärsystems Ausfall des Sekundärsystems Wartungsmaÿnahmen Erprobung auf einem Testsystem Zusammenfassung und Ausblick 57 Glossar 59 Literatur 67 Abbildungsverzeichnis 69 Tabellenverzeichnis 71 Quellcodeverzeichnis 73 ii

5 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 Friedrich- Schiller-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 Hochverfü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

6 Das vierte Kapitel beschäftigt sich mit einigen theoretischen Vorbetrachtungen der Replikation, 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 DBMS IBM DB2 LUW Version 9. So werden hier die Verfahren der SQL-Replikation, Q-Replikation sowie der High Availability Disaster Recovery (HADR), wobei unter anderem Bezug auf die Architektur und Funktionsweise genommen wird, eingehend erklärt. Im sechsten Kapitel liegt die Konzentration auf der Beschreibung der praktischen Umsetzung 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

7 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 UrMEL (University Multimedia Electronic Library). Die Aufgabe von UrMEL besteht in der Bündelung der vielfältigen Aktivitäten an der Friedrich-Schiller-Universität Jena zur Bereitstellung multimedialer und historischer Dokumente in gemeinsamen Projekten [UrM09]. Zu diesem Zwecke umfasst UrMEL derzeit die drei Projektkonzeptionen [UrM09] und die auf dem Open-Source-System MyCoRe (siehe dazu auch Abschnitt 6.5) basieren. Unter 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 einsehbar. Hierunter 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 ndet man eine Reihe von Spezialapplikationen 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 Verwaltung 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 IBM DB2 LUW Version 9 eingesetzt. Dieses läuft gegenwärtig auf einer Sun XFire 4540 mit dem Betriebssystem Linux Red Hat in der Version 5.1. Wie in Abbildung 1 zu erkennen ist, erfolgte die Datensicherung bislang durch Online- 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 Totalausfalls, 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

8 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 UrMEL jederzeit verfügbar sind. Die 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

9 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

10 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[%] = ( ) Ausfallzeit Produktionszeit + Ausfallzeit 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. Die Harvard Research Group (HRG), ein im Marktforschungs- und Beratungssegment tätiges Unternehmen, unterteilt die Hochverfügbarkeit in ihrer Availability Environment Classication (AEC 0 bis 5) in sechs Verfügbarkeitsklassen ein, die in der folgenden Tabelle 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

11 HRG-Klasse Bezeichnung Erklärung AEC-0 Conventional Funktion kann unterbrochen werden, Datenintegrität ist nicht essenziell. AEC-1 Highly Reliable Funktion kann unterbrochen werden, Datenintegrität muss jedoch gewährleistet sein. AEC-2 High Availability 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

12 4 Theoretische Grundlagen der Replikation Im Kontext der Datenverarbeitung bezeichnet die Replikation das Speichern ein und derselben 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 SQL-Replikation, Q-Replikation und HADR der Firma IBM genannt. Auf diese wird im fünften Kapitel näher eingegangen. 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

13 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 Änderungsoperation 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 lazy oder optimistische Replikation 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 Änderungsoperation durchgeführt werden kann, nämlich der Primary-Copy-Ansatz und der Update-Everywhere-Ansatz [Mun09]. Der Primary-Copy-Ansatz beschreibt eine Replikationsumgebung, bei der ein Replikationsteilnehmer 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 Master- Systems ü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

14 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 Kon- ikten 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 Latest Timestamp und Earliest Timestamp. Eine Erweiterung des bidirektionalen Datenusses stellt die Datenussrichtung peer-topeer 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

15 5 Replikationsverfahren unter IBM DB2 LUW Das DBMS IBM DB2 LUW Version 9 unterstützt eine Vielzahl software- und hardwarebasierter Replikationsverfahren für die verschiedenen Systemumgebungen. Zu den softwarebasierten Verfahren zählen im Besonderen die Verfahren der SQL-Replikation und Q-Replikation sowie das High Availability Disaster Recovery-Verfahren. Auf diese wird 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 IBM DB2 LUW [IBM99]. Im Unterschied zum HADR-Verfahren, welches 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 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 Architektur setzt sich dabei aus verschiedenen Komponenten zusammen, die in der Abbildung 4 schematisch dargestellt sind. Der Einfachheit halber wird im weiteren Verlauf dieses Kapitels das Szenario angenommen, dass jeweils ein Primär- und ein Sekundärsystem 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

16 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, Änderungen an zu replizierenden Daten aus der sogenannten Zwischenspeichertabelle zu 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 IBM DB2 LUW fest. So ist es möglich, dass eine Replikation zwischen verschiedenen relationalen 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 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

17 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 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 Capture- Programm 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 an die Transaktion gekoppelte Ablegung des after image-wertes aus der Protokolldatei in den Hauptspeicher. Hinter dem Begri des after images verbirgt sich dabei das durch 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 Capture- Programm nur die after image-werte. Es ist aber bei der Registrierung der Quelleinheiten möglich, die zusätzliche Speicherung der before image-werte einzustellen. Sobald der Commit-Log-Record (CLR) gefunden wird, entnimmt das Capture-Programm die zur Transaktion gehörenden after image-werte aus dem Hauptspeicher und legt diese mit zusätzlichen Informationen in der Zwischenspeichertabelle ab. Der genaue Aufbau einer Zwischenspeichertabelle wird in Abschnitt betrachtet. Wird die Transaktion dagegen 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 Abbildung 5. Falls auf dem Primärsystem ein anderes DBMS als IBM DB2 LUW eingesetzt wird, gestaltet 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

18 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 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 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, beispielsweise 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 erklärt. Mit der Verarbeitung der geänderten Daten auf dem Sekundärsystem ist ein sogenannter Replikationsdurchlauf abgeschlossen. Die 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

19 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 Zwischenspeichertabelle. (2) Das Apply-Programm kopiert die entnommenen Werte in die Zieleinheit 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 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 Durchführungsintervalls deniert, welches drei verschiedenen Typen entsprechen kann: Intervallsteuerung, Ereignissteuerung oder kontinuierliche Replikation. Unter der Intervallsteuerung versteht man die Festlegung eines einfachen Intervalls, in welchem 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

20 der Benutzer oder das Apply-Programm selbstständig einen Eintrag in einer zum Apply- Programm 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 versteht 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 erklärt 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

Hochverfügbarkeit von TransConnect 2.2

Hochverfügbarkeit von TransConnect 2.2 Hochverfügbarkeit von TransConnect 2.2 und Ausblick Torsten Uhr - SQL Projekt AG Stand September 2012 Inhalt Teil 1 Backup & Restore Virtualisierung Hot-Standby / Fail-Over Teil 2 Ausblick auf zukünftige

Mehr

Relationale Datenbanken Datenbankgrundlagen

Relationale Datenbanken Datenbankgrundlagen Datenbanksystem Ein Datenbanksystem (DBS) 1 ist ein System zur elektronischen Datenverwaltung. Die wesentliche Aufgabe eines DBS ist es, große Datenmengen effizient, widerspruchsfrei und dauerhaft zu speichern

Mehr

Möglichkeiten der E-Mail- Archivierung für Exchange Server 2010 im Vergleich

Möglichkeiten der E-Mail- Archivierung für Exchange Server 2010 im Vergleich Möglichkeiten der E-Mail- Archivierung für Exchange Server 2010 im Vergleich Seit Microsoft Exchange Server 2010 bieten sich für Unternehmen gleich zwei mögliche Szenarien an, um eine rechtskonforme Archivierung

Mehr

In die Zeilen würden die Daten einer Adresse geschrieben werden. Das Ganze könnte in etwa folgendermaßen aussehen:

In die Zeilen würden die Daten einer Adresse geschrieben werden. Das Ganze könnte in etwa folgendermaßen aussehen: 1 Einführung in Datenbanksysteme Fast jeder kennt Excel und hat damit in seinem Leben schon einmal gearbeitet. In Excel gibt es Arbeitsblätter, die aus vielen Zellen bestehen, in die man verschiedene Werte

Mehr

Datensicherheit und Hochverfügbarkeit

Datensicherheit und Hochverfügbarkeit Datensicherheit und Hochverfügbarkeit 1. Instanzfehler Aussage: Instanzfehler werden durch Crash Recovery vom DBS automatisch behandelt. Recovery Zeiten? Ausfall von Speichersubsystem, Rechner,...? Ausfall

Mehr

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

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

Mehr

(früher: Double-Take Backup)

(früher: Double-Take Backup) (früher: Double-Take Backup) Eine minutengenaue Kopie aller Daten am Standort: Damit ein schlimmer Tag nicht noch schlimmer wird Double-Take RecoverNow für Windows (früher: Double-Take Backup) sichert

Mehr

Implementierung von Dateisystemen

Implementierung von Dateisystemen Implementierung von Dateisystemen Teil 2 Prof. Dr. Margarita Esponda WS 2011/2012 44 Effizienz und Leistungssteigerung Festplatten sind eine wichtige Komponente in jedem Rechnersystem und gleichzeitig

Mehr

RAID. Name: Artur Neumann

RAID. Name: Artur Neumann Name: Inhaltsverzeichnis 1 Was ist RAID 3 1.1 RAID-Level... 3 2 Wozu RAID 3 3 Wie werden RAID Gruppen verwaltet 3 3.1 Software RAID... 3 3.2 Hardware RAID... 4 4 Die Verschiedenen RAID-Level 4 4.1 RAID

Mehr

TECHNISCHE PRODUKTINFORMATION CARUSO

TECHNISCHE PRODUKTINFORMATION CARUSO 1111 TECHNISCHE PRODUKTINFORMATION CARUSO TECHNISCHE PRODUKTINFORMATION Seite 0/7 Inhalt 1 Systemdefinition............2 2 Technische Details für den Betrieb von CARUSO......2 2.1 Webserver... 2 2.2 Java

Mehr

Zero Effort Backup (ZEB) automatische Datensicherung über das Internet

Zero Effort Backup (ZEB) automatische Datensicherung über das Internet Ralph Lehmann. Computerservice und IT-Beratung. Kochstraße 34. 04275 Leipzig Ralph Lehmann Computerservice und IT-Beratung Kochstraße 34 04275 Leipzig Ralph Lehmann Computerservice und IT-Beratung Tel.:

Mehr

TAV Übung 3. Übung 3: Verteilte Datenhaltung

TAV Übung 3. Übung 3: Verteilte Datenhaltung Übung 3: Verteilte Datenhaltung 1. Serialisierung Konstruieren Sie Historien aus drei Transaktionen T1, T2 und T3, die folgende Merkmale aufweisen: 1. Die serielle Reihenfolge ist T1 vor T2 vor T3. 2.

Mehr

56 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen. Client Client Client Client Client. Public Network. aktiv. Private Network.

56 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen. Client Client Client Client Client. Public Network. aktiv. Private Network. 56 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen aktiv inaktiv Node 1 ( Aktiv ) Node 2 ( Passiv ) Private Network aktiv inaktiv (exklusiver Zugriff) Abbildung 3.1: Schematische Darstellung

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

Seminar Cloud Data Management WS09/10. Tabelle1 Tabelle2

Seminar Cloud Data Management WS09/10. Tabelle1 Tabelle2 Seminar Cloud Data Management WS09/10 Tabelle1 Tabelle2 1 Einführung DBMS in der Cloud Vergleich verschiedener DBMS Beispiele Microsoft Azure Amazon RDS Amazon EC2 Relational Databases AMIs Was gibt es

Mehr

Microsoft SQL Server 2005 für Administratoren

Microsoft SQL Server 2005 für Administratoren Microsoft SQL Server 2005 für Administratoren Irene Bauder ISBN 3-446-22800-4 Leseprobe Weitere Informationen oder Bestellungen unter http://www.hanser.de/3-446-22800-4 sowie im Buchhandel Sichern von

Mehr

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Dateiname: ecdl5_01_00_documentation_standard.doc Speicherdatum: 14.02.2005 ECDL 2003 Basic Modul 5 Datenbank - Grundlagen

Mehr

dpa-infocom - Datenlieferung

dpa-infocom - Datenlieferung dpa-infocom - Datenlieferung Copyright 2006 von dpa-infocom GmbH Status des Dokuments: FINAL Inhaltsverzeichnis Inhaltsverzeichnis...1 1. Verzeichnisstrukturen...2 2. Nachrichtenmanagement...2 3. Datenübertragung...3

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

PowerBridge MSSQL Beta

PowerBridge MSSQL Beta SoftENGINE PowerBridge MSSQL Beta Dokumentation Thomas Jakob 17.04.2011 Inhalt Einrichtung der SQL Umgebung... 3 SQL-Server Installieren... 3 BüroWARE Installieren... 3 PowerBridge-SQL Modus einrichten...

Mehr

Datensicherung. Beschreibung der Datensicherung

Datensicherung. Beschreibung der Datensicherung Datensicherung Mit dem Datensicherungsprogramm können Sie Ihre persönlichen Daten problemlos Sichern. Es ist möglich eine komplette Datensicherung durchzuführen, aber auch nur die neuen und geänderten

Mehr

E-Interview mit Herrn Dr. Winokur, CTO von Axxana

E-Interview mit Herrn Dr. Winokur, CTO von Axxana E-Interview mit Herrn Dr. Winokur, CTO von Axxana Titel des E-Interviews: Kostengünstige Datenrettung ohne Verlust und über alle Distanzen hinweg wie mit Enterprise Data Recording (EDR) von Axxana eine

Mehr

IT-Kompaktkurs. Datenbanken Skript zur Folge 10. Prof. Dr. Dieter Rummler Fachhochschule Deggendorf

IT-Kompaktkurs. Datenbanken Skript zur Folge 10. Prof. Dr. Dieter Rummler Fachhochschule Deggendorf IT-Kompaktkurs Skript zur Folge 10 Prof. Dr. Dieter Rummler Fachhochschule Deggendorf Client Server Architektur Zunächst zur grundsätzlichen Unterscheidung zwischen File-Server Datenbank und Server-Datenbank

Mehr

Wiederherstellung (Recovery)

Wiederherstellung (Recovery) Fragestellungen Aufgaben der Komponenten für das Recovery: Sicherstellung der Dauerhaftigkeit der gespeicherten Daten, d.h. Daten, die in einer Transaktion einmal bestätigt wurden (commit), bleiben auch

Mehr

Änderungen erkennen Schneller handeln Stefan Panek. Senior Consultant Christoph Jansen. Consultant 23.10.2008

Änderungen erkennen Schneller handeln Stefan Panek. Senior Consultant Christoph Jansen. Consultant 23.10.2008 Änderungen erkennen Schneller handeln Stefan Panek. Senior Consultant Christoph Jansen. Consultant 23.10.2008 Seit der Datenbankversion 9i bietet Oracle das Feature Change Data Capture an. Aber was genau

Mehr

Themen. M. Duffner: Datenbanksysteme

Themen. M. Duffner: Datenbanksysteme Datenbanksysteme Themen Theorie Einführung Datenbank, Datenbankmanagementsystem (DBMS), Aufgaben eines DBMS Relationale Datenbanken Daten als Tabellen Datenbankentwurf im Entity-Relationship-Modell Abfragesprache

Mehr

DEN TSM SERVER HOCHVERFÜGBAR MACHEN. Tipps zur Realisierung

DEN TSM SERVER HOCHVERFÜGBAR MACHEN. Tipps zur Realisierung DEN TSM SERVER HOCHVERFÜGBAR MACHEN Tipps zur Realisierung AGENDA 01 Ist eine HA-Lösung für TSM erforderlich 02 Besonderheiten bei TSM Version 6 03 Methoden der Absicherung des TSM-Betriebs 04 Entscheidungskriterien

Mehr

Musterlösung Übungsblatt 1 Netzprogrammierung WS 05/06

Musterlösung Übungsblatt 1 Netzprogrammierung WS 05/06 Musterlösung Übungsblatt 1 Netzprogrammierung WS 05/06 Block Verteilte Systeme und Middleware 1. Beschreiben Sie die Entwicklung verteilter Systeme von einer Zentralisierung bis zu Peer-to-Peer. Nicht

Mehr

sedex-client Varianten für den Betrieb in einer hoch verfügbaren

sedex-client Varianten für den Betrieb in einer hoch verfügbaren Département fédéral de l'intérieur DFI Office fédéral de la statistique OFS Division Registres Team sedex 29.07.2014, version 1.0 sedex-client Varianten für den Betrieb in einer hoch verfügbaren Umgebung

Mehr

Heterogenes Speichermanagement mit V:DRIVE

Heterogenes Speichermanagement mit V:DRIVE Heterogenes Speichermanagement mit V:DRIVE V:DRIVE - Grundlage eines effizienten Speichermanagements Die Datenexplosion verlangt nach innovativem Speichermanagement Moderne Businessprozesse verlangen auf

Mehr

whitepaper CLOUD-ENTWICKLUNG: BESTE METHODEN UND SUPPORT-ANWENDUNGEN

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

Mehr

2. DFG- Workshop 3.1. Erfassung/Bewertung/Transfer. Beitrag von Peter Küsters. Spiegelung. Archiv. Bild 1: Unterschied zwischen FTP und Spiegelung

2. DFG- Workshop 3.1. Erfassung/Bewertung/Transfer. Beitrag von Peter Küsters. Spiegelung. Archiv. Bild 1: Unterschied zwischen FTP und Spiegelung 2. DFG- Workshop 3.1. Erfassung/Bewertung/Transfer Beitrag von Peter Küsters Formen des Datentransfers bei der Erfassung von Websites Im folgenden werden Methoden und Software zur Erfassung vorgestellt.

Mehr

Migrationsanleitung von 2.0 auf 2.1

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

Mehr

Unterabfragen (Subqueries)

Unterabfragen (Subqueries) Unterabfragen (Subqueries) Die kürzeste Formulierung ist folgende: SELECT Felderliste FROM Tabelle1 WHERE Tabelle1.Feldname Operator (SELECT Feldname FROM Tabelle2 WHERE Bedingung); wobei Tabelle1 und

Mehr

Rechtssichere E-Mail-Archivierung

Rechtssichere E-Mail-Archivierung Rechtssichere E-Mail-Archivierung Rechtliche Sicherheit für Ihr Unternehmen Geltende rechtliche Anforderungen zwingen Unternehmen in Deutschland, Österreich und der Schweiz, E-Mails über viele Jahre hinweg

Mehr

VoIPcom Supportpakete

VoIPcom Supportpakete VoIPcom Supportpakete bietet drei verschiedene Supportpakete an. Anrecht auf das Supportpaket Silber haben grundsätzlich alle Kunden, welche eine VoIPcom Telefonanlage im Einsatz haben. Für Firmenkunden

Mehr

Handbuch Version 1.02 (August 2010)

Handbuch Version 1.02 (August 2010) Handbuch Version 1.02 (August 2010) Seite 1/27 Inhaltsverzeichnis 1. Einleitung 1.1. Begrüßung 03 1.2. Was ist PixelX Backup FREE / PRO 03 1.3. Warum sollten Backups mittels einer Software erstellt werden?

Mehr

Die maßgeschneiderte IT-Infrastruktur aus der Südtiroler Cloud

Die maßgeschneiderte IT-Infrastruktur aus der Südtiroler Cloud Die maßgeschneiderte IT-Infrastruktur aus der Südtiroler Cloud Sie konzentrieren sich auf Ihr Kerngeschäft und RUN AG kümmert sich um Ihre IT-Infrastruktur. Vergessen Sie das veraltetes Modell ein Server,

Mehr

VMware Schutz mit NovaBACKUP BE Virtual

VMware Schutz mit NovaBACKUP BE Virtual VMware Schutz mit NovaBACKUP BE Virtual Anforderungen, Konfiguration und Restore-Anleitung Ein Leitfaden (September 2011) Inhalt Inhalt... 1 Einleitung... 2 Zusammenfassung... 3 Konfiguration von NovaBACKUP...

Mehr

Perzentile mit Hadoop ermitteln

Perzentile mit Hadoop ermitteln Perzentile mit Hadoop ermitteln Ausgangspunkt Ziel dieses Projektes war, einen Hadoop Job zu entwickeln, der mit Hilfe gegebener Parameter Simulationen durchführt und aus den Ergebnissen die Perzentile

Mehr

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector 7.4 Analyse anhand der SQL-Trace 337 7.3.5 Vorabanalyse mit dem Code Inspector Der Code Inspector (SCI) wurde in den vorangegangenen Kapiteln immer wieder erwähnt. Er stellt ein paar nützliche Prüfungen

Mehr

Dell Data Protection Solutions Datensicherungslösungen von Dell

Dell Data Protection Solutions Datensicherungslösungen von Dell Dell Data Protection Solutions Datensicherungslösungen von Dell André Plagemann SME DACH Region SME Data Protection DACH Region Dell Softwarelösungen Vereinfachung der IT. Minimierung von Risiken. Schnellere

Mehr

Sichere Daten mit OSL Storage Cluster

Sichere Daten mit OSL Storage Cluster Sichere Daten mit OSL Storage Cluster Alternative Konzepte für die Datensicherung und Katastrophenvorsorge Dipl.-Ing. Torsten Pfundt Gliederung Voraussetzungen für die Konzepte und Lösungen restorefreies

Mehr

KitMig Flexible Live-Migration in mandantenfähigen Datenbanksystemen

KitMig Flexible Live-Migration in mandantenfähigen Datenbanksystemen KitMig Flexible Live-Migration in mandantenfähigen Datenbanksystemen Andreas Göbel, Marcel Sufryd Friedrich-Schiller-Universität Jena AGENDA 1. Mandantenfähige DBMS 2. Live-Migration 3. KitMig 4. Untersuchungen

Mehr

Betriebssysteme K_Kap11C: Diskquota, Raid

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

Mehr

Handbuch Datensicherung

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

Mehr

Replikation in Datenbanken

Replikation in Datenbanken Replikation in Datenbanken Vortrag: Datenbanken II Yves Adler Hochschule für Technik, Wirtschaft und Kultur Leipzig Fachbereich Informatik, Mathematik und Naturwissenschaften Y. Adler (HTWK Leipzig) Replikation

Mehr

Leitfaden Datensicherung und Datenrücksicherung

Leitfaden Datensicherung und Datenrücksicherung Leitfaden Datensicherung und Datenrücksicherung Inhaltsverzeichnis 1. Einführung - Das Datenbankverzeichnis von Advolux... 2 2. Die Datensicherung... 2 2.1 Advolux im lokalen Modus... 2 2.1.1 Manuelles

Mehr

Konzept für eine Highperformance- und Hochverfügbarkeitslösung für. einen Anbieter von Krankenhaus Abrechnungen

Konzept für eine Highperformance- und Hochverfügbarkeitslösung für. einen Anbieter von Krankenhaus Abrechnungen Konzept für eine Highperformance- und Hochverfügbarkeitslösung für Anforderungen : einen Anbieter von Krankenhaus Abrechnungen Es soll eine Cluster Lösung umgesetzt werden, welche folgende Kriterien erfüllt:

Mehr

SmartExporter 2013 R1

SmartExporter 2013 R1 Die aktuelle Version wartet mit zahlreichen neuen Features und umfangreichen Erweiterungen auf. So können mit SmartExporter 2013 R1 nun auch archivierte Daten extrahiert und das Herunterladen der Daten

Mehr

Einsatz von Replikation. Florian Munz

Einsatz von Replikation. Florian Munz Einsatz von Replikation Florian Munz Agenda Wofür braucht man Replikation? Anwendungsszenarien Wie funktioniert Replikation? Konsistenzbegriff und Strategien Wie implementiert man Replikation? Lösungen

Mehr

Alle Metadaten werden in Dateien gehalten

Alle Metadaten werden in Dateien gehalten 6 Beispiel: Windows NT (NTFS) 6.3 Metadaten 6.3 Metadaten Alle Metadaten werden in Dateien gehalten Indexnummer 0 1 2 3 4 5 6 7 8 16 17 MFT MFT Kopie (teilweise) Log File Volume Information Attributtabelle

Mehr

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

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

Mehr

Eine Software für verschiedene Repositorien

<MyCoRe> Eine Software für verschiedene Repositorien 100. Deutscher Bibliothekartag in Berlin Eine Software für verschiedene Repositorien Dr. Wiebke Oeltjen Universität Hamburg www.mycore.de Das Konzept von MyCoRe Ein Software-Kern viele Anwendungen

Mehr

Shibboleth Clustering und Loadbalancing

Shibboleth Clustering und Loadbalancing Shibboleth Clustering und Loadbalancing STEINBUCH CENTRE FOR COMPUTING - SCC KIT Universität des Landes Baden-Württemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft www.kit.edu Computercluster

Mehr

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

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

Mehr

Verteiltes Backup. Einleitung Grundlegende Backup Techniken Backup in Netzwerken. Client/Server Peer-to-Peer

Verteiltes Backup. Einleitung Grundlegende Backup Techniken Backup in Netzwerken. Client/Server Peer-to-Peer Verteiltes Backup Einleitung Grundlegende Backup Techniken Backup in Netzwerken Client/Server Peer-to-Peer Einleitung Backup: Das teilweise oder gesamte Kopieren der in einem Computersystem vorhandenen

Mehr

Win7Deploy Seite 2 von 17. Was ist Win7Deploy?

Win7Deploy Seite 2 von 17. Was ist Win7Deploy? Win7Deploy Seite 1 von 17 Win7Deploy Eine einfache, passgenaue und kostengünstige Lösung um Windows 7 in Ihrem Unternehmen einzuführen [ www.win7deploy.de ] Ablauf einer Win7Deploy Installation am Beispiel

Mehr

IBM Informix Dynamic Server Hochverfügbarkeits-Technologien unter Unix

IBM Informix Dynamic Server Hochverfügbarkeits-Technologien unter Unix 2 IBM Informix Dynamic Server Hochverfügbarkeits-Technologien unter Unix Version: 11.02 ORDIX Seminarunterlagen einfach. gut. geschult. Dieses Dokument wird durch die veröffentlicht. Copyright. Alle Rechte

Mehr

Eine Architekturfür ausfallsicheresysteme in standortübergreifenden Multiserver-Umgebungen

Eine Architekturfür ausfallsicheresysteme in standortübergreifenden Multiserver-Umgebungen Eine Architekturfür ausfallsicheresysteme in standortübergreifenden Multiserver-Umgebungen Andree de Boer sd&m AG Lübecker Str. 128 22087 Hamburg andree.de.boer@sdm.de Abstract: Die Konstruktion ausfallsicherer

Mehr

[DIA] Webinterface 2.4

[DIA] Webinterface 2.4 [DIA] Webinterface 2.4 2 Inhalt Inhalt... 2 1. Einleitung... 3 2. Konzept... 4 2.1 Vorteile und Anwendungen des... 4 2.2 Integration in bestehende Systeme und Strukturen... 4 2.3 Verfügbarkeit... 5 3.

Mehr

Hardware- und Software-Anforderungen IBeeS.ERP

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

Mehr

Astaro Mail Archiving Service Version 1.0

Astaro Mail Archiving Service Version 1.0 Astaro Mail Archiving Service Version 1.0 Verfahrensdokumentation Inhaltsverzeichnis 1. Einleitung... 2 2. Übersicht... 2 2.1 Production-Cloud... 3 2.2 Backup-Cloud... 3 2.3 Control-Cloud... 3 2.4 Zugangsschutz...

Mehr

Lokales Storage Teil 1

Lokales Storage Teil 1 Lokales Storage Teil 1 Zinching Dang 08. Juli 2015 1 Lokales Storage im Allgemeinen Lokales Storage im Allgemeinen Datenträger, die direkt am Host angeschlossen sind Anbindung über verschiedene Bus-Systeme

Mehr

Storage as a Service im DataCenter

Storage as a Service im DataCenter Storage as a Service im DataCenter Agenda Definition Storage as a Service Storage as a Service und IT-Sicherheit Anwendungsmöglichkeiten und Architektur einer Storage as a Service Lösung Datensicherung

Mehr

Effizientes Änderungsmanagement in Outsourcing- Projekten

Effizientes Änderungsmanagement in Outsourcing- Projekten Effizientes Änderungsmanagement in Outsourcing- Projekten Dr. Henning Sternkicker Rational Software IBM Deutschland GmbH Sittarder Straße 31 52078 Aachen henning.sternkicker@de.ibm.com Abstract: Es werden

Mehr

SQL- & NoSQL-Datenbanken - Speichern und Analysen von großen Datenmengen

SQL- & NoSQL-Datenbanken - Speichern und Analysen von großen Datenmengen SQL- & NoSQL-Datenbanken - Speichern und Analysen von großen Datenmengen Lennart Leist Inhaltsverzeichnis 1 Einführung 2 1.1 Aufgaben einer Datenbank...................... 2 1.2 Geschichtliche Entwicklung

Mehr

Datensicherungskonzept Westfälische Hochschule

Datensicherungskonzept Westfälische Hochschule Datensicherungskonzept Westfälische Hochschule -ZIM- Rev. 1.00 Stand: 04.04.2014 Revisionsstände Revisionsstand Kommentar 1.00 Erste Version Seite 2 1 Einleitung Das Datensicherungskonzept dient zur Dokumentation

Mehr

Transaktionsverwaltung

Transaktionsverwaltung Transaktionsverwaltung VU Datenbanksysteme vom 21.10. 2015 Reinhard Pichler Arbeitsbereich Datenbanken und Artificial Intelligence Institut für Informationssysteme Technische Universität Wien Transaktionsverwaltung

Mehr

Einführung in SQL Datenbanken bearbeiten

Einführung in SQL Datenbanken bearbeiten Einführung in SQL Datenbanken bearbeiten Jürgen Thomas Entstanden als Wiki-Buch Bibliografische Information Diese Publikation ist bei der Deutschen Nationalbibliothek registriert. Detaillierte Angaben

Mehr

Konzeption eines Master-Data-Management-Systems. Sven Schilling

Konzeption eines Master-Data-Management-Systems. Sven Schilling Konzeption eines Master-Data-Management-Systems Sven Schilling Gliederung Teil I Vorstellung des Unternehmens Thema der Diplomarbeit Teil II Master Data Management Seite 2 Teil I Das Unternehmen Vorstellung

Mehr

Vorteile der E-Mail-Archivierung

Vorteile der E-Mail-Archivierung Die E-Mail stellt für die meisten Unternehmen nicht nur das wichtigste Kommunikationsmedium, sondern auch eine der wertvollsten Informationsressourcen dar. Per E-Mail übertragene Informationen werden in

Mehr

Reflection 14.1 SP3 Update 1: Versionshinweise

Reflection 14.1 SP3 Update 1: Versionshinweise Reflection 14.1 SP3 Update 1: Versionshinweise Technischer Hinweis 2725 Stand vom 18. April 2014 Gilt für Reflection for HP with NS/VT Version 14.x Reflection for IBM Version 14.x Reflection for UNIX and

Mehr

Online Help StruxureWare Data Center Expert

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

Mehr

Lastenheft. Zielbestimmungen. Produkteinsatz. swp11-4. 3. Mai 2011. Franz Teichmann, Robert Röÿling swp11-4 3. Mai 2011

Lastenheft. Zielbestimmungen. Produkteinsatz. swp11-4. 3. Mai 2011. Franz Teichmann, Robert Röÿling swp11-4 3. Mai 2011 Lastenheft swp11-4 3. Mai 2011 Zielbestimmungen In der heutigen Geschäftswelt stehen mittelständische Unternehmen vor dem Dilemma, einerseits interne und externe Kommunikation in angemessener Weise gewährleisten

Mehr

2. Braunschweiger Linux-Tage. Vortrag über RAID. von. Thomas King. http://www.t-king.de/linux/raid1.html. 2. Braunschweiger Linux-Tage Seite 1/16

2. Braunschweiger Linux-Tage. Vortrag über RAID. von. Thomas King. http://www.t-king.de/linux/raid1.html. 2. Braunschweiger Linux-Tage Seite 1/16 2. Braunschweiger Linux-Tage Vortrag über RAID von Thomas King http://www.t-king.de/linux/raid1.html 2. Braunschweiger Linux-Tage Seite 1/16 Übersicht: 1. Was ist RAID? 1.1. Wo wurde RAID entwickelt? 1.2.

Mehr

Replikation mit TeraStation 3000/4000/5000/7000. Buffalo Technology

Replikation mit TeraStation 3000/4000/5000/7000. Buffalo Technology Replikation mit TeraStation 3000/4000/5000/7000 Buffalo Technology Einführung Durch Replikation wird ein Ordner in zwei separaten TeraStations fast in Echtzeit synchronisiert. Dies geschieht nur in einer

Mehr

Fehlerbehandlung (Recovery)

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

Mehr

Projektphasen und Technische Vorbereitung eines NX Refiles mit dem PLMJobManager

Projektphasen und Technische Vorbereitung eines NX Refiles mit dem PLMJobManager Projektphasen und Technische Vorbereitung eines NX Refiles mit dem PLMJobManager Dieses Dokument dient zur Information über die Organisation der Projektphasen und der technischen Vorbereitung eines Refile

Mehr

MySQL Replikationstechnologien

MySQL Replikationstechnologien MySQL Replikationstechnologien Lenz Grimmer MySQL Community Relations Specialist $ whoami 1998 2002 2008 2010 Agenda Replikation: Definition und Klassifizierung Anwendungsgebiete

Mehr

Die wichtigsten Vorteile von SEPPmail auf einen Blick

Die wichtigsten Vorteile von SEPPmail auf einen Blick Die wichtigsten Vorteile von SEPPmail auf einen Blick August 2008 Inhalt Die wichtigsten Vorteile von SEPPmail auf einen Blick... 3 Enhanced WebMail Technologie... 3 Domain Encryption... 5 Queue-less Betrieb...

Mehr

Alles Spricht von RAID-Verband

Alles Spricht von RAID-Verband Alles Spricht von RAID-Verband Der Begriff "RAID" fiel in der Vergangenheit lediglich in dem Zusammenhang von Server-PC's. Doch heutzutage, wo die PC-Hardware immer günstiger werden und das Interesse an

Mehr

Handbuch zu AS Connect für Outlook

Handbuch zu AS Connect für Outlook Handbuch zu AS Connect für Outlook AS Connect für Outlook ist die schnelle, einfache Kommunikation zwischen Microsoft Outlook und der AS Datenbank LEISTUNG am BAU. AS Connect für Outlook Stand: 02.04.2013

Mehr

Storage Management Konzepte

Storage Management Konzepte Storage Management Konzepte Der Trend, dass Information immer und überall auf der Welt zur Verfügung stehen müssen wie auch der stetig steigende Speicherbedarf stellen neue Anforderungen an die Datenspeicherung

Mehr

IBM Software Group. IBM Tivoli Continuous Data Protection for Files

IBM Software Group. IBM Tivoli Continuous Data Protection for Files IBM Software Group IBM Tivoli Continuous Data Protection for Files Inhaltsverzeichnis 1 IBM Tivoli CDP for Files... 3 1.1 Was ist IBM Tivoli CDP?... 3 1.2 Features... 3 1.3 Einsatzgebiet... 4 1.4 Download

Mehr

Klausur Datenbanksysteme

Klausur Datenbanksysteme Prüfung Datenbanksysteme, 31.Jan. 2003 S. 1 Klausur Datenbanksysteme Name: Matrikel-Nr.: Studiengang: Aufgabenblatt nicht vor Beginn der Prüfung umdrehen! Prüfer: Prof. Dr. Martin Hulin Dauer: 90 Minuten

Mehr

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 378

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 378 DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN Nr. 378 Umsetzung ausgewählter Supply-Chain-Operations-Reference-Metriken durch das

Mehr

Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH

Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH Complex Hosting Autor.: Monika Olschewski Whitepaper Version: 1.0 Erstellt am: 14.07.2010 ADACOR Hosting GmbH Kaiserleistrasse 51 63067 Offenbach am Main info@adacor.com www.adacor.com Complex Hosting

Mehr

Backup und Restore von Oracle- Datenbanken in Niederlassungen

Backup und Restore von Oracle- Datenbanken in Niederlassungen Regionaltreffen München/Südbayern am Dienstag, 07.07.2008, 17:00 Uhr Backup und Restore von Oracle- Datenbanken in Niederlassungen Entfernte DBs einfach sichern Ihr Partner für Schulung, Betreuung und

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

Top-Themen. Office 365: So funktioniert die E-Mail-Archivierung... 2. Seite 1 von 16

Top-Themen. Office 365: So funktioniert die E-Mail-Archivierung... 2. Seite 1 von 16 Top-Themen Office 365: So funktioniert die E-Mail-Archivierung... 2 Seite 1 von 16 Schritt-für-Schritt-Anleitung Office 365: So funktioniert die E-Mail- Archivierung von Thomas Joos Seite 2 von 16 Inhalt

Mehr

Acronis Backup Advanced für Citrix XenServer

Acronis Backup Advanced für Citrix XenServer Acronis Backup Advanced für Citrix XenServer Vollständiges Backup und Recovery für Ihre Citrix XenServer- Umgebung! Schützen Sie Ihre komplette Citrix XenServer-Umgebung mit effizienten Backups in einem

Mehr

20 Vorgehensweise bei einem geplanten Rechnerwechsel... 2 20.1 Allgemein... 2 20.2 Rechnerwechsel bei einer Einzelplatzlizenz... 2 20.2.

20 Vorgehensweise bei einem geplanten Rechnerwechsel... 2 20.1 Allgemein... 2 20.2 Rechnerwechsel bei einer Einzelplatzlizenz... 2 20.2. 20 Vorgehensweise bei einem geplanten Rechnerwechsel... 2 20.1 Allgemein... 2 20.2 Rechnerwechsel bei einer Einzelplatzlizenz... 2 20.2.1 Schritt 1: Datensicherung... 2 20.2.2 Schritt 2: Registrierung

Mehr

Einsatz der Mehrkörpersimulation in Verbindung mit Computertomographie in der Produktentwicklung

Einsatz der Mehrkörpersimulation in Verbindung mit Computertomographie in der Produktentwicklung Einsatz der Mehrkörpersimulation in Verbindung mit Computertomographie in der Produktentwicklung Hintergrund Bei komplexen Baugruppen ergeben sich sehr hohe Anforderungen an die Tolerierung der einzelnen

Mehr

1. Installation und Inbetriebnahme pcon.update

1. Installation und Inbetriebnahme pcon.update Manual pcon.update 1. Installation und Inbetriebnahme pcon.update Unter nachfolgendem Link können Sie die erforderliche Software pcon.update herunterladen. ftp://ftpdownload:download-9200@ftp.weber-os.ch/download/pcon/update/p-up-

Mehr

Datenbanken: Backup und Recovery

Datenbanken: Backup und Recovery Der Prozess der Wiederherstellung der Daten einer Datenbank nach einem Fehler im laufenden Betrieb in einen konsistenten, möglichst verlustfreien Zustand heißt Recovery. Beteiligt an diesem Recovery sind

Mehr

Dokumentation QuickHMI-Schnittstelle. Datenbanken

Dokumentation QuickHMI-Schnittstelle. Datenbanken Dokumentation QuickHMI-Schnittstelle für SQLServer Datenbanken Version 1.0 D-28359 Bremen info@indi-systems.de Tel + 49 421-989703-30 Fax + 49 421-989703-39 Inhaltsverzeichnis Was ist die QuickHMI-Schnittstelle

Mehr

Documentation. OTRS Appliance Installationshandbuch. Build Date:

Documentation. OTRS Appliance Installationshandbuch. Build Date: Documentation OTRS Appliance Installationshandbuch Build Date: 10.12.2014 OTRS Appliance Installationshandbuch Copyright 2001-2014 OTRS AG Dieses Werk ist geistiges Eigentum der OTRS AG. Es darf als Ganzes

Mehr

dogado Support Policies Stand: 01. Dezember 2014, Version 1.06

dogado Support Policies Stand: 01. Dezember 2014, Version 1.06 dogado Support Policies Stand: 01. Dezember 2014, Version 1.06 Version 1.06 - Seite 1 von 10 Inhaltsverzeichnis dogado Support Policies... 3 dogado Geschäftszeiten und Erreichbarkeit... 3 Schweregrade

Mehr

Design und Realisierung von E-Business- und Internet-Anwendungen! " # $ %& # ' ( ( )

Design und Realisierung von E-Business- und Internet-Anwendungen!  # $ %& # ' ( ( ) Design und Realisierung von E-Business- und Internet-Anwendungen! " # $ %& # ' ( ( ) Seite 2 Agenda. Was haben wir letzte Woche gemacht? Die IT Infrastructure Library (ITIL) Die Prozesse des Service Support

Mehr