Aktiv-Aktiv-Replikation

(1)

Oracle Dojo ist eine Serie von Heften, die Oracle Deutschland B.V. zu unterschiedlichsten Themen aus der Oracle-Welt herausgibt.

Der Begriff Dojo [‘do:d3o] kommt aus dem japanischen Kampf- sport und bedeutet Übungshalle oder Trainingsraum. Als

„Trainingseinheiten“, die unseren Anwendern helfen, ihre Arbeit mit Oracle zu perfektionieren, sollen auch die Oracle Dojos verstanden werden. Ziel ist es, Oracle-Anwendern mit jedem Heft einen schnellen und fundierten Überblick zu einem abgeschlossenen Themengebiet zu bieten.

Im Oracle Dojo Nr. 6 beschäftigt sich Joachim Jaensch, Leitender System berater bei Oracle Deutschland B.V. und zuständig für das Thema Replikation und Integration, mit Oracle GoldenGate.

Dieses Dojo bietet Ihnen einen wunderbaren Einstieg und eine gute Hilfe beim Aufbau von verteilten Umgebungen.

6 Oracle GoldenGate 11 gR 2 – Aktiv -Aktiv -Replikation

ORACLE DOJO NR.

6

JOACHIM JAENSCH

(2)

6 Oracle GoldenGate 11 gR 2 – Aktiv -Aktiv -Replikation

ORACLE DOJO NR.

6

JOACHIM JAENSCH

6 Oracle GoldenGate 11 gR 2 – Aktiv -Aktiv -Replikation

ORACLE DOJO NR.

6

JOACHIM JAENSCH

(3)

Teil I

– Überblick

1 Was versteht man unter Datenreplikation? 6

2 Replikation mit Oracle GoldenGate 8

2.1 Überblick 8

2.2 Einsatzgebiete 11

2.3 Unterstützte Plattformen 14

2.4 Installation und Konfiguration 15

2.5 Prozesse 18

2.5.1 Manager-Prozess 18

2.5.2 Collector-Prozess 19

2.5.3 Extract-Prozess (primär und sekundär) 20

2.5.4 Replicat-Prozess 22

2.6 Trail Files 24

2.7 Instantiierung und INITIAL-LOAD 25

2.8 GoldenGate Software Command Interface (GGSCI) 28

2.8.1 GoldenGate-Kommandos 30

2.8.2 Kommando OBEY 31

3 Konfliktbehandlung 32

3.1 Wann entstehen Konflikte? 32

3.2 Vermeidung von Konflikten 33

3.3 Standardkonfliktlösungen 34

4 Globalisierung 36

5 Sicherheit 39

5.1 Übersicht 39

5.2 Passwort-Verschlüsselung 40

6 Administration und Überwachung 44

6.1 GGSCI-Kommandos und -Reports 44

6.2 Oracle Management Pack for Oracle GoldenGate 45

6.2.1 Oracle Enterprise Manager Plug-in 47

6.2.2 Oracle GoldenGate Monitor 49

6.2.3 Oracle GoldenGate Director 53

6.2.4 Gegenüberstellung 57

6.3 Oracle GoldenGate Veridata 59

Teil II

– Replikationsbeispiel

7 GoldenGate-Installation 63

8 Aufbau einer Aktiv-Aktiv-Replikation 66

8.1 Überblick und Voraussetzungen 67

8.2 Voraussetzungen in primärer und sekundärer Datenbank 69

8.2.1 ARCHIVELOG Mode 69

8.2.2 Supplemental Logging 72

8.2.3 Das Replikationsobjekt 73

8.2.4 GoldenGate Admin-User 80

8.2.5 Instantiierung 82

8.3 Aufbau der GoldenGate-Parameterdateien 83

8.3.1 Erstellen eines Connect-Makros 84

8.3.2 Datei GLOBALS und Manager-Parameter 85

8.3.3 Extract- und Replicat-Parameter 88

8.4 OBEY-Kommando-Files 90

8.4.1 Primäre Datenbank 91

8.4.2 Sekundäre Datenbank 93

8.5 Einrichten der Replikationsumgebung (OBEY Files) 95

8.6 Starten und Stoppen der Replikation 102

8.7 Kontrolle der Replikation 108

8.8 Einbau einer UPDATE-Konfliktlösung 111

8.8.1 Ergänzen der GoldenGate-Parameterdateien 111

8.8.2 Test der Konfliktbehandlung 116

8.8.3 GoldenGate Reports 125

8.9 Löschen der Replikationsumgebung 138

9 Schlusswort 147

10 Weitere Informationen 150

be trademarks of their respective owners. Herausgeber: Günther Stürner, Oracle Deutschland B.V. Design: volkerstegmaier.de // Druck: Stober GmbH, Eggenstein

(4)

Teil I

– Überblick

2.1 Überblick 8

2.5 Prozesse 18

5 Sicherheit 39

5.1 Übersicht 39

Teil II

9 Schlusswort 147

Teil I

– Überblick

2.1 Überblick 8

2.5 Prozesse 18

5 Sicherheit 39

5.1 Übersicht 39

Teil II

9 Schlusswort 147

(5)

Oracle GoldenGate 11gR2 Aktiv-Aktiv-Replikation –

Oracle DOjO nr.

6

J O A C H I M J A E N S C H

(6)

3

Vorwort des Her ausgebers

Die Golden Gate Bridge sehen und überqueren, per pedes, mit dem Fahrrad oder einfach mit dem Auto, ist ein MUSS, wenn man San Francisco besucht. Dieses Bauwerk, das in den 30er-Jahren des letzten Jahrhunderts unter schwierigsten Bedingungen gebaut wurde, gilt zu Recht als Meisterleistung der Ingenieurskunst und als eines der schönsten Bauwerke der Welt. Egal von welcher Perspektive man diese Brücke betrachtet, sie ist beeindruckend.

Ich kann es nicht mit Bestimmtheit sagen, aber ich denke mir, dass die ursprünglichen Entwickler der GoldenGate Software – Oracle hat die Firma GoldenGate Software, Inc. im Jahr 2009 übernommen – genau dieses Gefühl vermitteln wollten, als sie einen Namen für ihre 1995 gegründete Firma und ihr Produkt gesucht haben. Die GoldenGate Software sollte ebenfalls eine Brücke darstellen und zwar zwischen verteilten Datenbanksys- temen. Dieses Produkt sollte, wie seine Namensgeberin, alles in den Schatten stellen, was es bisher in diesem Bereich gab.

Oracle GoldenGate ist nach Oracle Advanced Replication und nach Oracle Streams die dritte Generation unserer Replika- tions- und Integrationstechnologie und setzt Maßstäbe im Bereich der verteilten Systeme und das nicht nur im homogenen Oracle-Umfeld.

