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

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem

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

Mehr

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

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

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

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

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

StorageCraft ImageManager ist eine voll ausgereifte Ergänzung zu

StorageCraft ImageManager ist eine voll ausgereifte Ergänzung zu Produktszenarien Was kann das Produkt für Sie tun? ist eine voll ausgereifte Ergänzung zu StorageCraft ShadowProtect, mit deren Hilfe Sie von einer einfachen Backup- und Wiederherstellungslösung zu einer

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

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

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

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

4 Grundlagen der Datenbankentwicklung

4 Grundlagen der Datenbankentwicklung 4 Grundlagen der Datenbankentwicklung In diesem Kapitel werden wir die Grundlagen der Konzeption von relationalen Datenbanken beschreiben. Dazu werden Sie die einzelnen Entwicklungsschritte von der Problemanalyse

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

(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

Leitfaden zur Installation von BitByters.Backup

Leitfaden zur Installation von BitByters.Backup Leitfaden zur Installation von BitByters.Backup Der BitByters.Backup - DASIService ist ein Tool mit dem Sie Ihre Datensicherung organisieren können. Es ist nicht nur ein reines Online- Sicherungstool,

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

c o m p e t e n c e : d a t a m a n a g e m e n t

c o m p e t e n c e : d a t a m a n a g e m e n t c o m p e t e n c e : d a t a m a n a g e m e n t ... alle Daten sind gesichert, aber nur einen Klick entfernt. Sie haben nie mehr Sorgen wegen eines Backups. Ihre Daten sind auch bei einem Hardware-Ausfall

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

Memeo Instant Backup Kurzleitfaden. Schritt 1: Richten Sie Ihr kostenloses Memeo-Konto ein

Memeo Instant Backup Kurzleitfaden. Schritt 1: Richten Sie Ihr kostenloses Memeo-Konto ein Einleitung Memeo Instant Backup ist eine einfache Backup-Lösung für eine komplexe digitale Welt. Durch automatisch und fortlaufende Sicherung Ihrer wertvollen Dateien auf Ihrem Laufwerk C:, schützt Memeo

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

PADS 3.0 Viewer - Konfigurationen

PADS 3.0 Viewer - Konfigurationen PADS 3.0 Viewer - Konfigurationen Net Display Systems (Deutschland) GmbH - Am Neuenhof 4-40629 Düsseldorf Telefon: +49 211 9293915 - Telefax: +49 211 9293916 www.fids.de - email: info@fids.de Übersicht

Mehr

Synchronisation von redundanten Datenbeständen

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

Mehr

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

1 Lieferantenbewertung

1 Lieferantenbewertung 1 Lieferantenbewertung Mit Hilfe der Lieferantenbewertung können alle aktiven Lieferanten nach ISO Kriterien bewertet werden. Die zur Bewertung hinterlegten Faktoren können individuell vorgegeben werden.

Mehr

Ersatzteile der Extraklasse Magento-Module der Shopwerft

Ersatzteile der Extraklasse Magento-Module der Shopwerft Ersatzteile der Extraklasse Magento-Module der Shopwerft MicroStudio - Fotolia.com Werden von Kunden oder Suchmaschinen Elemente des Shops aufgerufen, die nicht vorhanden sind, wird statt des gewünschten

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

Software-Engineering und Datenbanken

Software-Engineering und Datenbanken Software-Engineering und Datenbanken Prof. Dr. Bernhard Schiefer bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer Prof. Dr. Bernhard Schiefer 1-1 Wesentliche Inhalte Begriff DBS Datenbankmodelle

Mehr

Datenbanken. Prof. Dr. Bernhard Schiefer. bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer

Datenbanken. Prof. Dr. Bernhard Schiefer. bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer Datenbanken Prof. Dr. Bernhard Schiefer bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer Wesentliche Inhalte Begriff DBS Datenbankmodelle Datenbankentwurf konzeptionell, logisch und relational

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

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

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

Datenbanksysteme für Business, Technologie und Web. Nutzerdefinierte Replikation zur Realisierung neuer mobiler Datenbankanwendungen DB I S

Datenbanksysteme für Business, Technologie und Web. Nutzerdefinierte Replikation zur Realisierung neuer mobiler Datenbankanwendungen DB I S Datenbanksysteme für Business, Technologie und Web Nutzerdefinierte Replikation zur Realisierung neuer mobiler Datenbankanwendungen DB I S Christoph Gollmick gollmick@informatik.uni-jena.de Friedrich-Schiller-Universität

Mehr

Normfall 7.2. Whitepaper. Erstellen eines Normfall Projektspeichers auf Basis einer vorhandenen Installation von:

Normfall 7.2. Whitepaper. Erstellen eines Normfall Projektspeichers auf Basis einer vorhandenen Installation von: Normfall 7.2 Whitepaper Erstellen eines Normfall Projektspeichers auf Basis einer vorhandenen Installation von: Microsoft SQL Server 2008 R2/2012/2014 2014 Normfall GmbH Alle Rechte vorbehalten. Vorbemerkungen

Mehr

THEMA: CLOUD SPEICHER

THEMA: CLOUD SPEICHER NEWSLETTER 03 / 2013 THEMA: CLOUD SPEICHER Thomas Gradinger TGSB IT Schulung & Beratung Hirzbacher Weg 3 D-35410 Hungen FON: +49 (0)6402 / 504508 FAX: +49 (0)6402 / 504509 E-MAIL: info@tgsb.de INTERNET:

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

Acronis TrueImage (Version 7.0) Benutzerführung. genutzte Quelle: http://www.acronis.de / Hilfedatei zum Programm Acronis TrueImage Version 7.

Acronis TrueImage (Version 7.0) Benutzerführung. genutzte Quelle: http://www.acronis.de / Hilfedatei zum Programm Acronis TrueImage Version 7. Hier finden Sie von der Firma GriCom Wilhelmshaven eine, um ein Backup Ihres Computers / Ihrer Festplatten zu erstellen und dieses Backup bei Bedarf zur Wiederherstellung zu nutzen. Diese Bedienerführung

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

Anleitung. Dateiensynchronisation zwischen zwei. PC s bzw. NMS-Instanzen

Anleitung. Dateiensynchronisation zwischen zwei. PC s bzw. NMS-Instanzen Anleitung Dateiensynchronisation zwischen zwei Version 1.0 vom 25. März 2010 Änderungen vorbehalten 1/21 Inhaltsverzeichnis 1 Überblick... 3 2 Synchronisationswerkzeug... 4 2.1 Beschreibung... 4 2.2 Quelle...

Mehr

Scopevisio AG Abteilung Auftragsdatenverarbeitung Rheinwerkallee 3

Scopevisio AG Abteilung Auftragsdatenverarbeitung Rheinwerkallee 3 Scopevisio AG Abteilung Auftragsdatenverarbeitung Rheinwerkallee 3 53227 Bonn Copyright Scopevisio AG. All rights reserved. Seite 1 von 11 Copyright Scopevisio AG. All rights reserved. Seite 2 von 11 Inhalt

Mehr

Datenbanken: Architektur & Komponenten 3-Ebenen-Architektur

Datenbanken: Architektur & Komponenten 3-Ebenen-Architektur Datenbanken: Architektur & Komponenten 3-Ebenen-Architektur Moderne Datenbanksysteme sind nach der 3-Ebenen-Architektur gebaut: Anwendung 1 Web-Anwendung Anwendung 2 Java-Programm... Anwendung n Applikation

Mehr

Ein Schlüssel ist eine Menge von Attributen (also eines oder mehrere), die eine Datenzeile (Tupel) einer Tabelle eindeutig identifiziert

Ein Schlüssel ist eine Menge von Attributen (also eines oder mehrere), die eine Datenzeile (Tupel) einer Tabelle eindeutig identifiziert Maika Büschenfeldt Datenbanken: Skript 1 1. Was ist eine relationale Datenbank? In Datenbanken können umfangreiche Datenbestände strukturiert abgelegt werden. Das Konzept relationaler Datenbanken soll

Mehr

Software Requirements Specification

Software Requirements Specification Software Requirements Specification Identifikation von Sehenswürdigkeiten basierend auf Bildinhalten Iterationsschritt: 3 Abgabedatum: 08.06.2010 Gruppe 37: Matthias Hochsteger 0627568 Josef Kemetmüller

Mehr

Lizenzierung von SQL Server 2014

Lizenzierung von SQL Server 2014 Lizenzierung von SQL Server 2014 SQL Server 2014 bietet zwei Lizenzoptionen: das Core-basierte Lizenzmodell, dessen Maßeinheit die Anzahl der Prozessorkerne und damit die Rechenleistung der Server-Hardware

Mehr

Einführung. Informationssystem als Abbild der realen Welt

Einführung. Informationssystem als Abbild der realen Welt Was ist ein Datenbanksystem? Anwendungsgrundsätze Betrieb von Datenbanksystemen Entwicklung von Datenbanksystemen Seite 1 Informationssystem als Abbild der realen Welt Modellierung (Abstraktion) Sachverhalte

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

Installationsanleitung für den Online-Backup Client

Installationsanleitung für den Online-Backup Client Installationsanleitung für den Online-Backup Client Inhalt Download und Installation... 2 Login... 4 Konfiguration... 5 Erste Vollsicherung ausführen... 7 Webinterface... 7 FAQ Bitte beachten sie folgende

Mehr

Benutzerdokumentation Hosted Backup Services Client

Benutzerdokumentation Hosted Backup Services Client Benutzerdokumentation Hosted Backup Services Client Geschäftshaus Pilatushof Grabenhofstrasse 4 6010 Kriens Version 1.1 28.04.2014 Inhaltsverzeichnis 1 Einleitung 4 2 Voraussetzungen 4 3 Installation 5

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

COLLECTION. Installation und Neuerungen. Märklin 00/H0 Jahresversion 2009. Version 7. Die Datenbank für Sammler

COLLECTION. Installation und Neuerungen. Märklin 00/H0 Jahresversion 2009. Version 7. Die Datenbank für Sammler Die Datenbank für Sammler COLLECTION Version 7 Installation und Neuerungen Märklin 00/H0 Jahresversion 2009 Stand: April 2009 Inhaltsverzeichnis Inhaltsverzeichnis... 2 VORWORT... 3 Hinweise für Anwender,

Mehr

XAMPP-Systeme. Teil 3: My SQL. PGP II/05 MySQL

XAMPP-Systeme. Teil 3: My SQL. PGP II/05 MySQL XAMPP-Systeme Teil 3: My SQL Daten Eine Wesenseigenschaft von Menschen ist es, Informationen, in welcher Form sie auch immer auftreten, zu ordnen, zu klassifizieren und in strukturierter Form abzulegen.

Mehr

IBM SPSS Data Access Pack Installationsanweisung für Windows

IBM SPSS Data Access Pack Installationsanweisung für Windows IBM SPSS Data Access Pack Installationsanweisung für Windows Inhaltsverzeichnis Kapitel 1. Übersicht.......... 1 Einführung............... 1 Bereitstellen einer Datenzugriffstechnologie.... 1 ODBC-Datenquellen...........

Mehr

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

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

Mehr

Datenintegrität und Transaktionskonzept

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

Mehr

Microsoft Office 2010

Microsoft Office 2010 Microsoft Office 2010 Office-Anpassungstool Author(s): Paolo Sferrazzo Version: 1.0 Erstellt am: 15.06.12 Letzte Änderung: - 1 / 12 Hinweis: Copyright 2006,. Alle Rechte vorbehalten. Der Inhalt dieses

Mehr

4 Planung von Anwendungsund

4 Planung von Anwendungsund Einführung 4 Planung von Anwendungsund Datenbereitstellung Prüfungsanforderungen von Microsoft: Planning Application and Data Provisioning o Provision applications o Provision data Lernziele: Anwendungen

Mehr

1 Einleitung. 2 Anmeldung

1 Einleitung. 2 Anmeldung Deployment-Portal 1 Einleitung Das Deployment-Portal von MODUS Consult bildet die zentrale Plattform zum Austausch von Programmobjekten wie Servicepacks und Programmanpassungen. Mit Hilfe von personalisierten

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

KREDITVERZEICHNIS Konfiguration Ausgabe: 20.02.13 1/13. Dokumentation KREDITVERZEICHNIS. Teil 2. Konfiguration

KREDITVERZEICHNIS Konfiguration Ausgabe: 20.02.13 1/13. Dokumentation KREDITVERZEICHNIS. Teil 2. Konfiguration KREDITVERZEICHNIS Konfiguration Ausgabe: 20.02.13 1/13 Dokumentation KREDITVERZEICHNIS Teil 2 Konfiguration Stand 20.02.2013 KREDITVERZEICHNIS Konfiguration Ausgabe: 20.02.13 2/13 Inhalt 1. KONFIGURATION...

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

Ä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

Redundantes Speichern

Redundantes Speichern Redundantes Speichern Höchste Verfügbarkeit und größtmögliche Datensicherheit durch paralleles Speichern in EBÜS Status: Freigegeben Dieses Dokument ist geistiges Eigentum der Accellence Technologies GmbH

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

Hinweise zu Java auf dem Mac:

Hinweise zu Java auf dem Mac: Hinweise zu Java auf dem Mac: 1. Möglichkeit zum Überprüfen der Java-Installation / Version 2. Installiert, aber im Browser nicht AKTIVIERT 3. Einstellungen in der Java-KONSOLE auf Deinem MAC 4. Java Hilfe

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

Inhaltsverzeichnis: Definitionen Informationssysteme als Kommunikationssystem Problemlösende Perspektiven Allgemeine System Annäherung Fazit

Inhaltsverzeichnis: Definitionen Informationssysteme als Kommunikationssystem Problemlösende Perspektiven Allgemeine System Annäherung Fazit Informationssysteme Inhaltsverzeichnis: Definitionen Informationssysteme als Kommunikationssystem Problemlösende Perspektiven Allgemeine System Annäherung Fazit Definitionen: Informationen Informationssysteme

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

mywms Vorlage Seite 1/5 mywms Datenhaltung von Haug Bürger

mywms Vorlage Seite 1/5 mywms Datenhaltung von Haug Bürger mywms Vorlage Seite 1/5 mywms Datenhaltung von Haug Bürger Grundlegendes Oracle9i PostgreSQL Prevayler Memory mywms bietet umfangreiche Konfigurationsmöglichkeiten um die Daten dauerhaft zu speichern.

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

Aufgaben zur fachwissenschaftlichen Prüfung Modul 3 Daten erfassen, ordnen, verarbeiten und austauschen: Schwerpunkt Datenbanken

Aufgaben zur fachwissenschaftlichen Prüfung Modul 3 Daten erfassen, ordnen, verarbeiten und austauschen: Schwerpunkt Datenbanken Aufgaben zur fachwissenschaftlichen Prüfung Modul 3 Daten erfassen, ordnen, verarbeiten und austauschen: Schwerpunkt Datenbanken 30 Wozu dient ein Primärschlüssel? Mit dem Primärschlüssel wird ein Datenfeld

Mehr

Technisches Konzept "Halbautomatische Wartungsanzeige"

Technisches Konzept Halbautomatische Wartungsanzeige Technisches Konzept "Halbautomatische Wartungsanzeige" Einleitung Dieses technische Konzept beschreibt im ersten Teil die Problematik, die derzeit während Wartungszeiten oder bei Teilausfällen einer Internet-Anwendung

Mehr

Datenbank-Administration im WS 2012/13 - Einführung in Projekt 3 - Prof. Dr. Klaus Küspert Dipl.-Math. Katharina Büchse Dipl.-Inf.

Datenbank-Administration im WS 2012/13 - Einführung in Projekt 3 - Prof. Dr. Klaus Küspert Dipl.-Math. Katharina Büchse Dipl.-Inf. Datenbank-Administration im WS 2012/13 - Einführung in Projekt 3 - Prof. Dr. Klaus Küspert Dipl.-Math. Katharina Büchse Dipl.-Inf. Andreas Göbel Friedrich-Schiller-Universität Jena Lehrstuhl für Datenbanken

Mehr

eassessment Oracle DB Engine Whitepaper

eassessment Oracle DB Engine Whitepaper eassessment Oracle DB Engine Whitepaper DOKUMENT: TYP: eassessment Oracle DB Engine Whitepaper Plattformdokumentation ERSTELLT VON: nova ratio AG Universitätsstraße 3 56070 Koblenz Deutschland VERSION:

Mehr

1 Die Active Directory

1 Die Active Directory 1 Die Active Directory Infrastruktur Prüfungsanforderungen von Microsoft: Configuring the Active Directory Infrastructure o Configure a forest or a domain o Configure trusts o Configure sites o Configure

Mehr

Datenschutzerklärung und Informationen zum Datenschutz

Datenschutzerklärung und Informationen zum Datenschutz Datenschutzerklärung und Informationen zum Datenschutz Informationen zum Datenschutz in den Produkten TAPUCATE WLAN Erweiterung Stand: 04.06.2015 Inhaltsverzeichnis 1) Vorwort 2) Grundlegende Fragen zum

