Die Bachelorarbeit "Standortübergreifende Migration einer relationalen Oracle Datenbank zu einem neuen System inklusive Schemaintegration und minimaler Auszeit." beschäftigt sich mit der Migration einer 17 TB großen Oracle Datenbank. Dafür wurde als Praxisteil ein Testsystem aufgesetzt, um diese Migration unter den gegebenen Kriterien durchzuspielen. Für die Migration wurde RMAN, Data Guard und GoldenGate verwendet. Alle abgesetzten Befehle sind im Anhang enthalten und die Arbeit enthält eine ausführliche Beschreibung und Gegenüberstellung von Replikationstechniken.
Das Ziel dieser Arbeit ist die erfolgreiche Migration der Datenbank mit allen geforderten Kriterien. Da die Migration der CRM-T-Umgebung erst Ende 2015 oder Anfang 2016 stattfinden wird, soll diese Arbeit zusätzlich eine Vorlage für diese Migration bieten. Außerdem dient sie als Beweis, dass die geplante Migration in entsprechender Ausführung funktioniert. Daher werden alle Befehle und Konfigurationsparameter protokolliert und im Anhang beigefügt.
Bis jetzt hatte das Unternehmen nicht die Möglichkeit die geplanten Sicherheitsvorkehrungen in der Praxis zu testen, da noch keine Verbindung zwischen den beiden Standorten besteht. Da die gleichen Konfigurationen in der Testumgebung verwendet werden, wird das Netzwerk zwischen den Datenbanken mit einer bestimmten Software überwacht. Dadurch wird erkannt, ob die Verschlüsselung funktioniert und das Unternehmen T-Systems kann anhand der Bachelorarbeit die Verschlüsselung auf der CRM-T-Umgebung implementieren.
Inhaltsverzeichnis
Abkürzungsverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
1 Einleitung
1.1 Hintergrund
1.2 Problemstellung
1.3 Abgrenzung
1.4 Ziel der Bachelorthesis
2 Technische Grundlagen und Erklärung von Begrifflichkeiten
2.1 Relationale Datenbank
2.2 Migration
2.3 Aufbau einer Oracle Datenbank
2.3.1 Software
2.3.2 Datenbank-Instanz
2.3.3 Datenbank
2.3.4 Physikalische Struktur
2.3.4.1 PFILE
2.3.5 Logische Struktur
2.4 System Change Number
2.5 SQL*Plus
2.6 Fragmentierung/Reorganisation
3 Planung der Migration
3.1 Sicherung einer relationalen Oracle Datenbank
3.1.1 Cold Backup
3.1.2 Hot Backup
3.2 Replikationsverfahren
3.2.1 Oracle Data Guard
3.2.1.1 Physical Standby Database
3.2.1.2 Snapshot Standby Database
3.2.1.3 Logical Standby Database
3.2.2 Oracle Streams
3.2.3 Oracle GoldenGate
3.2.4 Export/Import
3.2.5 Trigger
3.3 Vorgaben
3.3.1 Kriterien der Migration
3.3.2 Anzahl an Datenbanken als Zwischenschritt
3.3.3 Auswahl der Replikationsverfahren
3.3.3.1 Replikationsverfahren für die Kopie
3.3.3.2 Replikationsverfahren für die Zieldatenbank
3.3.4 Erster Entwurf
3.4 Kritische Betrachtungsweise der gewählten Methodik
4 Aufbau der Testumgebung
4.1 Erstellung der Datenbanken
4.1.1 Aufbau der Quelldatenbank
4.1.2 Aufbau der Physical Standby Datenbank
4.1.2.1 Sicherung der Quelldatenbank
4.1.2.2 Netzwerk
4.1.2.3 Verschlüsselung
4.1.2.4 Konfiguration des PFILEs
4.1.2.5 Wiederherstellung der Datenbank
4.1.3 Aufbau der Zieldatenbank
4.2 Data Guard
4.2.1 Konfiguration Data Guard Quelldatenbank
4.2.2 Konfiguration Data Guard Standby Datenbank
4.3 GoldenGate
4.3.1 Konfiguration GoldenGate Quellsystem
4.3.2 Konfiguration GoldenGate Zielsystem
5 Durchführung der Migration
5.1 Datenübertragung
5.2 Deployment
5.3 Schwenk der Applikation
6 Auswertung der Messergebnisse
7 Fazit
Literaturverzeichnis
Selbstständigkeitserklärung
Anhang
Vorwort und Danksagung
Ich arbeite bei T-Systems, dem Tochterunternehmen des Konzerns Deutsche Telekom AG in der Datenbankabteilung in Krefeld und bin dort in den letzten Jahren im Umfeld von Oracle Datenbanken und Linux/Unix-Systemen ausgebildet worden. Zuerst habe ich mich in Linux-Systemen eingearbeitet, um diese Kenntnisse als Grundlage für den Umgang mit einer Oracle Datenbank nutzen zu können. Anschließend habe ich mich mit der Architektur von Oracle Datenbanken befasst und auf einem Testsystem viele Szenarien durchlaufen. Zur Unterstützung bekam ich Hilfestellung und Aufgaben von Arbeitskollegen. Darauf aufbauend wurde immer tiefer in die Materie eingegangen, sodass ich am Ende einen umfangreichen Kenntnisstand zu Oracle Datenbanken aufweisen kann. Das Unternehmen T-Systems ist seit längerer Zeit mit der Planung für die Migration der CRM-T-Umgebung von Krefeld nach Magdeburg beschäftigt. Diese Planung lieferte die Idee für das Thema meiner Bachelorarbeit. Die Migration soll unabhängig von den bisherigen Kenntnisstand analysiert werden mit anschließender Durchführung auf einer Testumgebung. Die Anforderungen an die Migration werden für die Bachelorarbeit übernommen, sodass diese Migration eine Reorganisation und Schemaintegration beinhalten soll. Eine geeignete Testumgebung ist nicht vorhanden, weswegen dessen Aufbau ebenfalls in der Arbeit enthalten ist. Die Hauptaufgabe dieser Arbeit ist, dass sie nach Fertigstellung für das Unternehmen als Referenz für die geplante Migration dienen soll.
An dieser Stelle möchte ich mich bei allen Kollegen bedanken, die mich bei dieser Arbeit unterstützt haben. Ein besonderer Dank geht vor allem an meinen Fachbetreuer Herr Klaus Thijssen, der sowohl die komplette Bachelorarbeit betreut hat und mich bei technischen Fragen an fachliche Ansprechpartner weiter vermitteln konnte. So konnte mich Matthias Konigorski sehr gut in die Thematik einarbeiten und war für fachliche Fragen der richtige Ansprechpartner. Außerdem bedanke ich mich bei den Kollegen Michael Kurpiers und Jan Fabian, die sich die Zeit genommen haben, die Arbeit Probe zu lesen. Zu guter Letzt bedanke ich mich bei meinem Teamleiter Herr Klaus-Dieter Vortmann, der zeitliche Ressourcen der Arbeitskollegen freigeräumt hat, um mich zu unterstützen.
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
Abbildungsverzeichnis
Abbildung 1: Auswirkung IT-Ausfall
Abbildung 2: Instance-Database
Abbildung 3: PFILE
Abbildung 4: Fragmentierter Tabellenbereich
Abbildung 5: Tabellenbereich Reorganisiert
Abbildung 6: Aufbau Data Guard
Abbildung 7: Physical Standby Database (Active)
Abbildung 8: Standby Konvertierungen
Abbildung 9: Logical Standby Database
Abbildung 10: Oracle Streams
Abbildung 11: GoldenGate
Abbildung 12: Konzept
Abbildung 13: Erster Entwurf
Abbildung 14: Aufbau der Testumgebung
Abbildung 15: Zeitlicher Verlauf
Abbildung 16: Anmeldung-Kurzinformationen
Abbildung 17: FTP-Paketinhalt
Abbildung 18: Kurzinformation
Abbildung 19: SFTP-Paketinhalt
Abbildung 20: Encryption
Abbildung 21: PFILE-Standby
Abbildung 22: PFILE Quelldatenbank
Abbildung 23: GoldenGate Prozesse
Abbildung 24: Quelltabelle
Abbildung 25: Zieltabelle
Tabellenverzeichnis
Tabelle 1: Beispieltabelle
Tabelle 2: Vergleich Replikationsverfahren
Tabelle 3: Messungen Testumgebung
Tabelle 4: Test- und CRM-T-Umgebung
Tabelle 5: Geschätzte Laufzeiten der CRM-T-Umgebung
1.Einleitung
Das erste Kapitel Einleitung dient der Einführung in das Thema der Bachelorthesis. Zu Beginn wird der Hintergrund der Thematik erläutert, gefolgt von der Problemstellung und der Zielbeschreibung dieser Arbeit
1.1 Hintergrund
Eine Datenbank ist ein System zur elektronischen Datenverwaltung, dessen Aufgabe es ist, die großen Datenmengen nachhaltig zu speichern. Prinzipiell gibt es bei einem solchen System zwei Bestandteile: Software und die zu verwaltende Daten. Mittlerweile gibt es viele verschiedene Anbieter von Datenbanksoftware. Neben kommerziellen Anbietern, wie Microsoft oder Oracle, gibt es Open Source Datenbanken, wie beispielsweise MongoDB oder MariaDB. Der Nachteil von Open Source Software ist, dass sie keinen Support bietet, was bedeutet, dass der Datenbankadministrator nur in Internetforen oder Wiki-Seiten Antworten auf seine Fragen erhält. Aus diesem Grund setzen viele Unternehmen auf kommerzielle Software. Außerdem spielt die zu verwaltenden Datenmenge eine Rolle und das geforderte Sicherheitslevel. Das Unternehmen T-Systems verwaltet sensible Kundendaten, die unter bestimmten Kriterien gesichert werden müssen, sodass ein Fremdzugriff auf diese Daten ausgeschlossen werden kann. Darüber hinaus müssen sie nachhaltig sein, dass selbst ein Systemausfall keinen Datenverlust versursacht. Dadurch ist ein zusätzliches, fehlerfreies Sichern der Daten erforderlich. Damit das Sichern der Daten fehlerfrei und vollständig stattfindet, sollte diese Sicherung durch ein Programm erfolgen, welches eine fehlerfreie Sicherung durch den Hersteller garantiert. Das Unternehmen hat sich für die Anforderungen für eine Oracle Datenbank entschieden. Die Oracle Datenbank enthält eine lizenzierte Software zur Datenbankverwaltung, die mit einer Vielzahl an zusätzlicher Software ausgeliefert wird, welche genutzt werden kann, um Sicherungen oder Replikationen durchzuführen. Es gibt ausreichend Literatur und Dokumentationen, durch die sich der Datenbankadministrator über entsprechende Themen informieren kann.
Diese Bachelorthesis beschäftigt sich mit der Migration einer Oracle Datenbank auf ein neues System. Als Vorlage dient eine Umgebung des Unternehmens T-Systems. Bei dieser Umgebung handelt es sich um eine CRM-T (Customer-Relationship-Management-Telekom) Umgebung, die in den kommenden Monaten migriert werden soll. CRM-T ist eine Anwendung der Telekom, die auf die Kundenpflege ausgerichtet ist. Dafür wird in der Arbeit eine Testumgebung aufgebaut, auf der eine Migration stattfinden soll, die alle gegebenen Kriterien der Migration der CRM-T-Umgebung erfüllt. Die gegebenen Kriterien und Anforderungen der CRM-T-Umgebung werden für die Testumgebung übernommen.
Das genaue Problem beziehungsweise die Anforderungen an diese Migration werden im darauffolgenden Kapitel beschrieben.
1.2 Problemstellung
Die in der Arbeit beschriebene Migration soll für ein bestimmtes Szenario angewandt werden. Es handelt sich um eine circa 17 Terabyte große Oracle Datenbank mit einem Siebel Schema der T-Systems International GmbH, welche an einen neuen Standort migriert werden soll. Der aktuelle Standort lautet Krefeld und das Zielsystem befindet sich im 433 Kilometer entfernten Magdeburg. Durch die große Entfernung tritt bereits das erste Problem auf: Die eingeschränkte Übertragungsrate. Die gesamten 17 Terrabyte sollen über das Netzwerk übertragen werden, was bedeutet, dass während der Übertragung, die sich über Tage ziehen kann, die Schnittstelle vollständig ausgelastet ist. Ein weiteres Problem sind die vielen Datenänderungen, die durchgehend auf dem Quellsystem ausgeführt und auf das Zielsystem übertragen werden müssen. Für die gesamte Migration soll der Regelbetrieb nicht beeinflusst werden. Das bedeutet, dass die Datenbank während der Migration nicht heruntergefahren werden darf und die Prozesse der Replikationsverfahren, die für die Synchronisierung des Datenbestandes verantwortlich und Teil der Migration sind, die Leistung nicht merklich beeinflussen dürfen. Wenn das System heruntergefahren wird, entspricht das einer Downtime. In der heutigen Zeit bekommt so eine Downtime einen immer höheren Stellenwert, da die damit verbundenen Kosten immer größer werden. Nach einer Studie der Independent Oracle User Group kommt es bei über 50% der befragten Teilnehmer schon zu Unterbrechungen des gesamten Geschäftsbetriebes während einer Downtime.[1]
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Auswirkung IT-Ausfall[2]
Dies schränkt die Art und Weise ein, wie die spätere Replikation ablaufen kann, und gegebenenfalls muss zu der Replikation erst einmal eine Sicherung erstellt werden, also ein Abbild der gesamten Datenbank. Beim Neuaufbau können die Daten nicht direkt von der Quelldatenbank übernommen werden, da dies die Datenbank und das Netzwerk zu sehr belasten würde. Auf dem Zielsystem wird ein anderes Betriebssystem verwendet, als auf dem Quellsystem. Dies kann die Migration erschweren, weil die Art und Weise einer Datenspeicherung im Arbeitsspeicher systemabhängig ist. Je nach Betriebssystem werden Zahlenwerte aufsteigend oder absteigend sortiert. Außerdem soll während der Migration eine Neuorganisation inklusive Defragmentierung und Strukturoptimierung stattfinden. Je länger eine Datenbank in Gebrauch ist, desto größer wird die Fragmentierung. Bei Oracle Datenbanken werden Daten in Datenblöcke mit fest definierter Größe gespeichert. Wenn es nun zu einer Datenänderung kommt, die beinhaltet, dass der zu ändernde Wert größer wird, passt dieser möglicherweise nicht mehr in den aktuellen Block und muss in einem Neuen gespeichert werden. Im alten Block wird nur ein Verweis auf den Neuen gesetzt. Durch dieses Verhalten müssen bei einer Datenabfrage zusätzliche Blöcke gelesen werden, wodurch die Antwortzeit für den Anwender steigt.
Der gesamte Migrationsprozess beinhaltet die standortübergreifende Übertragung von Daten, die sensible Kundendaten enthalten.
Laut dem Bundesdatenschutzgesetz (BDSG):
„Werden personenbezogene Daten automatisiert verarbeitet oder genutzt, ist die innerbehördliche oder innerbetriebliche Organisation so zu gestalten, dass sie den besonderen Anforderungen des Datenschutzes gerecht wird. Dabei sind insbesondere Maßnahmen zu treffen, die je nach der Art der zu schützenden personenbezogenen Daten oder Datenkategorien geeignet sind, (…) zu gewährleisten, dass personenbezogene Daten bei der elektronischen Übertragung oder während ihres Transports oder ihrer Speicherung auf Datenträger nicht unbefugt gelesen, kopiert, verändert oder entfernt werden können, und dass überprüft und festgestellt werden kann, an welche Stellen eine Übermittlung personenbezogener Daten durch Einrichtungen zur Datenübertragung vorgesehen ist (Weitergabekontrolle), (…) Eine Maßnahme nach Satz 2 Nummer 2 bis 4 ist insbesondere die Verwendung von dem Stand der Technik entsprechenden Verschlüsselungsverfahren.[3]
Dies hat zufolge, dass der Konzern entsprechend dem BDSG in der Pflicht steht, den gesamten Datenverkehr zu verschlüsseln und dieser für Außenstehende nicht zu entziffern sein darf. In der Thesis muss geklärt werden, ob und wie eine Neuorganisation verschlüsselte Übertragung realisiert werden kann. Nachdem die Migration durchgeführt wurde, muss festgestellt werden, ob es zu Datenverlusten kam. Eine hundertprozentige Sicherheit, dass alle Daten einwandfrei übertragen wurden, bekommt man durch gegebene Methoden nicht. Es ist möglich, direkt vor dem Schwenk, in dem Zeitraum der nicht geöffneten Datenbank, die Datensätze beider Datenbanken zu vergleichen. Dies funktioniert jedoch nur stichprobenartig, da die Datenmenge zu groß ist, um tatsächlich alle Tabellen miteinander zu vergleichen. Dazu kommt, dass die Auszeit, die für den Schwenk vorgesehen wird, nur begrenzt ist. Das bedeutet, es sind nur wenige Stunden Zeit, um die Konsistenz zu überprüfen, da es sofort nach dem Start der Datenbank-Instanz zu Datenänderungen kommt und ein Datensatz nicht mehr identisch ist. Nach der Auszeit ist es nur noch über stichprobenartige Abfragen möglich, den Datensatz zu kontrollieren. Ob die Übertragung verschlüsselt ist, kann man überprüfen, indem man einzelne Pakete in der Verbindung abfängt und versucht sie zu lesen. Eine erfolgreiche Verschlüsselung ist daran zu erkennen, dass der Inhalt eines Paketes nicht mehr leserlich ist.
1.3 Abgrenzung
Die Bachelorarbeit wird von einem Migrationsverfahren handeln, welchem als Vorlage die zu migrierende Plattform von dem Unternehmen T-Systems dient. Diese Migration soll gegen Ende des Jahres 2015 stattfinden. Da es sich um eine Oracle Database handelt und T-Systems diese aus kommerziellen Gründen nutzt, ist der Support für diese und deren Programme in den bezahlten Lizenzen inbegriffen und die Auswahl der Replikationsverfahren wird sich auf diese begrenzen. Dies ist auch der Grund, warum der wirtschaftliche Aspekt in dieser Thesis nicht erläutert und es kein Kapitel zu einer Kostenabschätzung geben wird. Die Übertragung der Sicherung wird durch eine einfache SFTP-Verbindung (Secure File Transfer Protocol) stattfinden. SFTP ist eine Alternative des Protokolls FTP, welches für den Datenaustausch entworfen wurde. Im Gegensatz zu FTP verschlüsselt SFTP die übertragenen Daten. Bis jetzt hat sich das Unternehmen T-Systems noch nicht entschieden, ob dieses Protokoll zur Verschlüsselung verwendet oder auf Produkt namens Crypto-box[4] zurückgreift. Diese Verschlüsselung ist eine hardwarebasierte Verschlüsselung und in der Anschaffung mit erhöhten Kosten verbunden. Aus diesem Grund wird auf den Einsatz dieser Technik in dieser Bachelorarbeit verzichtet. Der letzte Schritt einer Migration ist der Umzug auf die neue Umgebung. Dieser letzte Schritt wird in Zusammenarbeit mit der Applikation durchgeführt. Diese Bachelorarbeit bezieht sich jedoch nur auf die Datenbank. Daher wird auf die Implementierung einer Applikation in der Testumgebung verzichtet.
1.4 Ziel der Bachelorthesis
Das Ziel dieser Arbeit ist die erfolgreiche Migration der Datenbank mit allen geforderten Kriterien. Da die Migration der CRM-T-Umgebung erst Ende 2015 oder Anfang 2016 stattfinden wird, soll diese Arbeit zusätzlich eine Vorlage für diese Migration bieten. Außerdem dient sie als Beweis, dass die geplante Migration in entsprechender Ausführung funktioniert. Daher werden alle Befehle und Konfigurationsparameter protokolliert und im Anhang beigefügt.
Bis jetzt hatte das Unternehmen nicht die Möglichkeit die geplanten Sicherheitsvorkehrungen in der Praxis zu testen, da noch keine Verbindung zwischen den beiden Standorten besteht. Da die gleichen Konfigurationen in der Testumgebung verwendet werden, wird das Netzwerk zwischen den Datenbanken mit einer bestimmten Software überwacht. Dadurch wird erkannt, ob die Verschlüsselung funktioniert und das Unternehmen T-Systems kann anhand der Bachelorarbeit die Verschlüsselung auf der CRM-T-Umgebung implementieren.
2 Technische Grundlagen und Erklärung von Begrifflichkeiten
Das Kapitel Technische Grundlagen und Erklärung von Begrifflichkeiten führt in das Thema Oracle Datenbanken ein und erläutert die wichtigsten Begrifflichkeiten. Zu Beginn erfolgt eine Erläuterung über eine relationale Datenbank im Allgemeinen und was diese spezifiziert. Des Weiteren wird das Wort Migration genau definiert und welche Teilschritte diese beinhaltet. Als nächstes wird der Aufbau einer relationalen Oracle Datenbank erklärt und erforderliche Grundkenntnisse, die für das Verständnis dieser Arbeit elementar sind, behandelt. Diese Grundkenntnisse beinhalten ebenfalls die Werkzeuge, die benutzt werden, um die Datenbank zu administrieren, wie zum Beispiel das von Oracle angebotene Sicherungswerkzeug für eine relationale Oracle Datenbank.
2.1 Relationale Datenbank
Eine relationale Datenbank basiert auf dem relationalen Datenmodell. In Datenbanksystemen werden Relationen als Verbindungen zwischen Mengen, die durch Tabellen abgebildet werden, dargestellt. Die Spalten werden als Attribute und die Zeilen als Tupel bezeichnet, wobei die Relation die Beziehung zwischen den Tupeln auf Basis des Attributs aufbaut. Jede Tabelle einer relationalen Datenbank enthält einen PK(Primärschlüssel). Dieser PK ist in jeder Tabelle einzigartig vorhanden und darf nicht doppelt verwendet werden. Die einfachste Implementierung ist beispielsweise die Verwendung von IDs oder ein inkrementelles Hinaufzählen. Neben dem PK existiert der FK(Fremdschlüssel). Der FK verweist auf den PK einer anderen Tabelle, wodurch es möglich ist, Beziehungen zwischen Tabellen aufzubauen und diese zu verknüpfen.[5] Ein weiteres Merkmal, dass eine Datenbank relational ist, ist die Einhaltung der AKID-Eigenschaften (Atomarität, Konsistenz, Isolation, Dauerhaftigkeit) für Transaktionen innerhalb der Datenbank. Eine Transaktion ist eine logische Einheit von Datenänderungen, die in einer Datenbank festgeschrieben werden. Die relationale Datenbank muss sicherstellen, dass jede Transaktion „ als kleinste, nicht mehr weiter zerlegbare Einheit behandelt wird, d.h. entweder werden alle Änderungen der Transaktion in der Datenbasis festgeschrieben oder gar keine. [6]. Das bedeutet, es wird überprüft, ob eine Transaktion vollständig durchgeführt und alle Datenänderungen in die Datenbank geschrieben wurden, ansonsten ist die Transaktion nicht gültig. Nach jeder Transaktion soll der Datenbestand konsistent sein, „ Andernfalls wird sie komplett (siehe Atomarität) zurückgesetzt. [7]. Jede einzelne Transaktion muss von anderen Transaktionen isoliert werden. „ Diese Eigenschaft verlangt, dass nebenläufig (parallel, gleichzeitig) ausgeführte Transaktionen sich nicht gegenseitig beeinflussen. [8]. Mehrere Schreibprozesse, die auf ein Attribut eines Datensatzes ausgeführt werden sollen, dürfen sich nicht gegenseitig beeinflussen. Realisiert wird dies, indem diese nicht parallel, sondern hintereinander abgearbeitet werden. Als Letztes soll die Datenbank Dauerhaftigkeit aufweisen: „ Die Wirkung einer erfolgreich abgeschlossenen Transaktion bleibt dauerhaft in der Datenbank erhalten. [9]. Selbst nach einem Systemabsturz darf die Datenbank keine Daten verlieren. Die nicht abgeschlossenen Transaktionen werden zurückgesetzt und müssen vom Anwender erneut gestartet werden, damit die Datenänderungen in die Datenbank festgeschrieben werden.
Um dieses Prinzip näher zu erläutern dient das Beispiel einer Überweisung zwischen zwei Kreditinstituten.
- Kreditinstitut A werden 100 Euro abgebucht
- Kreditinstitut B werden 100 Euro gutgeschrieben
- Kreditinstitut C
Atomarität:
„Würde das Geld von Kreditinstitut A zwar abgebucht werden, aber Kreditinstitut B in irgendeiner Form nicht erreichen, dann würde eine Verletzung der Atomarität vorliegen. Wird die Banküberweisung an irgendeiner Stellte gestoppt, wird der Vorgang rückgängig gemacht und die Überweisung wird zurückgewiesen.“[10]
Konsistenz:
„Wenn zwar die Überweisung von A nach B erfolgreich verlaufen ist, aber die Zuordnung zwischen Sender und Empfänger nicht der Wahrheit entspricht, z.B. A und C , so liegt eine Verletzung der Konsistenz vor. Nach jeder Transaktion muss die Integritätsprüfung erfolgen, damit die Gültigkeit der Daten in der Datenbank gewährleistet ist.“[11]
Isolation:
„Eine Überweisung darf nur als eine Transaktion erfolgen. Es dürfen keine parallelen Transaktionen zum Zeitpunkt der Überweisung von A nach B stattfinden. Sollen mehrere Banküberweisungen erfolgen, so wird die Transaktion in einer Warteschlange gespeichert und Schritt für Schritt abgearbeitet. Würde hier eine Parallelität stattfinden, so würde eine Verletzung der Isolation vorliegen.“[12]
Dauerhaftigkeit:
„Die Überweisung von A nach B muss auch noch nach Jahren oder beliebig vielen Systemabstürzen nachvollziehbar und dauerhaft gespeichert sein. Wird diese Regel nicht befolgt, so liegt eine Verletzung der Dauerhaftigkeit vor.“[13]
2.2 Migration
Als Migration bezeichnet man „ das Migrieren von Daten, z.B. in ein anderes Betriebssystem [14]. Die Migration einer Datenbank beinhaltet die Replikation und den anschließenden Wechsel auf das Zielsystem. Replikation beschreibt in der Datenverarbeitung eine Vervielfältigung und Synchronisation von Daten. Es können einzelne Daten, Anwendungen, oder sogar ganze Betriebssysteme repliziert werden. Die Herausforderung einer Migration stellt die Nichtbeeinflussung des Betriebs dar. Der gesamte Vorgang muss entsprechend geplant und durchgeführt werden. Es kann die gesamte Datenbank migriert werden oder nur ein bestimmter Teil der Datenbank. Anschließend wird der komplette Betrieb inklusive den Anwendern auf die neue Umgebung geschwenkt. Es gibt verschiedene Arten einer Migration, die zu unterscheiden sind. Zum einen gibt es die homogene Migration und zum anderen die heterogene Migration. Die homogene Migration beschreibt eine blockidentische Kopie der Quelldatenbank. Dafür müssen beide Systeme die identischen Anforderungen aufweisen. Es muss das gleiche Betriebssystem verwendet werden und auch die identische Hardware. Da es sich um eine blockidentische Kopie der Datenbank handelt, schließt diese Tatsache eine Schemaintegration, also eine Transformation der Tabellen, aus. Ein Vorteil dieser Art ist die schnelle und effiziente Arbeitsweise, weil es keine Transformationen vorsieht und eine einfache Kopie durchgeführt werden kann. Neben der homogenen Datenbank besteht die Option eine heterogene Migrationsart zu verwenden. Diese Art der Migration sieht eine Schemaintegration vor, bzw. eine Migration in ein nicht identisches System. Üblicherweise wird hierfür eine Replikation verwendet, die sich an der logischen Struktur einer Datenbank orientiert. Diese wird im weiteren Verlauf der Arbeit näher beschrieben. Ein Vorteil der heterogenen Migration ist, dass während des Vorgangs eine Datenbereinigung und Strukturoptimierung, bzw. Reorganisation implementiert werden kann. Der Aufwand und die benötigte Durchführungszeit ist davon abhängig, wie unterschiedlich die Systeme zueinander sind und welche Reorganisationen realisiert werden sollen. Zu der Durchführung werden hier zwei verschiedene Verfahren weiter erläutert:
- Klassische Migration
- Migration mit minimaler Auszeit
Die klassische Migration ist die einfachste Form der Migration. Ihr einziges Ziel ist es, die Daten sauber in das neue System zu übertragen und im Anschluss auf dieses zu schwenken. Zu Beginn der Übertragung wird der Betrieb eingestellt, sodass dieser zu keiner Inkonsistenz führen kann, da keine neuen Daten während der Übertragung in die Datenbank festgeschrieben werden. Nach vollständiger Replikation werden alle Prozesse auf die neue Datenbank umgestellt, die anschließend hochgefahren werden kann. Der Nachteil dieser Migration ist, dass die Ausfallzeit sehr hoch ist, da während der gesamten Migration der Betrieb eingestellt ist.
Eine verbesserte Variante der klassischen Migration stellt die Migration mit minimaler Auszeit dar. Dieses Verfahren ist darauf konzipiert den Regelbetrieb so wenig wie möglich zu beeinflussen. Während der Übertragung der Daten ermöglicht diese Migration den Anwendern, weiter auf der alten Umgebung zu arbeiten, da bestimmte Methodiken angewandt werden, die nicht erfordern, dass der Betrieb eingestellt werden muss. Nur bei dem letzten Schritt, dem Schwenk, kommt es zu einer kurzen Auszeit, weil alle Prozesse neu konfiguriert werden müssen und während dieses Vorgangs keine neuen Daten festgeschrieben werden dürfen. Damit wird verhindert, dass Datenänderungen unkontrolliert in irgendeines der beiden Systeme transportiert werden. Die Migration mit minimaler Auszeit sorgt zwar dafür, dass der Regelbetrieb kaum beeinflusst wird, ist jedoch komplexer in der Planung, beziehungsweise Ausführung und der gesamte Vorgang nimmt mehr Zeit in Anspruch als eine klassische Migration.
2.3 Aufbau einer Oracle Datenbank
Um eine Migration einer relationalen Oracle Datenbank erfolgreich durchzuführen, muss man deren Aufbau kennen. Anders als bei einer typischen MySQL-Datenbank, kann man eine Oracle Datenbank klar in mehrere Bestandteile gliedern:
- Software
- Datenbank-Instanz
- Datenbank
Es ist wichtig, dass man zwischen diesen drei Komponenten differenziert und den Aufbau beziehungsweise die Arbeitsweise der Programmiersprache kennt, mit der auf die Datenbank zugegriffen wird. Die Datenbank-Instanz enthält sogar verschiedene Zustände, die einen direkten Einfluss auf Replikation und Sicherung ausüben. Des Weiteren kann eine Sicherung beziehungsweise Replikation auf dem physikalischen oder dem logischen Aufbau einer Datenbank basieren. Bevor also eine Entscheidung für ein bestimmtes Replikationsverfahren getroffen werden kann, müssen sich beide Strukturen näher angeschaut werden.
2.3.1 Software
Um eine relationale Oracle Datenbank zu erstellen, wird die Oracle Software verwendet. Diese dient als Grundlage für eine Oracle Datenbank, enthält jedoch keine veränderbaren Parameter wodurch eine Sicherung einfach und schnell ist. Die Installation einer Datenbank oder Datenbank-Instanz kann unabhängig voneinander erfolgen.
2.3.2 Datenbank-Instanz
Der Unterschied zwischen einer Datenbank und einer Datenbank-Instanz muss vorab geklärt werden, da es zwischen beiden Begriffen häufig zu Verwechslungen kommt. Eine Datenbank-Instanz beinhaltet die Werkzeuge, mit denen auf die Datenbank zugegriffen werden kann, um diese zu verwalten. Außerdem enthält sie die einzelnen Prozesse einer Datenbank, die im Hintergrund arbeiten. Des Weiteren ist zu entscheiden, in welchem Status sich eine Datenbank-Instanz befindet. Eine Datenbank-Instanz durchläuft drei Status des Hochfahrens. Der erste Status ist der No-Mount-Status. In diesem Status werden alle erforderlichen Datenbank-Instanz-Prozesse gestartet, der benötigte Platz in dem Arbeitsspeicher, sowie die benötigte Rechenleistung allokiert und Parameter gelesen, beziehungsweise gesetzt. Außerdem fängt die Datenbank-Instanz schon zu diesem Zeitpunkt an, alle Ereignisse in einer separaten Datei zu protokollieren, damit der Datenbankadministrator nachvollziehen kann, wie der Startvorgang ablief und ob es zu Problemen beziehungsweise Fehlern kam. Die benötigte Datei, um diesen Status zu erreichen, ist das PFILE. Diese Datei enthält alle wichtigen Parameter, um die zuvor erwähnten Schritte erfolgreich auszuführen und teilt der Instanz mit, wo das Control File liegt. Das Control File ist nötig, um die Instanz in den zweiten Status zu versetzen, dem Mount Status. Erst im Mount Status wird eine Verbindung der Instanz zu der eigentlichen Datenbank hergestellt. Nachdem die Verbindung hergestellt wurde, können die Datenbankdateien im Status Open freigegeben werden. Erst im geöffneten Status ist die Datenbank voll einsatzfähig.
2.3.3 Datenbank
Die Datenbank-Instanz ist direkt mit der eigentlichen Datenbank verbunden. Abbildung 2: Instance-Database verdeutlicht diese Struktur und zeigt eine Art Querschnitt der Datenbank. Es ist zur erkennen, dass die Datenbank aus drei Datentypen besteht:
- Datendateien
- Control Files
- Online Redo Logs
Datendateien beinhalten die Anwendungsdaten einer Datenbank. Diese sind auch physikalisch auf dem Betriebssystem zu finden. Die Datendateien enthalten alle Segmente, wie Tabellen oder Indexe. Neben den Datendateien besteht die Datenbank aus Redo Logs und dem Control File, welches, wie bereits erwähnt wichtig für die Datenbank-Instanz ist.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2: Instance-Database[15]
2.3.4 Physikalische Struktur
Die physikalische Struktur einer relationalen Oracle Datenbank beinhaltet die Datendateien, Redo Logs und das Control File. Jede Oracle Datenbank hat eine oder mehrere physikalische Datendateien. Die Datendateien beinhalten alle Datenbankdaten, also die logische Struktur dieser Datenbank, wie zum Beispiel Tabellen und Indexe. Das Control File ist ein weiterer elementarer Bestandteil der Datenbank und enthält Einträge über die physikalische Struktur, sowie den Datenbank-Namen, Namen und Speicherort der Datendateien, Redo Logs und die genaue Zeit, wann die Datenbank erstellt wurde.[16] Auch wenn es viele wichtige Informationen enthält, ist das Control File nicht lesbar und kann dadurch auch nicht auf Betriebssystemebenebene editiert werden. Alle Transaktionen, die auf der Datenbank getätigt werden, werden in ein Transaktionslog geschrieben, ein sogenanntes Redo Log. Es sind mindestens zwei auf jeder Oracle Datenbank vorhanden. Die primäre Funktion dieser Dateien ist es, alle Datenblockänderungen, die in einer Datenbank festgeschrieben werden sollen, zu protokollieren. Das bedeutet, dass bei einem Fehler, der verhindert, dass die Daten in die Datendateien festgeschrieben werden, die Informationen in einem Redo Log dennoch erhalten bleiben. Die Hauptaufgabe eines Redo Logs ist es, für den Fall, dass eine Datenbank zum Beispiel durch einen Systemabsturz ausfällt, diese wieder in einen konsistenten Stand zu überführen, da es sonst zu Datenverlust käme. Dieses Prinzip macht eine relationale Datenbank aus, es orientiert sich dabei an den AKID-Eigenschaften. In der normalen Standard-Konfiguration werden die Redo Logs überschrieben, sobald diese nicht mehr benötigt werden. Es ist jedoch sinnvoll, die Datenbank so zu konfigurieren, dass diese archiviert werden. Diese archivierten Redo Logs heißen Archived Redo Logs. Diese Archived Redo Logs sind auch notwendig, um eine Sicherung im laufenden Betrieb zu erstellen.
2.3.4.1 PFILE
Ein weiterer Bestandteil der physikalischen Struktur ist das sogenannte PFILE. Diese Datei wird hier separat erläutert, da sie im weiteren Verlauf der Thesis eine wichtige Rolle spielen wird. Das PFILE enthält eine Liste über die Konfigurationen einer Datenbank-Instanz und der Datenbank. Neben dem PFILE existiert das SPFILE, welches im Gegensatz zu dem PFILE dynamisch arbeitet. Das bedeutet, dass bei einer Inbetriebnahme einer Oracle Datenbank mittels SPFILE Konfigurationen innerhalb der Datenbank im laufenden Betrieb geändert werden können.[17] Abgesehen von dieser einen besonderen Eigenschaft und den leicht unterschiedlichen Aufbau der beiden Dateien sind diese identisch. In der Abbildung Abbildung 3: PFILE wird der Inhalt des PFILEs der Quelldatenbank gezeigt. Der Inhalt eines PFILEs ist in zwei Teilen zu gliedern. Die Parameter des ersten Teils beginnen alle mit dem Instanznamen, in diesem Beispiel: ”Source.__”. Diese Parameter werden von dem System gesetzt und von der Datenbank als gegeben angesehen. Beispielsweise wird der Pfad zum Quellverzeichnis der Datenbank (Source.__oracle_base=’/home/oracle/app/oracle’) und der zu allokierende Speicher für verschiedene Bestandteile der Datenbank gesetzt. Der zweite Teil besteht aus Parametern, die innerhalb einer Datenbank-Instanz konfigurierbar sind. Darunter zählt das Verzeichnis, in dem sich das Control File befindet (*.control_files) oder die Größe eines Datenblockes (*.db_block_size=8192). Es ist zu erkennen, dass zwei Control Files existieren. Das Erste liegt im normalen Home-Ordner der Datenbank und das andere befindet sich in dem Ordner, wo Sicherungen abgelegt werden (*.db_recovery_file_dest). Das Zweite dient nur zur Sicherheit, falls das Erste defekt oder gelöscht ist und ausgewechselt werden muss. Des Weiteren wird der Speicher allokiert. Es werden insgesamt 1547483648 Bytes im Arbeitsspeicher für die Datenbank-Instanz freigegeben (*.memory_target).
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3: PFILE
2.3.5 Logische Struktur
Eine relationale Oracle Datenbank wird aus administrativen Gründen in mehrere logische Speichereinheiten aufgeteilt, sogenannter Tabellenbereiche (Tablespace), um beispielsweise alle Objekte, die zu einer bestimmten Applikation gehören, leichter verwalten zu können. Ein Tabellenbereich besteht aus ein oder mehreren Datendateien. Durch diese Architektur ist es einfach, weiteren Speicherplatz der Datenbank hinzuzufügen, indem man einen Tabellenbereich um eine leere Datendatei erweitert. Diese Datendateien sind innerhalb der Datenbank in Segmente unterteilt. Segmente können beispielweise Tabellen oder Indizes sein. Ein Segment besteht aus einem oder mehreren Extents. Ein Extent ist eine Art Paket aus beliebig vielen Datenblöcken, die einen bestimmten Bereich physikalisch auf der Festplatte belegen.[18] Die genaue Größe eines Datenblocks ist im PFILE definiert.
2.4 System Change Number
Eine SCN ist ein logischer, interner Zeitstempel einer Oracle Datenbank. Jede Transaktion einer Datenbank enthält eine SCN und ist somit chronologisch einzuordnen. Eine SCN ist eine monoton steigende Sequenz, die einen logischen Zeitpunkt darstellt, jedoch nicht die tatsächliche Uhrzeit. Wenn also eine Transaktion eine geringere SCN als eine andere Transaktion besitzt, so trat es zu einem früheren Zeitpunkt auf. Es ist möglich, dass mehrere SQL-Befehle, die auf der Datenbank innerhalb einer Transaktion ausgeführt wurden, dieselbe SCN erhalten. Diese SCNs erleichtert es der Datenbank und dem Administrator, eine Wiederherstellung durchzuführen.[19]
2.5 SQL*Plus
Um auf die Datenbank Instanz zugreifen zu können, liefert Oracle das Werkzeug SQL*Plus mit. Dies ist das elementare Zugriffswerkzeug, mit dem auf der Datenbank gearbeitet werden kann. Dieses Werkzeug erlaubt es dem Datenbankadministrator SQL, PL/SQL, SQL*Plus und Betriebssystem Befehle auszuführen. Die Programmiersprache, die von SQL*Plus verwendet wird, lautet PL/SQL. PL/SQL ist eine Programmiersprache der dritten Generation und baut auf der Datenbanksprache SQL auf. Im Gegensatz zur reinen SQL-Sprache kommen beim PL/SQL weitere Befehle hinzu, mit denen man die Ausführung von SQL-Anweisungen entsprechend unterschiedlicher Bedingungen steuern kann. Beim SQL werden die Kommandos in mehrere Kategorien eingeteilt:
- DDL (Data Definition Language)
- DML (Data Manipulation Language)
- DCL (Data Control Language)
Bei der DDL werden Objekte oder Strukturen, wie zum Beispiel eine Tabelle, in einer Datenbank erstellt, verändert, oder gelöscht. Die DML erweitert, verändert und löscht Dateninhalte beziehungsweise Informationen in einer Tabelle. Mit der DCL ist es möglich, Lese- sowie Schreibrechte von Objekten zu vergeben und diese wieder zu annullieren.[20]
2.6 Fragmentierung/Reorganisation
Der Datenbestand der Quelldatenbank soll während der Migration zur Zieldatenbank reorganisiert werden. Dadurch soll zum einen ein Leistungsanstieg auf der Datenbank am neuen Standort erreicht werden und zweitens eine Neustrukturierung von Datenbanksegmenten und deren physikalischen Speicherort (Datendateien) durchgeführt werden.
Die CRM-T-Quelldatenbank wächst monatlich um ca. 100GB Speicherplatz. Grund dafür ist nicht nur ein Wachstum des Datenbestandes sondern auch die zunehmende Fragmentierung der Datenbanksegmente, wie Tabellen und Indizes.
Eine Fragmentierung beschreibt ungenutzten Speicherbereiche (Fragmente) zwischen benutzten Speicherbereichen innerhalb eines Speicherraums. Innerhalb einer Oracle Datenbank kommt es zu einer Fragmentierung, durch beispielsweise Datenbereinigungen innerhalb eines Segments. Dabei spielt die HWM (High Water Mark) eine entscheidende Rolle. Die HWM beschreibt eine Art Zeiger innerhalb der Datenbankstruktur. Es spiegelt die aktuelle Größe eines Segments oder Datendatei wieder. Abbildung 4: Fragmentierter Tabellenbereich zeigt einen Tabellenbereich, bestehend aus einer Datendatei. Diese Datendatei enthält drei Segmente, wobei Segment 1 in drei Extents aufgeteilt ist. Die HWM des Segments 1 zeigt auf den zweiten Block im dritten Extent. Das bedeutet, dass auch wenn in den vorherigen Extents freier Speicherberreich zur Verfügung steht, dieser nicht physikalisch auf der Festplatte zur Verfügung steht, da die HWM den gesamten Bereich allokiert. Nur neue Datenänderungen des Segments 1 werden in den freien Platz geschrieben.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 4: Fragmentierter Tabellenbereich
Diese Fragmentierung hat nicht nur einen negativen Einfluss auf den potentiell vorhandenen Speicherbereich auf der Festplatte, sondern sorgt auch für schlechtere Antwortzeiten des Systems. Wenn nun der komplette Inhalt von Segment 1 auf Datenbankebene abgefragt werden soll, führt dies dazu, dass der Lesekopf der Festplatte nicht in einem Fluss die Informationen lesen kann, sondern über Segment 2 und 3 springen muss, um die restlichen Informationen von Segment 1 abfragen zu können. Im großem Maße und bei großen Segmenten, kann dies einen spürbaren Leistungsverlust bedeuten.
In der aktuellen CRM-T-Datenbank teilen sich verschiedene Segmente den gleichen Tabellenplatz und somit auch die gleichen Datendateien. Sinnvolle Reorganisationen ausgewählter Segmente führen dann zwar zu einer Defragmentierung des entsprechenden Segments, was sich positiv auf das Antwortzeitverhalten von Datenbankabfragen auswirkt. Der durch diese Maßnahme freiwerdende Speicherplatz kann aber zu einem großen Teil zukünftig nur durch Segmente dieser Datendatei genutzt werden, steht somit nicht der gesamten Datenbank für das weitere Datenwachstum zur Verfügung.
Diese Art der Fragmentierung lässt sich durch eine einfache Reorganisation des Tabellenbereichs lösen. Beispielweise könnten jeder Tabelle ein eigener Tabellenbereich zugeteilt werden. Dies macht Sinn für besonders große Tabellen. Da die CRM-T-Umgebung insgesamt 35000 Segmente (Tabellen, Indizes, Prozeduren, Trigger) umfasst, wäre es ein enormer Aufwand jede einzelne Tabelle manuell zu reorganisieren. Außerdem wird auf alle Tabellen rund um die Uhr zugegriffen, weswegen sie nicht für eine Reorganisation ausfallen dürfen. Neben der HWM eines Segments existiert die HWM einer Datendatei. Die HWM einer Datendatei gibt die allokierte Größe der Datendatei an, also das Ende des letzten festgeschriebenen Extents eines Segments innerhalb der Datendatei. Abbildung 5: Tabellenbereich Reorganisiert stellt eine Datendatei mit reorganisierten Objekten aus Abbildung 4: Fragmentierter Tabellenbereich dar. Die Daten aus Segment 1 wurden in das erste Extent verschoben, wodurch die anderen beiden Extents gelöscht werden konnten. Durch eine Verkleinerung der Datendatei, kann die HWM der Datendatei um ein Extent verkleinert werden. Hinter dem Segment 1 ist zwar auch ein freies Extent entstanden, jedoch kann dieses nicht für neue Segmente verwendet werden, sondern nur für bereits vorhandene (Segment 1,2 und 3). Ein neues Segment würde nach der aktuellen HWM eingefügt werden.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 5: Tabellenbereich Reorganisiert
Es wäre möglich, Segment 2 und 3 zu exportieren, im Tabellenbereich zu löschen, die HWM auf die freie Stelle nach Segment 1 zu setzen und die Segmente wieder zu importieren.
In der Praxis fände diese Art der Reorganisation jedoch keine Anwendung, da die Datenbank von CRM-T jede Sekunde über 1200 Transaktionen aufweist. Abgesehen davon, dass die Tabellen zu jederzeit online sein müssen, damit ein Löschen und wieder Einfügen eine Option darstellen würde, gäbe es das Problem, dass der Tabellenbereich sofort neue Daten erhält. Somit ist das Umsetzen des Zeigers fast unmöglich.
Mit der Migration des CRM-T-Datenbestandes wird somit nicht nur eine Defragmentierung und damit ein Leistungsgewinn für die neue Datenbank angestrebt, sondern durch eine entsprechend geschickte Aufteilung von Datenbanksegmenten wie Tabellen und Indizes auf Tabellenbereiche und Datendateien (Separierung häufig zu reorganisierender Segmente in einzelne Tabellenbereiche bzw. Datendateien) soll erreicht werden, dass bei zukünftigen Reorganisationen von Datenbanksegmenten der dadurch freiwerdende Speicher- beziehungsweise Tabellenplatz unabhängig und somit datenbankweit wiederverwendet werden kann.
3 Planung der Migration
Das folgende Kapitel beschäftigt sich mit der Planung der Migration. Zu Beginn einer Replikation muss entschieden werden, ob es notwendig beziehungsweise vorteilhaft ist, zunächst eine Sicherung zu erstellen und mit dieser weiterzuarbeiten, um die Quelldatenbank zu entlasten. Um eine Sicherung zu erstellen, gibt es mehrere Arten und Ansätze. Danach werden Verfahren vorgestellt, die eine Replikation von einer Oracle Datenbank ermöglichen. Es wird die Funktionsweise und eventuell vorhandene Vor- und Nachteile erklärt. Anschließend folgt eine Selektion anhand der Vorgaben für die Migration und ein erster Entwurf, wie die geplante Migration aussehen soll.
3.1 Sicherung einer relationalen Oracle Datenbank
Ein Datenbankadministrator ist angehalten, eine Sicherungsstrategie vorzuweisen, um eventuellen Datenverlust zu verhindern. Eine Sicherung ist eine Kopie einer Datenbank, welche man verwendet, um Daten zu rekonstruieren. Diese kann entweder eine physikalische oder eine logische Sicherung sein. Physikalische Sicherungen sind Kopien der physikalischen Dateien. Diese enthalten die Datendateien, das Control File und Archived Redo Logs. Diese Sicherungen sollten auf einem anderen System abgelegt werden. Die logische Sicherung beinhaltet logische Daten, wie zum Beispiel Tabellen. Den Unterschied zwischen einer physikalischen und logischen Sicherung lässt sich leicht anhand eines Beispiels mit einer Word-Datei erklären. Die physikalische Sicherung behandelt nur die Datei an sich und würde ein einfaches Kopieren an einen anderen Speicherort bedeuten. Die logische Sicherung würde die Word-Datei öffnen und nur den Inhalt kopieren in eine neue Datei übertragen. Logische Sicherungen sind eine nützliche Ergänzung, jedoch bieten sie ohne eine physikalische Sicherung keinen ausreichenden Schutz vor einem Datenverlust.[21]
3.1.1 Cold Backup
Man spricht von einem Cold Backup, wenn sich die Datenbank in einem geschlossenen Zustand befindet. Diese Art von Sicherung beinhaltet im Normalfall die gesamte Datenbank und ist zu dem Zeitpunkt der Erstellung konsistent.[22] Die einfachste Möglichkeit ein Cold Backup durchzuführen, ist ein einfaches Kopieren der Datendateien inklusive Software und zugehörigen Konfigurationsdateien der Datenbank, während die Datenbank gestoppt ist. Generell beschreibt ein Cold Backup eine Sicherung, die erstellt wird, wenn die Datenbank geschlossen ist.
3.1.2 Hot Backup
Ein Hot Backup, auch online Sicherung genannt, beschreibt eine Sicherung, die während des laufenden Betriebs erstellt wird. Die Datenbank befindet sich also im geöffneten Zustand, was bedeutet, dass der Betrieb für eine Sicherung nicht unterbrochen wird. Es gibt mehrere Varianten um so eine Sicherung durchzuführen. Zum einen kann die Datenbank in einen Hot Backup Mode versetzt werden. Dieser Modus veranlasst die Datenbank, dass sich die Tabellenbereiche in einem Sicherungsmodus befinden, damit es zu keinen Fractured Blocks kommt.[23] Von Fractured Blocks spricht man, wenn der Inhalt innerhalb eines Datenblocks nicht mehr konsistent ist, also eine Hälfte eines Datenblocks neuer ist als die andere.[24] Online Sicherungen werden also nicht nur auf Betriebssystemebene durchgeführt, sondern erfordern ein Mitwirken der Datenbank-Instanz. Sobald sich die Datenbank im Hot Backup Mode befindet, können die Datendateien und Archived Redo Logs auf Betriebssystemebene kopiert werden. Eine andere Möglichkeit, eine online Sicherung durchzuführen, ist die Sicherung durch RMAN. RMAN ist ein mitgeliefertes Werkzeug von Oracle, welches die Vorgehensweise zur Erstellung einer Sicherung vereinfacht, da vieles automatisiert abläuft. Es stellt eine Kopie der Datenbankdateien her und zusätzlich sichert dieses Werkzeug die Archived Redo Logs, um zusätzliche Informationen, welche die Sicherung nicht erfasst hat, wiederzugewinnen. Der Hot Backup Mode, welcher für eine online Sicherung mittels SQL*Plus verwendet wird, braucht bei einer Sicherung mittels RMAN nicht aktiv sein. RMAN kann sowohl für ein Cold Backup als auch für ein Hot Backup verwendet werden. Jedoch ist es zwingend notwendig, dass die Datenbank-Instanz sich mindestens im Mount-Status befindet, da RMAN ein Werkzeug der Instanz ist und wissen muss, wo die Datendateien liegen und diese Information erst mittels des Control Files im Mount-Status der Datenbank-Instanz mitgeteilt wird. Ein weiterer Vorteil von RMAN ist, dass es das SPFILE und Control File direkt mitsichert. Außerdem ist es möglich, inkrementelle Sicherungen zu erstellen. Eine inkrementelle Sicherung baut auf den vorherigen Sicherungen auf. Somit ist es zwingend notwendig, dass eine Komplettsicherung bereits existiert, die als Fundament benutzt werden kann. Es werden nur die neuen Änderungen gesichert, die nach der letzten Sicherung getätigt wurden. Dadurch nimmt eine inkrementelle Sicherung auf Dauer weniger Zeit in Anspruch. Der Nachteil ist jedoch, dass eine inkrementelle Sicherung nur in Verbindung mit den vorherigen Sicherungen funktioniert und das Archivieren oder Löschen somit komplexer ausfällt.
3.2 Replikationsverfahren
Die Replikation kann ein Bestandteil der Migration. Dieser Vorgang ist dafür Verantwortlich, dass die Daten in die neue Umgebung übertragen und mit der alten Umgebung synchronisiert werden. Es gibt zwei verschiedene Arten eine Replikation zu implementieren:
- Bidirektionale Replikation
- Unidirektionale Replikation
Die Bidirektionale Replikation beschreibt ein Vorgehen, bei dem die Replikationsmechanismen auf der Ziel-, aber auch auf der Quellumgebung eingerichtet werden. So können Datenänderungen in beide Richtungen repliziert werden. Das Hauptziel der in dieser Arbeit beschriebenen Migration ist die komplette Datenbank in eine neue Umgebung zu übertragen, weswegen im weiteren Verlauf nur auf die unidirektionale Replikation eingegangen wird, auch wenn die in den kommenden Kapiteln vorgestellten Replikationsverfahren durchaus in der Lage wären eine bidirektionale Verbindung aufzubauen.
Um eine Datenbank zu replizieren, gibt es verschiedene Ansätze und Möglichkeiten. Der simpelste Ansatz ist eine blockidentische, physikalische Spiegelung der Dateien. Das bedeutet ein einfaches Kopieren und Einsetzen der Daten, während die Datenbank heruntergefahren ist. Dieser Ansatz ist jedoch sehr fehleranfällig und funktioniert nur bei einer Replikation auf ein identisches System. Mögliche korrupte Dateien werden ebenfalls ohne Fehlerbeseitigung kopiert. Korrupte oder beschädigte Dateien sind Dateien, die nicht mehr ordnungsgemäß funktionieren. Ein anderer Ansatz, die logische Replikation, spiegelt nicht die vorhandenen Dateien aus dem Quellsystem, sondern liest die Datenänderungen der Datenbank, überträgt diese und baut sie anhand der entnommenen Informationen nach. Dadurch wird gewährleistet, dass die Kopie auch auf einem nicht identischen System funktioniert und korrupte Dateien werden aussortiert. Den Inhalt der Datenbank erhalten diese Replikationsverfahren zum Beispiel durch die Datenblockänderungen aus den Redo Logs. Es wird unterschieden zwischen Verfahren, die einen identischen Klon des Systems anhand der Datenblockänderungen nachbauen und Verfahren, die Änderungen oder Kriterien miteinbeziehen, die vorher durch den Anwender angegeben werden. Außerdem ist zwischen einer synchronen und asynchronen Replikationsart zu unterscheiden. Bei einer synchronen Kommunikation müssen beide Teilnehmer aktiv sein. Das bedeutet, dass eine Nachricht erst dann übermittelt wird, wenn die zu empfangende Komponente empfangsbereit ist. Bis zur erfolgreichen Übertragung ist die sendende Komponente blockiert und wartet auf die Bestätigung des Empfängers. Der Nachteil dieser Art der Kommunikation ist, dass falls die empfangende Komponente ausfällt, oder die Verbindung eine zu hohe Latenz aufweist, die sendende Komponente lange aussetzt. Bei einem Replikationsverfahren geht es so weit, dass einzelne Transaktionen oder Befehle erst gar nicht abgesetzt werden können, wenn die empfangende Komponente nicht aktiv ist. Um dem Abhilfe zu schaffen wurde die asynchrone Kommunikation eingeführt. Die asynchrone Kommunikation geht davon aus, dass die empfangende Komponente auch mal nicht aktiv ist, der Betrieb der senden Komponente dennoch weitergehen soll. Also werden Prozesse gestartet, die die zu sendenden Objekte übermitteln sollen, jedoch die sendende Komponente nicht blockieren. Dadurch kann nach dem Senden normal weitergearbeitet werden, auch wenn die empfangende Komponente nicht aktiv ist. Es werden im weiteren Verlauf folgende Replikationsverfahren beschrieben:
- Oracle Data Guard
- Oracle Streams
- Oracle GoldenGate
- Export/Import
- Trigger
[...]
[1] Vgl. Oracle Corporation: Oracle White Paper: Zero Downtime Database Upgrade Using Oracle GoldenGate S. 7
[2] Nach Oracle Corporation: Oracle White Paper: Zero Downtime Database Upgrade Using Oracle GoldenGate S. 7
[3] Anlage (zu § 9 Satz 1). BDSG
[4] https://www.marx.com/de
[5] Vgl. Kemper, A.; Eickler. A.: Datenbanksysteme: Eine Einführung: S. 273
[6] Kemper, A.; Eickler. A.: Datenbanksysteme: Eine Einführung: S. 273
[7] Kemper, A.; Eickler. A.: Datenbanksysteme: Eine Einführung: S. 273
[8] Kemper, A.; Eickler. A.: Datenbanksysteme: Eine Einführung: S. 273
[9] Kemper, A.; Eickler. A.: Datenbanksysteme: Eine Einführung: S. 273
[10] Datenbanken Verstehen: Datenbanktransaktionen nach dem ACID-Prinzip
[11] Datenbanken Verstehen: Datenbanktransaktionen nach dem ACID-Prinzip
[12] Datenbanken Verstehen: Datenbanktransaktionen nach dem ACID-Prinzip
[13] Datenbanken Verstehen: Datenbanktransaktionen nach dem ACID-Prinzip
[14] Bibliografisches Institut: Duden, Online: http://www.duden.de/Rechtschreibung/Migration
[15] Oracle Corporation: Oracle Database Online Documentation 10g: Database Concepts S. 285
[16] Vgl. Oracle Corporation: Oracle Database Online Documentation 10g: Database Concepts S. 36
[17] Vgl. Oracle Corporation: Oracle Database Online Documentation 10g: Database Concepts S. 37
[18] Vgl. Oracle Corporation: Oracle Database Online Documentation 10g: Database Concepts S. 38
[19] Vgl. Oracle Corporation: Oracle Database Online Documentation 11g: Database Concepts S. 217
[20] Vgl. Oracle Corporation: Oracle Database Online Documentation 10g: Database SQL Reference. S. 509
[21] Vgl. Oracle Corporation: Oracle Database Online Documentation 11g: Database Backup and Recovery Users’s Guide. S. 28
[22] Vgl. Oracle Corporation: Oracle Database Online Documentation 11g: Database Backup and Recovery Users’s Guide. S. 570
[23] Vgl. Oracle Corporation: Oracle Database Online Documentation 11g: Database Backup and Recovery Users’s Guide. S. 567
[24] Vgl. Oracle Corporation: Oracle Database Online Documentation 11g: Database Backup and Recovery Users’s Guide. S. 575
-
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X.