(7)

4

Für Oracle GoldenGate bieten sich vielfältige Einsatzmöglich- keiten. Man findet es oft als zentrale Komponente bei hochver- fügbaren verteilten Konfigurationen, in Replikationsumgebun- gen jeglicher Art, als Basis für Zero-Downtime-Upgrades von Oracle-Datenbanken oder als ETL-Komponente, um unterschiedliche Datenquellen zu konsolidieren – und das sind nur einige typische Szenarien.

Das Wissen über die Möglichkeiten, die ihnen Oracle Golden- Gate bietet, ist die Basis für bessere und stabilere IT-Systeme.

Ich freue mich sehr, dass Joachim Jaensch, einer unserer erfah- rensten Systemberater und zuständig für das Thema Replikation und Integration, sein Wissen über Oracle GoldenGate in diesem Dojo zusammengefasst hat. Es bietet Ihnen einen wunderbaren Einstieg und eine gute Hilfe beim Aufbau von verteilten Umge- bungen.

Ich wünsche Ihnen viel Spaß beim Lesen und beim Testen.

Ihr Günther Stürner Vice President Sales consulting

PS: Wir sind an Ihrer Meinung interessiert. Anregungen, Lob oder Kritik gerne an barbara.frank@oracle.com. Vielen Dank!

(8)

5

Teil I

GoldenGate 11gR2

Überblick

(9)

1 Was versteht man unter Datenreplikation?

Informationen beziehungsweise Daten bilden eine wichtige Grundlage für den Erfolg eines Unternehmens. Sie dienen ent- weder der reibungslosen Produktion oder der Vorbereitung von operativen und langfristigen Entscheidungen zum Wohle einer Firma. Mit zunehmender Größe eines Unternehmens wächst häufig auch die Anzahl der Firmenstandorte. Die Distanzen der einzelnen Firmenstandorte zueinander können dabei sehr unterschiedlich sein und beschränken sich nicht auf Länder- grenzen. Internationale Firmen sind heute weltweit aufgestellt und besitzen Niederlassungen oder Tochterfirmen in verschiedenen Ländern und auf mehreren Kontinenten. Dem muss die Informationsverarbeitung Rechnung tragen, das heißt, Unter- nehmensdaten müssen überall zeitnah verfügbar sein. Während noch vor zwanzig Jahren Datenträger per Post verschickt wurden, weil die nötigen Datennetze fehlten, kann man im heutigen In- ternetzeitalter weltweite TCP/IP-Netzwerke nutzen, um Informa- tionen und Daten zu verteilen. In den letzten Jahren sind Soft- warelösungen zur zeitnahen Verteilung von Daten entstanden, die diese neuen Möglichkeiten nutzen. Diese Verteilung bezeichnet man als Replikation. Man unterscheidet zwischen synchroner und asynchroner Replika tion. Bei der synchronen Replikation wird eine Änderung am Datenobjekt nur wirksam, wenn sie auf der Quell- und der Zieldatenbank erfolgreich war. Das hat

6 WAS vErStEHt MAN uNtEr DAtENrEplIkAtION?

(10)

einen Nachteil: Nur wenn die Änderung auf beiden Seiten erfolgreich war, wird weitergearbeitet, bei Netzwerkaus- fall stehen beide Datenbanken. In der Praxis wird deshalb hauptsächlich die asynchrone Replikation eingesetzt. Dabei existiert zwischen der Änderung des Originals und der Synchronisation des Replikats eine Latenzzeit. Asynchrone Replikations verfahren sind: File Transfer, Primary Copy, Snapshot Replication und Log-based-Replication. In diesem Dojo wird nur die zuletzt genannte Art der Replika tion betrachtet, die der von Oracle GoldenGate entspricht.

WAS vErStEHt MAN uNtEr DAtENrEplIkAtION? 7

Abb.1: Replikationsszenarien

In der Praxis findet man häufig Kombinationen der abgebildeten Replikationstopologien.

Uni-Directional (Single-Source) Query Off-Loading Zero-Downtime Migration

Broadcast Data Broadcast

Bi-Directional (Multi-Master) Hot Standby or Active-Active for HA

Integration/

Consolidation Data Warehouse

Peer-to-Peer Load Balancing Multi Master

Data Distribution via Messaging

BPM BAM CEP

(11)

2 Replikation mit Oracle GoldenGate

2.1 Überblick

Oracle GoldenGate ist eine Komponente zur Replikation von Daten zwischen unterschiedlichen Datenbanken und Systemen. Die Replikation beginnt mit dem Erfassen der Änderungen auf dem Quellsystem, dem Extract-Prozess.

Grundlage dafür bilden die Redolog- beziehungsweise Journal-Informationen des Quellsystems. Im ALO-Modus (Archived Log Files Only) liest GoldenGate nur archivierte Redolog Files. Die erfassten Änderungen können in lokalen Trail Files (Local Trails) oder Trails auf der Zielseite (Remote Trails) abgelegt werden. Mit einem Datapump-Prozess werden lokale Trail Files zum Zielsystem übertragen. Dort sorgt der Replicat-Prozess für das Anwenden der Änderungen in der Zieldatenbank. Die GoldenGate-Prozesse werden häufig auch nach der von Oracle Streams bekannten Terminologie benannt. EXTRACT heißt dann CAPTURE, REPLICAT wird als APPLY oder DELIVERY bezeichnet. An der Replikation können zwei und mehr Systeme beteiligt sein, wobei unidirektional und bidirektional repliziert werden kann. Neben DML-Änderungen (Data Manipulation Language) können auch DDL-Änderungen (Data Definition Language) Teil der Replikation sein. Replikationsumgebungen sind sehr

8 ÜbErblICk

(12)

vielseitig. Es gibt „1-way“-, „n-way“-, „Multimaster“- und

„Hub-and-Spoke“-Replikationen. Häufig sind die einzelnen Arten in Kombination zu finden. Zur Überwachung der Replikationslandschaft dienen Berichte, deren Erstel- lung automatisiert oder über Kommando erfolgen kann.

Mit dem Management Pack for Oracle GoldenGate steht eine grafische Komponente zur Administration und zum Monitoring unter dem Oracle Enterprise Manager bereit.

Nutzer, die nicht mit dem Oracle Enterprise Manager arbeiten, können den neu entwickelten GoldenGate Monitor verwenden. Der GoldenGate Director als älteres grafisches Administrationstool steht gegenwärtig auch noch zur Verfügung, wird aber langfristig durch die beiden anderen Tools ersetzt werden. Gegenwärtig müssen alle drei Kom- ponenten zusätzlich lizenziert werden. Die Konfiguration einer GoldenGate-Replikation erfolgt über Parameter, die in plattformspezifischen Flat Files abgelegt werden. Die Steu- erung der Replikationsprozesse (zum Beispiel Starten und Stoppen) erfolgt über das auf allen unterstützten Plattfor- men vorhandene GoldenGate Software Command Interface (GGSCI).