Mehr

suva In wenigen Schritten zum Gefahren-Portfolio Einleitung

suva In wenigen Schritten zum Gefahren-Portfolio Einleitung suva In wenigen Schritten zum Gefahren-Portfolio Einleitung Die Verordnung über die Verhütung von Unfällen und Berufskrankheiten VUV (Artikel 11a) verpflichtet den Arbeitgeber, Arbeitsärzte und andere

Mehr

Von Netop ProtectOn 2 auf Netop ProtectOn Pro umstellen

Von Netop ProtectOn 2 auf Netop ProtectOn Pro umstellen Von Netop ProtectOn 2 auf Netop ProtectOn Pro umstellen Wenn Sie Benutzer von ProtectOn 2 sind und überlegen, auf ProtectOn Pro upzugraden, sollten Sie dieses Dokument lesen. Wir gehen davon aus, dass

Mehr

Stammdaten- Synchronisierung

Stammdaten- Synchronisierung DESK GmbH Stammdaten- Synchronisierung Zusatzmodul zur Sage Office Line Evolution ab 2011 Benjamin Busch 01.07.2011 DESK Software und Consulting GmbH Im Heerfeld 2-4 35713 Eibelshausen Tel.: +49 (0) 2774/924

Mehr

Workshop GS-BUCHHALTER Umzug des Datenbankordners GSLINIE