Dargestellt wird die unidirektionale Replikation, also die Replikation von einer Quelle (Source) zu einem Ziel (Target).

Im oberen Teil wird der INITIAL-LOAD dargestellt, die Erst- befüllung der Zielseite mit den zu replizierenden Objekten.

ÜbErblICk 9

(13)

10

Danach kann die eigentliche „Change Replication“ beginnen, die im unteren Teil dargestellt ist. Das Einrichten einer Replika- tion muss heute fast immer bei laufendem Betrieb erfolgen.

Dabei gibt es zwei Forderungen zu beachten:

1. Verwendung eines konsistenten Backups der Quellobjekte für INITIAL-LOAD.

2. Erfassen aller danach erfolgten Änderungen an den Quell- objekten, um damit die Synchronisation der Ziel objekte nach Abschluss der Erstbefüllung durchzuführen.

Abb.2: GoldenGate-Architektur source

tables

Manager

change logs

Source Oracle or Non-Oracle Database

Optional capture

capture

capture trial

File

LAN/WAN/

Internet Over TCP/IP

Trial File

(14)

11

2.2 einsatzgebiete

Oracle GoldenGate wird zur Replikation in heterogenen Umgebungen eingesetzt. Für die Replikation in homogenen Oracle-Umgebungen kann GoldenGate natürlich auch benutzt werden. Ein Vorteil der Komponente ist die Schnel- ligkeit, in der repliziert werden kann. Oracle GoldenGate eignet sich deshalb hervorragend für die Replikation unter Real-Time-Bedingungen. Der EXTRACT auf der Quelldaten- bank läuft völlig unabhängig von einem eventuellen DATAPUMP oder vom REPLICAT auf der Zieldatenbank.

Abb.2: GoldenGate-Architektur

Manager

Collector

1. Change Synchronization and then

2. Continous Replication INITIAL-LOAD

delivery

delivery trial

Trial File

File

(15)

Die Prozesse sind voneinander entkoppelt, das heißt, sie können zwar in unmittelbarer zeitlicher Folge ablaufen, müssen es aber nicht. In bestimmten Situationen kann dieser Spielraum vorteilhaft sein.

GoldenGate ist hervorragend für die Lösung dieser Aufgabenstellungen geeignet:

– Real-Time Data Replication uni-/bidirectional

„1-way”/„n-way”

homogeneous/heterogeneous – Real-Time Data Warehouses

– Real-Time Database Offload Reporting – Database Upgrades with near-zero Downtime – Database Migrations with near-zero Downtime – Database Platform Migrations

homogeneous/heterogeneous

Je nach Einsatzgebiet nutzt man uni- oder bidirektionale Re- plikation. Für Database Upgrades oder Database Migra tions ist eigentlich nur die unidirektionale Replikation not wendig.

Da man aber Fehler niemals völlig ausschließen kann, bereitet man für diese Fälle auch eine Replikation für den

12 EINSAtzgEbIEtE

(16)

Rückweg von der Ziel- zur Quelldatenbank vor. Sehr gut haben Sie gearbeitet, wenn Sie diese Replikation niemals nutzen müssen. Der Ablauf eines Upgrades oder einer Migration ist ausführlich in mehreren Oracle White Papers beschrieben. Links dazu finden Sie unter Punkt 10.2. An dieser Stelle möchte ich Sie aber noch auf eine Besonder- heit zu GoldenGate hinweisen: Viele Unternehmen nutzen SAP-Installationen auf Grundlage einer Oracle-Datenbank.

Oracle bietet in enger Zusammenarbeit mit dem SAP Solu- tion Center in Walldorf sogenannte Oracle-to-Oracle (O2O) Transition Services an. Einer dieser Services ist Oracle-to- Oracle Online der auch als Oracle Triple-O bezeichnet wird. Dabei handelt es sich um eine Lösung, die aus „Initial Alignment" und „Data Synchronization" besteht. Letztere Funktion wird dabei durch Oracle GoldenGate realisiert.

Dieses spezielle Verfahren für Upgrade oder Migration einer SAP-Umgebung ist zum Beispiel nutzbar für R/3, BI, CRM und XI, sofern diese auf einer Oracle-Datenbank basieren.

Bei diesem Verfahren entstehen unabhängig von der Da- tenbankgröße nur Stillstandszeiten um die zehn Minuten.

Es ist zertifiziert durch die SAP und in einer SAP Support Note dokumentiert. Da ich Sie an dieser Stelle aber nicht aus dem Kontext dieses Dojo herausreißen möchte, rate ich Ihnen, die in Tabelle 1 aufgeführten Dokumente zu Oracle Triple-O erst zu einem späteren Zeitpunkt anzuschauen.

EINSAtzgEbIEtE 13

(17)

14 uNtErStÜtztE plAttfOrMEN

Für den Zugang auf die Support-Portale von SAP und Oracle ist ein User-Account notwendig.

2.3 unterstÜtzte PlattFormen

tab.1: Support Notes zu Oracle-to-Oracle Online

Name des Dokuments SAP / Oracle Support Note Oracle to Oracle Online Migrations

– Triple O

SAP - 1508271 https://service.sap.com Using Oracle GoldenGate with

Online SAP Migrations

Oracle - 1169023.1 https://support.oracle.com

tab.2: GoldenGate-Replikationsplattformen (Version 11.2.1.0.4) Database Log-Based Capture Non-Log_Based

Capture**

Replication

c-tree*** X X

DB2 for i X X

DB2 for Linux, UNIX, Windows

X X

DB2 for z/OS X X

Oracle X X

MySQL X X

SQL/MX X X

SQL Server X X

Sybase X X

(18)

2.4 installation und konFiguration

Oracle GoldenGate gibt es für eine Vielzahl unterschiedli- cher Datenbanken und Daten-Management-Systeme. Gold- enGate wird in verschiedenen „Builds“ für alle unterstützten Plattformen (Kombination Hardware/Betriebssystem) und Versionen bereitgestellt. Der Download der Software erfolgt über http://edelivery.oracle.com. Die Installation umfasst diese Schritte und wird im Teil 2 durchgeführt:

1. Entpacken des Zip-Files in einen Installation-Folder (Ordner, Verzeichnispfad)

2. Öffnen des Command Prompt und Aufruf des Golden- Gate Software Command Interface (GGSCI)