Workshop GS-BUCHHALTER Umzug des Datenbankordners GSLINIE Herzlich willkommen zu den Workshops von Sage. In diesen kompakten Anleitungen möchten wir Ihnen Tipps, Tricks und zusätzliches Know-how zu Ihrer Software von Sage mit dem Ziel vermitteln, Ihre Software

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

1 Einleitung. 1.1 Motivation und Zielsetzung der Untersuchung

1 Einleitung. 1.1 Motivation und Zielsetzung der Untersuchung 1 Einleitung 1.1 Motivation und Zielsetzung der Untersuchung Obgleich Tourenplanungsprobleme zu den am häufigsten untersuchten Problemstellungen des Operations Research zählen, konzentriert sich der Großteil

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

Bachelorarbeit. Preisvergleichdienste auf Smartphones: Vergleich deutscher Anbieter und technische Trends. Vorgelegt von.

Bachelorarbeit. Preisvergleichdienste auf Smartphones: Vergleich deutscher Anbieter und technische Trends. Vorgelegt von. Leibniz Universität Hannover Fachbereich Wirtschaftswissenschaften Lehrstuhl Wirtschaftsinformatik Leiter: Prof. Dr. Breitner Bachelorarbeit Zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.)

Mehr

w-lantv 50n Kurzanleitung Eine Schritt für Schritt Anleitung zum erfolgreichen, drahtlosen TV Erlebnis. Bitte zuerst lesen!