3. Ausführen des Kommandos: CREATE SUBDIRS

INStAllAtION uND kONfIgurAtION 15

* Derzeit nur als Ziel (Target) unterstützt

** Capture-Modul kommuniziert mit einem GoldenGate API zum Erfassen von Änderungen

*** Nur 1:1-Replikation unterstützt, keine Datenmanipulationen (Filtering, Mapping) möglich Database Log-Based Capture Non-Log-Based

Capture**

Replication

Teradata X X

PostgreSQL* X

TimesTen* X

Generic ODBC* X

(19)

16 INStAllAtION uND kONfIgurAtION

4. Zusätzliche Unterverzeichnisse anlegen (zum Beispiel „dirmac“)

5. Erstellen des Files: GLOBALS (empfohlen, um Standards zu ändern!)

Die beiden Ordner „ogg_new_src“ und „ogg_new_tar“

beinhalten jeweils die Dateien einer Oracle GoldenGate-Ins- tanz. Unter Windows 7 ist pro Datenbank eine GoldenGate- Instanz notwendig.

Abb.3: GoldenGate-Installationsverzeichnisse (Windows 7)

(20)

INStAllAtION uND kONfIgurAtION 17

Verwendung der Unterverzeichnisse:

Abb.3: GoldenGate-Installationsverzeichnisse (Windows 7)

Abb.4: GoldenGate-Unterverzeichnisse („dirmac“, „dirver“, „dirwlt“ später erstellt)

Name Inhalt

BR Bounded Recover Checkpoint Files

cfg Property- und XML files des GoldenGate Monitor Agents dirbdb Daten-Repository für GoldenGate Monitor oder für den

Enterprise Manager (*) dirchk Extract / Replicat Checkpoint Files

dirdat Standard-Verzeichnis für Local Trails / Remote Trails

(21)

18 prOzESSE

2.5 Prozesse

2.5.1 manager-Prozess

Der Manager-Prozess ist die Voraussetzung für alle Extract- und Replicat-Prozesse, die in einer GoldenGate-Instanz laufen.

Er hat folgende Funktionen:

Name Inhalt

dirdef Verzeichnis für Source Definition Files dirjar Java-Programme des GoldenGate Monitor Agents dirmac Selbstgeschriebene GoldenGate Makros (**) dirout (z.Zt. nicht mehr benutzt)

dirpcs GoldenGate Status Files (Files existieren nur zur Laufzeit) dirprm Parameter Files für alle GoldenGate-Prozesse dirrpt Report Files aller GoldenGate-Prozesse

dirsql Ehemals für TRIGGEN Utility, jetzt für SQL-Skripte genutzt dirtmp Standardverzeichnis zum Speichern großer Transaktionen dirver Verzeichnis für GoldenGate Veridata (***)

dirwlt Oracle Wallet für Passwords des GoldenGate Monitors (****)

* Angelegt durch CREATE DATASTORE bei GoldenGate Monitor-Konfiguration

** Muss bei Bedarf selbst angelegt werden

*** Existiert nur, wenn GoldenGate Veridata installiert ist

**** Angelegt durch PW_AGENT_UTIL.BAT -CREATE bei GoldenGate Monitor-Konfiguration tab.3: GoldenGate Unterverzeichnis (Version 11.2.1.0.1)

(22)

prOzESSE 19

1. Überwachung und Restart der Oracle GoldenGate- Prozesse

2. Reporterstellung bei Schwellwertüberschreitungen (zum Beispiel Latenzzeit)

3. Trail- und Log-File-Verwaltung 4. Speicherbereitstellung

5. Fehler- und Ereignisberichte (Reports) 6. Verarbeitung von Eingaben über das GGSCI

2.5.2 collector-Prozess

Der Collector-Prozess läuft als Hintergrundprozess auf dem Zielsystem, empfängt die durch einen Extract-Prozess übertragenen Informationen und speichert diese in einem Trail beziehungsweise Extract File. Er wird automatisch vom MANAGER gestartet, wenn eine Netzwerkverbindung benötigt wird. In diesem Fall bezeichnet man ihn als „Dy- namic Collector“ mit dem man nicht direkt zu tun hat. Es besteht die Möglichkeit, einen Collector-Prozess manuell zu starten, der dann als „Static Collector“ bezeichnet wird.

Ein dynamisch (automatisch) gestarteter Collector kann nur für einen speziellen Extract-Prozess arbeiten. Ein manuell gestarteter Collector arbeitet für mehrere Extract-Prozesse.

(23)

20 prOzESSE

Die optimale Arbeitsweise ist die Nutzung von Dynamic Collec- tor, weil dabei eine Eins-zu-eins-Beziehung zwischen EXTRACT und COLLECTOR existiert. Darüber hinaus hat man mit dieser Art von Collector keinerlei manuellen Aufwand.

2.5.3 eXtract-Prozess (Primär und sekundär)

Der Extract-Prozess erfasst die Änderungen an den Objekten der Quelldatenbank und legt sie in einem sogenannten Local Trail oder Remote Trail ab. Dazu liest der Extract das Change Log der Datenbank und extrahiert die benötigten Informationen. Bei Oracle beinhalten die Redolog Files die Datenbankänderungen.

Es werden dabei nur Transaktionen der Objekte verarbeitet, die diesem Extract-Prozess zugeordnet und „commited“ sind. Der Extract kann die Online-Redologs und die Archivelogs lesen.

Dabei erfasst er DML-Änderungen und wenn gewünscht auch DDL-Änderungen.

Abb.5: Extract-Prozess schreibt in ein Remote Trail

change

logs ^capture

LAN/WAN/Internet Over TCP/IP

Remote Trail Primärer

Extract

Trial File

Manager Manager

Collector

(24)

prOzESSE 21

Schreibt ein Extract-Prozess ein lokales Trail File, ist die spätere Übertragung dieses Files zur Zielplattform nötig.

Diese Funktionalität realisiert bei GoldenGate der Data- pump-Prozess. Das ist auch ein Extract-Prozess, der aber im Unterschied zum primären EXTRACT ein bereits erstelltes Local Trail File liest und diese Informationen in ein Remote Trail File schreibt. Der Datapump-Prozess wird deshalb auch als sekundärer Extract-Prozess bezeichnet.

Mit der aktuellsten Version 11gR2 wurde der Extract-Pro- zess, der auch häufig als Capture-Prozess bezeichnet wird, funktionell erweitert. Diese Erweiterung betrifft nur die Oracle-Datenbank. Mit INTEGRATED CAPTURE existiert ein zusätzlicher Extract- beziehungsweise Capture-Prozess, der auf der Grundlage von Oracle Streams arbeitet. Es gibt also ab sofort zwei verschiedene Extract- beziehungsweise Capture-Prozesse: CLASSIC CAPTURE und INTEGRATED

Abb.6: Primärer und sekundärer Extract-Prozess

LAN/WAN/Internet Over TCP/IP

Manager Manager

Collector

Primärer

Extract Sekundärer

Extract Local

Trail Remote

Trail change

logs ^Capture ^Trial_File ^Pump ^Trial_File

(25)

22 prOzESSE

CAPTURE. Wie bei Oracle Streams, kann INTEGRATED CAPTURE auch als DOWNSTREAM CAPTURE konfiguriert werden und unterstützt neue Datenformate wie Compression, XML Object Re- lational, XML Binary, Secure Files, Nested Tables und Object Tables.

Mit INTEGRATED CAPTURE nutzt Oracle GoldenGate den Capture- Prozess von Oracle Streams. Die Erzeugung des Capture- Prozesses wird von GoldenGate angestoßen und erfolgt im Hintergrund automatisch. In diesem Dojo gehe ich auf den INTEGRATED CAPTURE nicht ein, weil zum Verständnis Oracle-Streams-Wissen notwendig ist. Informationen dazu findet man in der aktuellen Dokumentation zu Oracle GoldenGate und Oracle Streams.

2.5.4 rePlicat-Prozess

Der Replicat-Prozess liest das Trail File und führt die übermittelten Transaktionen (oder auch DDL-Operationen) auf der Zieldatenbank

Merkmal CLASSIC CAPTURE INTEGRATED CAPTURE

Datenbank Alle unterstützten Plattformen Oracle Enterprise Edition

DOWNSTREAM CAPTURE Nein Ja

Redolog Based Ja Ja

Redolog-Verarbeitung Direkt LogMiner

New Datatypes Nein Ja

tab.4: Gegenüberstellung von CLASSIC CAPTURE und INTEGRATED CAPTURE

(26)

prOzESSE 23

durch. Damit sorgt er dafür, dass der Inhalt der Zieldaten- bank dem Stand in der Quelldatenbank angepasst wird. Im Normalfall sind die Objekte beider Datenbanken danach identisch. Das Replizieren von Änderungen soll in der Regel so schnell wie möglich erfolgen, weil nur so gewährleistet ist, dass auch auf der Zielseite die aktuellsten Datenbestän- de verfügbar sind. Stimmen die Objekte auf Quell- und Zieldatenbank überein, spricht man von einer Eins-zu-eins- Replikation, und die Änderungen können ohne jede Modifi- kation in der Zieldatenbank ausgeführt werden. Ist das nicht der Fall, muss dem Replikationsprozess die Struktur der Objekte der Quelldatenbank mitgeteilt werden. Das wird durch die Bereitstellung eines „Source Definition Files“

dem Replicat-Prozess mitgeteilt. Damit kennt dieser die ursprünglichen Datentypen und kann die Änderungen einer Transaktion für die Zielobjekte anpassen und durchführen.

Es ist weiter möglich, durch Filtern und Transformieren Än- derungen ganz oder teilweise zu verhindern oder Daten vor der Ausführung der Transaktion durch den Replicat-Prozess zu modifizieren beziehungsweise zu verändern. Der Repli- cat-Prozess muss aber noch eine weitere wichtige Funktion übernehmen. Das ist die Behandlung von Konflikten. Kon- flikte entstehen, wenn ein Datenbankobjekt gleichzeitig auf mehr als einer Seite geändert wird (siehe Punkt 3).

(27)

24 trAIl fIlES

2.6 trail Files

Die vom Extract-Prozess gelesenen Redolog-Informationen abgeschlossener Transaktionen werden in sogenannte Golden- Gate Trail Files geschrieben. Diese Trail Files können auf der Quellseite (Local Trail) oder auf der Zielseite (Remote Trail) erstellt werden. Trail Files werden mittels ADD EXTTRAIL (Local Trail) und ADD RMTTRAIL (Remote Trail) definiert. Die Standardgröße beträgt 100 MB und sollte immer auf das Da- tenvolumen der Replikation angepasst werden. Trail Files sind versionsabhängig. Die Version ist im File Header des Trail Files eingetragen. Beim Replizieren in Richtung älterer GoldenGate- Versionen muss der Extract-Prozess das Trail File im älteren Format erstellen, sodass der Replicat-Prozess es lesen kann (Parameter FORMAT bei ADD EXTTRAIL beziehungsweise ADD RMTTRAIL). Der Name des Trail Files ist abhängig vom Parameter TRAIL_NAME in der ADD-Anweisung:

Der Name eines Trail Files wird durch zwei beliebige Buch- staben (im Beispiel „rt“ für „remote trail“) und einer fortlau- fenden sechsstelligen Nummer gebildet. Trail Files werden

TRAIL_NAME Trail-File-Namen d:\ogg_new_src\dirdat\tstact\rt rt000000 bis rt999999 d:\ogg_new_tar\dirdat\tstact\rt rt000000 bis rt999999 tab.5: Bildung der Trail-File-Namen

(28)

INStANtIIEruNg uND INItIAl-lOAD 25

standardmäßig im Unterverzeichnis „dirdat“ angelegt. In Tabelle 5 sehen Sie, wie die Trail Files im Replikationsbei- spiel im zweiten Teil des Dojo heißen werden. Sie befinden sich nicht direkt im Verzeichnis „dirdat“, sondern in einem weiteren Unterverzeichnis „tstact“. Dieser Verzeichnispfad muss vor dem Start des Extract-Prozesses manuell angelegt werden. Die Files haben in beiden GoldenGate-Instanzen die gleichen Namen. Extract- und Replicat-Prozess erstellen jeweils Checkpoint-Informationen, mit der augenblickli- chen Schreib- beziehungsweise Leseposition im Trail File.

Diese Informationen ermöglichen jederzeit den Neustart eines GoldenGate-Prozesses nach dem Stoppen oder nach Abbruch durch einen Fehler (zum Beispiel Netzwerkaus- fall). Die Checkpoint-Informationen werden im Verzeichnis

„dirchk“ gespeichert. Es wird empfohlen, für den Replicat- Prozess eine Checkpoint Table in der Zieldatenbank zu benutzen. Im zweiten Teil des Dojo benutzen die beiden Replicat-Prozesse eine spezifische Checkpoint Table, die immer nur von einem Replicat-Prozess genutzt werden kann.

2.7 instantiierung und initial-load

Unter INITIAL-LOAD versteht man die Bereitstellung der Replikationsobjekte auf der Zielseite beziehungsweise in der Zieldatenbank mit oder ohne Inhalt. Die Objekte auf