w-lantv 50n Kurzanleitung Eine Schritt für Schritt Anleitung zum erfolgreichen, drahtlosen TV Erlebnis. Bitte zuerst lesen! Eine Schritt für Schritt Anleitung zum erfolgreichen, drahtlosen TV Erlebnis. Bitte zuerst lesen! Änderungen von Design und /oder Technik vorbehalten. 2008-2009 PCTV Systems S.à r.l. 8420-20056-01 R1 Lieferumfang

Mehr

Datenträgerverwaltung

Datenträgerverwaltung Datenträgerverwaltung Datenträgerverwaltung 1/9 Datenträgerverwaltung Inhaltsverzeichnis Vorgangsweise...2 Umwandeln einer Basisfestplatte in eine Dynamische Festplatte... 2 Spiegelung erstellen... 4 Partitionen

Mehr

Lizenzierung von Exchange Server 2013

Lizenzierung von Exchange Server 2013 Lizenzierung von Exchange Server 2013 Das Lizenzmodell von Exchange Server 2013 besteht aus zwei Komponenten: Serverlizenzen zur Lizenzierung der Serversoftware und Zugriffslizenzen, so genannte Client

Mehr

Bestandsabgleich mit einem Onlineshop einrichten

Bestandsabgleich mit einem Onlineshop einrichten Bestandsabgleich mit einem Onlineshop einrichten Mit unserem Tool rlonlineshopabgleich können die Warenbestände zwischen unserem Programm raum level und einem Onlineshop abgeglichen werden. Einleitend