(29)

26 INStANtIIEruNg uND INItIAl-lOAD

der Zielseite (zum Beispiel Tabellen) können dabei auch völlig anders aussehen als auf der Quellseite. Abhängig von einer geplanten Replikation umfasst das eine oder mehrere dieser Aktionen:

1. Anlegen der Objekte in der Zieldatenbank 2. Export auf Quelldatenbank und Import

in Zieldatenbank

3. Create Table As Select (CTAS)

Das Wichtigste bei der Instantiierung ist die Konsistenz der Daten der Replikationsobjekte. Oracle GoldenGate kennt den Begriff der „Commit Sequence Number“ (CSN). Da jede erfolgreiche Transaktion mit einem COMMIT endet, hat jede Transaktion eine bestimmte CSN. Die Konsistenz der Daten-

Begriff Erklärung Hinweis

Instantiierung Festlegen des Beginnpunktes für das Replizieren in die Zieldatenbank Startposition für Replicat- Prozess

Betrifft jede Zieldatenbank unidirektional: sekundäre Datenbank

bidirektional: sekundäre und primäre Datenbank

INITIAL-LOAD Erstellung und Befüllung der Replikationsobjekte auf der sekundären Datenbank

Betrifft Objekte und deren Inhalt, ist nicht immer notwendig und findet nur für die sekundäre Datenbank statt tab.6: Instantiierung und INITIAL-LOAD

(30)

INStANtIIEruNg uND INItIAl-lOAD 27

bank basiert auf abgeschlossenen Transaktionen. Verhindert man den Beginn neuer Transaktionen, dann ist die Daten- bank nach Beendigung der laufenden Transaktionen zu einer bestimmten CSN konsistent. Jedes Datenbanksystem generiert eigene, eindeutig fortlaufende Nummern für jede Transaktion. Bei Oracle ist das die „System Change Num- ber“ (SCN). Wie das Äquivalent für die CSN bei anderen un- terstützten GoldenGate-Plattformen aussieht, beschreiben die einzelnen GoldenGate Administrator’s Guides. Instanti- ierung und INITIAL-LOAD am Beispiel einer Oracle-Oracle- Replikation sehen deshalb immer so aus:

INITIAL-LOAD findet immer nur in der sekundären Daten- bank statt. Entschließt man sich, auch in die entgegenge- setzte Richtung zu replizieren, also von der sekundären zur

Abb.7: INITIAL-LOAD und Instantiierung Zeit

t1 t2 t3 t4 t5 t6

Datensicherung konsistent zu

Scn x InITIal-lOaD

konsistent zu Scn x

Instantiierung: Scn x+1 replikation beginnt bei

Scn x+1 sekundäre datenbank Primäre datenbank

(31)

28 gOlDENgAtE SOftWArE COMMAND INtErfACE (ggSCI)

primären Datenbank, findet kein INITIAL-LOAD statt, weil die Replikationsobjekte schon existieren. Die Instantiierung muss dagegen auch für diese Replikationsrichtung auf der primären Datenbank stattfinden. Es sind natürlich Sonder fälle möglich, in denen parallel zu einer Replikation eine weitere Replikation in die Gegenrichtung stattfinden könnte, zum Beispiel für Objekte aus einem anderen Schema. Man sollte aber immer die Übersichtlichkeit wahren, logisch strukturiert vorgehen und eine sekundäre Datenbank nicht gleichzeitig als primäre Datenbank betreiben.

2.8 goldengate soFtware command interFace (ggsci)

GoldenGate stellt eine eigene Kommandoumgebung bereit, den Oracle GoldenGate Command Interpreter. Aktiviert wird diese Umgebung durch Eingabe des Kommandos GoldenGate Software Command Interface (GGSCI) in einem Command-Prompt-Fenster (siehe Abbildungen 8, 9 und 10).

Nach Eingabe des Kommandos GGSCI befindet man sich in der GoldenGate-Kommandoumgebung.

Hier kann man einzelne GoldenGate-Kommandos eingeben oder OBEY-Kommando-Files abarbeiten.

(32)

gOlDENgAtE SOftWArE COMMAND INtErfACE (ggSCI) 29

Abb.8: Öffnen eines Command-Prompt-Fensters unter Windows 7

Abb.9: Aufruf des GoldenGate Command Interpreter

1.

GoldenGate Installations-

Verzeichnis auswählen

2.

Rechter Mausklick

3.

Öffnen mit Mausklick

(33)

30 gOlDENgAtE SOftWArE COMMAND INtErfACE (ggSCI)

2.8.1 goldengate-kommandos

Es existieren Kommandogruppen für die einzelnen GoldenGate- Prozesse und für spezifische GoldenGate-Funktionalitäten.

Abb.10: GoldenGate Command Interpreter – Beginnmeldungen

Gruppe Kommandos

Manager Commands (Manager Process)

INFO, SEND, START,STATUS, STOP

Extract Commands (Extract Process)

ADD, ALTER, CLEANUP, DELETE, INFO, KILL, LAG, SEND, START, STATS, STATUS, STOP

Replicat Commands (Replicat Process)

(siehe extract commands) ER Commands

(Multiple E/R Processes)

INFO, KILL, LAG, SEND, START, STATS, STATUS, STOP

(34)

gOlDENgAtE SOftWArE COMMAND INtErfACE (ggSCI) 31

2.8.2 kommando obeY

Zur Erleichterung der Arbeit besteht die Möglichkeit, Kom- mandos in einem Flat File abzulegen. Mit dem Kommando OBEY wird dieses File dann aufgerufen und die Komman- dos werden der Reihe nach abgearbeitet. Diese Kommando- Files haben unter Windows die Filenamen-Erweiterung

„OBY“. Diese Funktionalität wird im Beispiel genutzt, um Kommandos für das Aufsetzen und Löschen der Replikati- onsumgebung auszuführen. Pro Datenbank gibt es dabei einen Setup- und einen Cleanup-Skript mit GoldenGate- Kommandos (siehe Teil 2, Punkt 8.4)

Gruppe Kommandos

Trail Commands (EXTTRAIL/RMTTRAIL)

ADD, ALTER, DELETE, INFO

Database Commands DBLOGIN, ENCRYPT PASSWORD, LIST TABLES Trandata Commands

(Logging)

ADD, DELETE, INFO

Checkpoint Table

Commands ADD, CLEANUP, DELETE, INFO

Oracle Trace Table

Commands ADD, DELETE, INFO

DDL Commands DUMPDDL

Miscellaneous

Commands !, ALLOWNESTED, CREATE SUBDIRS, FC, HELP, HISTORY,

INFO ALL, INFO MARKER, OBEY, SHELL, SHOW, VERSIONS, VIEW GGSEVT, VIEW REPORT tab.7: Kommandogruppen

(35)

32 WANN ENtStEHEN kONflIktE?

3 Konfliktbehandlung

3.1 wann entsteHen konFlikte?

Bei der Replikation werden die Änderungen an Datenbank - objekten einer Datenbank (Quelle) zu einer anderen Daten- bank (Ziel) übertragen und dort ebenfalls ausgeführt. Damit hält man beide Datenbanken synchron und verfügt in beiden Datenbanken über aktuelle Datenbankobjekte. Das funktio- niert aber nur, solange die Datenbankobjekte der Zieldaten- bank ausschließlich durch die Replikation verändert werden.

Erfolgen noch Änderungen an den Zielobjekten von anderer Seite, kann es zu folgenden Situationen kommen:

INSERT ein Datensatz, der durch die Replikation eingefügt werden soll, existiert schon

UPDATE bei der Änderung des Inhalts einer Spalte stimmt der Spalteninhalt der Quelldatenbank nicht mit dem Spalten- inhalt der Zieldatenbank überein (BEFORE-IMAGE falsch!) DELETE ein Datensatz, der gelöscht werden soll, existiert nicht mehr

(36)

vErMEIDuNg vON kONflIktEN 33

3.2 Vermeidung Von konFlikten

Am einfachsten vermeidet man Konflikte, indem man nur einer Anwendung erlaubt Datenänderungen vorzunehmen.

Bei einer Aktiv-Aktiv-Replikation ist das aber nicht realisier- bar, weil Änderungen von mindestens zwei Seiten gemacht werden können. In solchen Fällen sollte durch technologi- sche Regelungen bestimmt werden, dass Datenbankobjekte beziehungsweise auch Spalten von Objekten nur durch eine Seite verändert werden dürfen. Man könnte zum Beispiel die Erlaubnis zum Ändern von Daten auf bestimmte Länder, Regionen oder Kunden begrenzen, sodass Daten immer nur durch eine festgelegte Seite geändert werden dürfen. DELETE-Konflikte verhindert man dadurch, dass Anwendungen den Datensatz nicht löschen, sondern nur als gelöscht kennzeichnen. Dazu muss das Datenbankobjekt (zum Beispiel die Tabelle) eine zusätzliche Spalte für diese Art der Kennzeichnung beinhalten. Weiterhin muss Anwen- dungslogik implementiert werden, die im Falle von Wider- sprüchen einen Lösungsweg definiert. Die Vermeidung von Konflikten sollte deshalb so früh wie möglich berücksichtigt werden, am besten schon bei der Planung und Erstellung des Datenmodells. Ist das nicht möglich, sind in vielen Fällen logische Änderungen für eine geplante Replikation notwendig oder zumindest vorteilhaft.

(37)

34 StANDArDkONflIktlöSuNgEN

3.3 standardkonFliktlösungen

In der Praxis zeigt sich immer wieder, dass bei jeder Replika- tion Konflikte auftreten, obwohl vorher nicht damit gerechnet wurde. Oracle Streams verfügt deshalb schon seit mehreren Jahren über Standardkonfliktlösungen, die ab Version 11.2.1.0.1 unter der Bezeichnung „Conflict Detection and Resolution“ (CDR) auch in Oracle GoldenGate implementiert wurden:

INSERTROWEXISTS Datensatz existiert schon UPDATEROWEXISTS Datensatz existiert, aber BEFORE-IMAGE stimmt nicht überein UPDATEROWMISSING Datensatz existiert nicht DELETEROWEXISTS Datensatz existiert,

aber mindestens ein BEFORE-IMAGE stimmt nicht überein DELETEROWMISSING Datensatz existiert nicht

CDR steht für Datenbanken aller Plattformen außer „Non- Stop“ bereit und unterstützt die Datentypen NUMERIC, DATE, TIMESTAMP, CHAR/NCHAR und VARCHAR/NVAR- CHAR, das heißt Spalten dieser Datentypen können bei GETBEFORECOLS und COMPARECOLS verwendet werden.

Die verfügbaren Standardkonfliktlösungen sind: USEMIN, USEMAX, USEDELTA, DISCARD, OVERWRITE und IGNORE.

(38)

StANDArDkONflIktlöSuNgEN 35

USEDELTA ist nur für Datentyp NUMERIC möglich. Um Konflikte zu erkennen und zu behandeln, müssen Extract- und Replicat-Prozess entsprechend konfiguriert werden.

Tabelle 8 zeigt die Parameter, die in der TABLE-Anweisung (EXTRACT) beziehungsweise in der MAP-Anweisung (REPLI- CAT) anzugeben sind, um sowohl die Konflikterkennung als auch die Konfliktlösung zu aktivieren:

EXTRACT REPLICAT Konflikterkennung Konfliktlösung ---

GETBEFORECOLSoder --- Nein Nein

GETBEFORECOLS COMPARECOLS Ja Nein

GETBEFORECOLS COMPARECOLS

RESOLVECONFLICT Ja Ja

tab.8: Voraussetzungen für die Konfliktbehandlung

Syntax der Anweisungen

Die Anweisungen zur CONFLICT DETECTION and

RESOLUTION (CDR) der GoldenGate Version 11gR2 sind nicht kompatibel mit Anweisungen früherer

Versionen.

(39)

36 glObAlISIEruNg

4 Globalisierung

Wie schon erwähnt, unterstützt GoldenGate eine Vielzahl von Plattformen (siehe Punkt 2.3). Auf diesen Plattformen werden unterschiedliche Zeichensätze (Character Sets) verwendet. Für die Replikation zwischen unterschiedlichen Systemen müssen die Daten zwischen diesen Zeichensätzen konvertiert werden. In der Oracle-Welt kennen wir den Parameter NLS_LANG zur Spezifi- kation des korrekten Character Sets der Oracle Client Sessions. Für die hier gezeigte Aktiv-Aktiv-Replikation einer Tabelle zwischen zwei Oracle-Datenbanken auf identischer Plattform spielt die Globalisierungsproblematik keine Rolle. Da aber die GoldenGate- Prozesse aus Sicht des Datenbankservers auch Client Sessions sind, werde ich hier noch auf den Parameter SETENV eingehen.

Globalisierung in Oracle GoldenGate 11gR2 beinhaltet alle Themen, die in Tabelle 9 aufgeführt sind.

In den Parameter Files der Aktiv-Aktiv-Replikation im zweiten Teil des Dojo ist NLS_LANG nicht explizit gesetzt. Wie in Tabelle 9 dargestellt, leitet sich dieser Parameter für den Extract-Prozess von der Quelldatenbank und für die GoldenGate-Kommando- umgebung und den Replicat-Prozess vom Betriebssystem ab. Da im Beispiel überall das gleiche Character Set zu finden ist, wurde auf die Angabe des Parameters