Mehr

Der Neue Weg zur Verschlüsselung von Datenbankinhalten

Der Neue Weg zur Verschlüsselung von Datenbankinhalten Der Neue Weg zur Verschlüsselung von Datenbankinhalten Da Häufigkeit und Schwere von Datendiebstahl zunehmen, ist es immens wichtig, dass Unternehmen vertrauliche und sensible Daten zusätzlich durch Verschlüsselung

Mehr

Dokumentation QuickHMI-Schnittstelle für Oracle Datenbanken

Dokumentation QuickHMI-Schnittstelle für Oracle Datenbanken Dokumentation QuickHMI-Schnittstelle für Oracle Datenbanken Version 2.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

4. Optional: zusätzliche externe Speicherung der Daten in unserem Rechenzentrum

4. Optional: zusätzliche externe Speicherung der Daten in unserem Rechenzentrum KMU Backup Ausgangslage Eine KMU taugliche Backup-Lösung sollte kostengünstig sein und so automatisiert wie möglich ablaufen. Dennoch muss es alle Anforderungen die an ein modernes Backup-System gestellt

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

Ablauf der Applikationsänderung 10

Ablauf der Applikationsänderung 10 35012069 05/2010 Ablauf der Applikationsänderung 10 Übersicht Dieses Kapitel enthält Informationen über den Ablauf einer Applikationsänderung in einem Premium Hot Standby-System. Inhalt dieses Kapitels