SEtENv (NlS_lANg = “AMErICAN_AMErICA.WE8MSWIN1252“)

verzichtet.

(40)

glObAlISIEruNg 37

Thema Gegenstand Erläuterung

Character Set Conversion(CS)

Database, Session/Client, Operating System and

Terminal CS Parameter, Trail and

Definition File

Datenbank CS Konfiguration hängt von der Datenbank ab, CS wird über Parameter gesetzt, gilt auch für Redolog-Daten, für GG gilt Session CS,

Terminal CS = NLS_LANG! (Oracle) Trail Files können anderes CS haben

→Info im Trail oder Definition File siehe Parameter: NOEXTATTR Partial CS

Conversion Local Trail or Remote Trail Ab 11gR2 Datenbank CS Info im Local Trail/

Remote Trail File

siehe Parameter: _TRAILCHARSET Object Name

Enhancements Case Sensitivity, Wildcard, Parameter Syntax Change,

Limitations

Unterstützt Umlaute (zum Beispiel: ä, Ä),

„Multi Byte Characters“, Leerzeichen, Klein- und Großbuchstaben siehe Parameter: _CASESENSITIVE Native

Database Error Message

Support

Capture Native Database Error Messages and output to

Report File

Erfordert sprachkompatibles Betriebssystem (zum Beispiel: keine korrekte Darstellung japanischer Meldungen unter deutschem Betriebssystem)

Implicit NLS_LANG

Setup

GG sets NLS_LANG if it is not

set or incorrect Parameter wird abgeleitet für:

Extract → immer Datenbank-Zeichensatz GGSCI → Betriebssystem-Zeichensatz Replicat → Betriebssystem-Zeichensatz Achtung → selbst richtig setzen!!!

User Token Name and Value in Trail File „Multi Byte Characters“ möglich Parameters New

in 11gR2

SESSIONCHARSET NOEXTATTR

CHARSET UPDATECS USEANSISQLQUOTES _NOCHARSETCONVERSION

_TRAILCHARSET

Nicht alle diese Parameter betreffen eine Oracle-Datenbank. Zur Bedeutung bitte nachschauen im:

„Windows and Unix Reference Guide“

(siehe Punkt 9.1)

tab.9: Voraussetzungen für die Konfliktbehandlung

(41)

38 glObAlISIEruNg

Das führt aber zu einer Meldung vom Typ WARNING beim Starten der Prozesse (siehe Punkt 8.8.3):

Replicat RE2SECO:

2012-08-13 15:21:18 INfO Ogg-03501 WArNINg:

NlS_lANg environment variable is invalid or not set.

using operating system character set value of WE8MSWIN1252.

Extract EX2PRIO:

2012-08-13 15:20:45 INfO Ogg-03500 WArNINg:

NlS_lANg environment variable does not match database character set,

or not set. using database character set value of WE8MSWIN1252.

Den Einträgen in Tabelle 9 entsprechend, werden beide Charac- ter Sets abgeleitet. Beim Replicat-Prozess ist das immer korrekt.

Gefahr besteht aber für den Replicat-Prozess. Im Falle einer plattformübergreifenden Replikation könnte der Replicat- Prozess einen falschen Zeichensatz benutzen, wenn Betriebs- system- und Datenbank-Zeichensatz unterschiedlich sind. Es ist immer zu empfehlen, NLS_LANG entsprechend zu setzen.

Damit vermeidet man mögliche Fehler durch Ableitung des Parameters und bekommt auch keine Warnungsmeldungen in den Report Files.

(42)

ÜbErSICHt 39

Parameter NLS_LANG: LANGUAGE_TERRITORY.CHARSET

Zu beachten sind neben dem Character Set auch die anderen beiden Bestandteile des Parameters NLS_LANG. Sie bestimmen die Standardkonventionen für die Datenbank- nachrichten, die Tages- und Monatsnamen, die Sortierrei- henfolge (LANGUAGE), die Datumsangabe, das Währungs- zeichen und für die numerischen Formate (TERRITORY).

Das sind weitere Gründe dafür, den Parameter explizit anzugeben. Im Report File würde das dann so aussehen:

...

-- Set Environment SEtENv (NlS_lANg = "AMErICAN_AMErICA.WE8MS- WIN1252")

Set environment variable (NlS_lANg=AMErICAN_AMErICA.WE8MS- WIN1252)

...

5 Sicherheit

5.1 ÜbersicHt

Im Rahmen dieses Dojo werden die Sicherheitsfunktionen von GoldenGate nur überblicksweise behandelt. Schwer- punkt für eine sichere Replikation ist die Verschlüsselung der Daten beginnend beim Extract-Prozess über das Ablegen in Local Trail oder Remote Trail Files bis hin zur erfolgreichen

(43)

40 pASSWOrt-vErSCHlÜSSEluNg

Verarbeitung durch den Replicat-Prozess auf der Zieldaten- bank. Auch die Arbeit mit verschlüsselten Passwörtern ist unterstützt (siehe nächster Punkt). In der Aktiv-Aktiv- Replikation (Teil 2) wird auf Verschlüsselung verzichtet, weil beide GoldenGate-Instanzen lokal auf dem gleichen Rechner laufen und die replizierte Tabelle auch keine schützenswerten Daten beinhaltet. Erwähnen möchte ich noch drei weitere Funktionen zur Erhöhung der Sicherheit in der Replikations- umgebung: Das ist die Kommandoautorisierung, der Verbindungsaufbau von einem sicheren Zielsystem zu einem Quellsystem außerhalb der Firewall sowie die Möglichkeit, Passwörter zu verstecken. In Tabelle 10 sind alle GoldenGate- Sicherheitsfunktionen aufgeführt. An dieser Stelle möchte ich darauf hinweisen, dass die in der Tabelle aufgeführte Sicher- heitsfunktion „Hide Password“ in der Aktiv-Aktiv-Replikation im zweiten Teil für den Extract-Prozess EX2PRIO genutzt wird (siehe Punkt 8.3.1).

5.2 Passwort-VerscHlÜsselung

Sicherer als das Verstecken eines Passworts ist dessen Ver- schlüsselung. Oracle GoldenGate bietet dazu verschiedene Möglichkeiten an. Der BLOWFISH-Algorithmus kann mit einem selbst erzeugten oder einem Standardschlüssel (DE- FAULT KEY) arbeiten. Die AES-Algorithmen benötigen immer selbst erzeugte Schlüssel. Mit dem GGSCI-Kommando