Mehr

Pflichtenheft. 1 Zielbestimmungen 2 1.1 Musskriterien... 2 1.2 Wunschkriterien... 2 1.3 Abgrenzungskriterien... 2

Pflichtenheft. 1 Zielbestimmungen 2 1.1 Musskriterien... 2 1.2 Wunschkriterien... 2 1.3 Abgrenzungskriterien... 2 Pflichtenheft Inhaltsverzeichnis 1 Zielbestimmungen 2 1.1 Musskriterien........................................ 2 1.2 Wunschkriterien....................................... 2 1.3 Abgrenzungskriterien...................................

Mehr

Daten synchronisieren mit FreeFileSync (zur Datensicherung) Freeware unter http://freefilesync.sourceforge.net/ herunter laden

Daten synchronisieren mit FreeFileSync (zur Datensicherung) Freeware unter http://freefilesync.sourceforge.net/ herunter laden Daten synchronisieren mit FreeFileSync (zur Datensicherung) Freeware unter http://freefilesync.sourceforge.net/ herunter laden Persönliche Daten auf der Computerfestplatte sollten in Abständen auf ein

Mehr

2. Sie sind der Administrator Ihres Netzwerks, das den SBS 2011 Standard ausführt.

2. Sie sind der Administrator Ihres Netzwerks, das den SBS 2011 Standard ausführt. Arbeitsblätter Der Windows Small Business Server 2011 MCTS Trainer Vorbereitung zur MCTS Prüfung 70 169 Aufgaben Kapitel 1 1. Sie sind der Administrator Ihres Netzwerks, das den SBS 2011 Standard ausführt.

Mehr

Whitepaper. Produkt: combit Relationship Manager / address manager. FILESTREAM für Microsoft SQL Server aktivieren

Whitepaper. Produkt: combit Relationship Manager / address manager. FILESTREAM für Microsoft SQL Server aktivieren combit GmbH Untere Laube 30 78462 Konstanz Whitepaper Produkt: combit Relationship Manager / address manager FILESTREAM für Microsoft SQL Server aktivieren FILESTREAM für Microsoft SQL Server aktivieren

Mehr

Lizenzierung von System Center 2012

Lizenzierung von System Center 2012 Lizenzierung von System Center 2012 Mit den Microsoft System Center-Produkten lassen sich Endgeräte wie Server, Clients und mobile Geräte mit unterschiedlichen Betriebssystemen verwalten. Verwalten im

Mehr