Oracle GoldenGate 11gR 2 - Oracle Data Warehouse Community

Transcription

OR ACLE DOJO NR.
6
Oracle GoldenGate 11gR2
–
Aktiv-Aktiv-Replikation
JOACHIM JAENSCH
Oracle
Oracle
Dojo
Dojo
ist eine
ist eine
Serie
Serie
vonvon
Heften,
Heften,
die die
Oracle
Oracle
Deutschland
Deutschland
B.V.B.V.
zu unterschiedlichsten
zu unterschiedlichsten
Themen
Themen
ausaus
derder
Oracle-Welt
Oracle-Welt
herausgibt.
herausgibt.
DerDer
Begriff
Begriff
Dojo
Dojo
[‘do:d
[‘do:d
o] kommt
ausaus
demdem
japanischen
japanischen
KampfKampf3o] 3kommt
sport
sport
undund
bedeutet
bedeutet
Übungshalle
Übungshalle
oder
oder
Trainingsraum.
Trainingsraum.
Als Als
„Trainingseinheiten“,
„Trainingseinheiten“,
die die
unseren
unseren
Anwendern
Anwendern
helfen,
helfen,
ihreihre
Arbeit
Arbeit
mitmit
Oracle
Oracle
zu perfektionieren,
zu perfektionieren,
sollen
sollen
auch
auch
die die
Oracle
Oracle
Dojos
Dojos
verstanden
verstanden
werden.
werden.
ZielZiel
ist es,
ist es,
Oracle-Anwendern
Oracle-Anwendern
mitmit
jedem
jedem
Heft
Heft
einen
einen
schnellen
schnellen
undund
fundierten
fundierten
Überblick
Überblick
zu einem
zu einem
abgeabgeschlossenen
schlossenen
Themengebiet
Themengebiet
zu bieten.
zu bieten.
Im Im
Oracle
Oracle
Dojo
Dojo
Nr. Nr.
6 beschäftigt
6 beschäftigt
sichsich
Joachim
Joachim
Jaensch,
Jaensch,
Leitender
Leitender
System
System
berater
berater
bei bei
Oracle
Oracle
Deutschland
Deutschland
B.V.B.V.
undund
zuständig
zuständig
für für
dasdas
Thema
Thema
Replikation
Replikation
undund
Integration,
Integration,
mitmit
Oracle
Oracle
GoldenGate.
GoldenGate.
Dieses
Dieses
Dojo
Dojo
bietet
bietet
Ihnen
Ihnen
einen
einen
wunderbaren
wunderbaren
Einstieg
Einstieg
undund
eineeine
gute
gute
Hilfe
Hilfe
beim
beim
Aufbau
Aufbau
vonvon
verteilten
verteilten
Umgebungen.
Umgebungen.
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
TeilTeil
II I– –Replikationsbeispiel
Überblick
7 1GoldenGate-Installation
Was versteht man unter63
Datenreplikation?
8 2Aufbau
einer Aktiv-Aktiv-Replikation
Replikation
mit Oracle GoldenGate
8.12.1Überblick
und8Voraussetzungen
Überblick
8.22.2Voraussetzungen
Einsatzgebiete
6
66
8
67
in11primärer und sekundärer Datenbank 69
8.2.12.3ARCHIVELOG
69
UnterstützteMode
Plattformen
14
8.2.22.4Supplemental
Logging
72
Installation und
Konfiguration
8.2.32.5Das
Replikationsobjekt
Prozesse
18
8.2.4
Admin-User
2.5.1GoldenGate
Manager-Prozess
18
8.2.5
82
2.5.2Instantiierung
Collector-Prozess
15
73
80
19
8.3
der GoldenGate-Parameterdateien
2.5.3Aufbau
Extract-Prozess
(primär und sekundär) 2083
8.3.1
eines Connect-Makros
2.5.4Erstellen
Replicat-Prozess
22
8.3.22.6Datei
TrailGLOBALS
Files 24
84
und Manager-Parameter 85
8.3.32.7Extractund Replicat-Parameter
88
Instantiierung
und INITIAL-LOAD
8.42.8OBEY-Kommando-Files
GoldenGate Software
25
90
Command
Interface (GGSCI) 28
8.4.1
Datenbank 91
2.8.1Primäre
GoldenGate-Kommandos
30
8.4.2
Datenbank
2.8.2Sekundäre
Kommando
OBEY 3193
8.5 3Einrichten
der Replikationsumgebung
Konfliktbehandlung
32
(OBEY Files) 95
8.63.1Starten
Stoppen
der Replikation
Wannund
entstehen
Konflikte?
32
102
8.73.2Kontrolle
der Replikation
108
Vermeidung
von Konflikten
33
8.83.3Einbau
einer UPDATE-Konfliktlösung
Standardkonfliktlösungen
34
111
8.8.1 4Ergänzen
der GoldenGate-Parameterdateien
Globalisierung
36
8.8.2 5Test
der Konfliktbehandlung
Sicherheit
39
8.8.35.1GoldenGate
Übersicht
Reports
125
39
8.95.2Löschen
der Replikationsumgebung
Passwort-Verschlüsselung
40
9 6Schlusswort
147
Administration
138
und Überwachung 44
106.1Weitere
Informationenund
150-Reports
GGSCI-Kommandos
6.2
44
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
111
116
Oracle GoldenGate Veridata 59
Or acle Dojo nr.
JOACHIM JAENSCH
Oracle GoldenGate 11gR2
–
Aktiv-Aktiv-Replikation
6

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 Datenbanksystemen. 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 Replikations- und Integrationstechnologie und setzt Maßstäbe im
Bereich der verteilten Systeme und das nicht nur im homogenen Oracle-Umfeld.
3
4
Für Oracle GoldenGate bieten sich vielfältige Einsatzmöglichkeiten. Man findet es oft als zentrale Komponente bei hochverfügbaren verteilten Konfigurationen, in Replikationsumgebungen 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 GoldenGate bietet, ist die Basis für bessere und stabilere IT-Systeme.
Ich freue mich sehr, dass Joachim Jaensch, einer unserer erfahrensten 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 Umgebungen.
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!
5

Teil I
GoldenGate 11gR2
Überblick
6
Was versteht man unter Datenreplikation?
1 Was versteht man unter
Datenreplikation?
Informationen beziehungsweise Daten bilden eine wichtige
Grundlage für den Erfolg eines Unternehmens. Sie dienen entweder der reibungslosen Produktion oder der Vorbereitungvon
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ändergrenzen. 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, Unternehmensdaten 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 Internetzeitalter weltweite TCP/IP-Netzwerke nutzen, um Informationen und Daten zu verteilen. In den letzten Jahren sind Softwarelö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 Replikation. Bei der synchronen Replikation
wird eine Änderung am Datenobjekt nur wirksam, wenn sie
auf der Quell- und der Zieldatenbank erfolgreich war. Das hat
7

Was versteht man unter Datenreplikation?
einen Nachteil: Nur wenn die Änderung auf beiden Seiten
erfolgreich war, wird weitergearbeitet, bei Netzwerkausfall 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
Replikationsverfahren sind: File Transfer, Primary Copy,
Snapshot Replication und Log-based-Replication. In diesem
Dojo wird nur die zuletzt genannte Art der Replikation betrachtet, die der von Oracle GoldenGate entspricht.
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
Abb.1: Replikationsszenarien
In der Praxis findet man häufig Kombinationen der abgebildeten
Replikationstopologien.
8 Überblick
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 uni
direktional 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
Überblick
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 Erstellung 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 Komponenten zusätzlich lizenziert werden. Die Konfiguration
einer GoldenGate-Replikation erfolgt über Parameter, die in
plattformspezifischen Flat Files abgelegt werden. Die Steuerung der Replikationsprozesse (zum Beispiel Startenund
Stoppen) erfolgt über das auf allen unterstützten Plattformen 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 Erstbefüllung der Zielseite mit den zu replizierenden Objekten.
9
10 Source
Tables
Capture
Manager
Change
Logs
LAN/WAN/
Internet
Over TCP/IP
Capture
Optional
Source
Oracle or
Non-Oracle
Database
Trial
Trial
File
File
Capture
Abb.2: GoldenGate-Architektur
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 Zielobjekte nach
Abschluss der Erstbefüllung durchzuführen.
11
INITIAL-LOAD
Delivery
Manager
Collector
Trial
Trial
File
File
Delivery
1. Change Synchronization
and then
2. Continous Replication
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 Schnelligkeit, 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.
12 Einsatzgebiete
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 Replikation. Für Database Upgrades oder Database Migrations
ist eigentlich nur die unidirektionale Replikation notwendig.
Da man aber Fehler niemals völlig ausschließen kann,
bereitet man für diese Fälle auch eine Replikation für den
Einsatzgebiete
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 Besonderheit zu GoldenGate hinweisen: Viele Unternehmen nutzen
SAP-Installationen auf Grundlage einer Oracle-Datenbank.
Oracle bietet in enger Zusammenarbeit mit dem SAP Solution 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 Datenbankgröß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.
13
14 Unterstützte Plattformen
Für den Zugang auf die Support-Portale von SAP und
Oracle ist ein User-Account notwendig.
Name des Dokuments
SAP / Oracle Support Note
Oracle to Oracle Online Migrations
– Triple O
https://service.sap.com
Using Oracle GoldenGate with
Online SAP Migrations
https://support.oracle.com
SAP - 1508271
Oracle - 1169023.1
Tab.1: Support Notes zu Oracle-to-Oracle Online
2.3
Unterstützte Plattformen
Database
Log-Based Capture
Non-Log_Based
Replication
Capture**
c-tree***
X
X
DB2 for i
X
X
DB2 for Linux,
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
UNIX, Windows
Tab.2: GoldenGate-Replikationsplattformen (Version 11.2.1.0.4)
15
Installation und Konfiguration Database
Log-Based Capture
Non-Log-Based
Replication
Capture**
Teradata
X
X
PostgreSQL*
X
TimesTen*
X
Generic ODBC*
X
* 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
2.4
Installation und Konfigur ation
Oracle GoldenGate gibt es für eine Vielzahl unterschiedlicher Datenbanken und Daten-Management-Systeme. GoldenGate 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. E
ntpacken des Zip-Files in einen Installation-Folder
(Ordner, Verzeichnispfad)
2. Ö
ffnen des Command Prompt und Aufruf des GoldenGate Software Command Interface (GGSCI)
3. Ausführen des Kommandos: CREATE SUBDIRS
16 Installation und Konfiguration
4. Z
usätzliche Unterverzeichnisse anlegen
(zum Beispiel „dirmac“)
5. E
rstellen des Files: GLOBALS
(empfohlen, um Standards zu ändern!)
Abb.3: GoldenGate-Installationsverzeichnisse (Windows 7)
Die beiden Ordner „ogg_new_src“ und „ogg_new_tar“
beinhalten jeweils die Dateien einer Oracle GoldenGate-Instanz. Unter Windows 7 ist pro Datenbank eine GoldenGateInstanz notwendig.
Installation und Konfiguration Abb.4: G
oldenGate-Unterverzeichnisse
(„dirmac“, „dirver“, „dirwlt“ später erstellt)
Verwendung der Unterverzeichnisse:
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
17
18 Prozesse
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 (****)
Tab.3: GoldenGate Unterverzeichnis (Version 11.2.1.0.1)
* 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
2.5
Prozesse
2.5.1Manager-Prozess
Der Manager-Prozess ist die Voraussetzung für alle Extractund Replicat-Prozesse, die in einer GoldenGate-Instanz laufen.
Er hat folgende Funktionen:
Prozesse
1. Überwachung und Restart der Oracle GoldenGateProzesse
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.2Collector-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 „Dynamic 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.
19
20 Prozesse
Die optimale Arbeitsweise ist die Nutzung von Dynamic Collector, 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.3Extr act-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.
Manager
Manager
LAN/WAN/Internet
Over TCP/IP
Change
Logs
Capture
Collector
Primärer
Extract
Abb.5: Extract-Prozess schreibt in ein Remote Trail
Trial
File
Remote
Trail
21
Prozesse
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.
Manager
Change
Logs
Manager
LAN/WAN/Internet
Over TCP/IP
Capture
Primärer
Extract
Trial
File
Local
Trail
Pump
Collector
Sekundärer
Extract
Trial
File
Remote
Trail
Abb.6: Primärer und sekundärer Extract-Prozess
Mit der aktuellsten Version 11gR2 wurde der Extract-Prozess, 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
22 Prozesse
APTURE. Wie bei Oracle Streams, kann INTEGRATED CAPTURE
C
auch als DOWNSTREAM CAPTURE konfiguriert werden und
unterstützt neue Datenformate wie Compression, XML Object Relational, XML Binary, Secure Files, Nested Tables und Object Tables.
Merkmal
Datenbank
CLASSIC CAPTURE
INTEGRATED CAPTURE
Alle unterstützten Plattformen
Oracle Enterprise Edition
Nein
Ja
DOWNSTREAM CAPTURE
Redolog Based
Redolog-Verarbeitung
New Datatypes
Ja
Ja
Direkt
LogMiner
Nein
Ja
Tab.4: Gegenüberstellung von CLASSIC CAPTURE und INTEGRATED CAPTURE
Mit INTEGRATED CAPTURE nutzt Oracle GoldenGate den CaptureProzess 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.4Replicat-Prozess
Der Replicat-Prozess liest das Trail File und führt die übermittelten
Transaktionen (oder auch DDL-Operationen) auf der Zieldatenbank
Prozesse
durch. Damit sorgt er dafür, dass der Inhalt der Zieldatenbank 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ände verfügbar sind. Stimmen die Objekte auf Quell- und
Zieldatenbank überein, spricht man von einer Eins-zu-einsReplikation, und die Änderungen können ohne jede Modifikation 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 Änderungen ganz oder teilweise zu verhindern oder Daten vor
der Ausführung der Transaktion durch den Replicat-Prozess
zu modifizieren beziehungsweise zu verändern. Der Replicat-Prozess muss aber noch eine weitere wichtige Funktion
übernehmen. Das ist die Behandlung von Konflikten. Konflikte entstehen, wenn ein Datenbankobjekt gleichzeitig auf
mehr als einer Seite geändert wird (siehe Punkt 3).
23
24 Trail Files
2.6
Tr ail Files
Die vom Extract-Prozess gelesenen Redolog-Informationen
abgeschlossener Transaktionen werden in sogenannte GoldenGate 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 Datenvolumen der Replikation angepasst werden. Trail Files sind
versionsabhängig. Die Version ist im File Header des Trail Files
eingetragen. Beim Replizieren in Richtung älterer GoldenGateVersionen 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:
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
Der Name eines Trail Files wird durch zwei beliebige Buchstaben (im Beispiel „rt“ für „remote trail“) und einer fortlaufenden sechsstelligen Nummer gebildet. Trail Files werden
Instantiierung und INITIAL-LOAD
standardmäßig im Unterverzeichnis „dirdat“ angelegt. In
Tabelle 5 sehen Sie, wie die Trail Files im Replikationsbeispiel 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 augenblicklichen 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 Netzwerkausfall). Die Checkpoint-Informationen werden im Verzeichnis
„dirchk“ gespeichert. Es wird empfohlen, für den ReplicatProzess 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
Unter INITIAL-LOAD versteht man die Bereitstellung der
Replikationsobjekte auf der Zielseite beziehungsweise in
der Zieldatenbank mit oder ohne Inhalt. Die Objekte auf
25
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 DatenBegriff
Erklärung
Hinweis
Instantiierung
Festlegen des Beginnpunktes
für das Replizieren in die
Zieldatenbank
Betrifft jede Zieldatenbank
Startposition für ReplicatProzess
INITIAL-LOAD
Erstellung und Befüllung der
Replikationsobjekte auf der
sekundären Datenbank
Tab.6: Instantiierung und INITIAL-LOAD
unidirektional: sekundäre
Datenbank
bidirektional: sekundäre und
primäre Datenbank
Betrifft Objekte und deren
Inhalt, ist nicht immer
notwendig und findet nur für
die sekundäre Datenbank statt
27
bank basiert auf abgeschlossenen Transaktionen. Verhindert
man den Beginn neuer Transaktionen, dann ist die Datenbank 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 Number“ (SCN). Wie das Äquivalent für die CSN bei anderen unterstützten GoldenGate-Plattformen aussieht, beschreiben
die einzelnen GoldenGate Administrator’s Guides. Instantiierung und INITIAL-LOAD am Beispiel einer Oracle-OracleReplikation sehen deshalb immer so aus:
Primäre Datenbank
Datensicherung
konsistent zu
SCN x
Sekundäre Datenbank
INITIAL-LOAD
konsistent zu
SCN x
Instantiierung: SCN x+1
Replikation beginnt bei
SCN x+1
Zeit
t1 t2
t3
t4
t5 t6
Abb.7: INITIAL-LOAD und Instantiierung
INITIAL-LOAD findet immer nur in der sekundären Datenbank statt. Entschließt man sich, auch in die entgegengesetzte Richtung zu replizieren, also von der sekundären zur
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 Sonderfä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.
GoldenGate Software Command Interface (GGSCI) 1.
GoldenGate
InstallationsVerzeichnis
auswählen
2.
Rechter Mausklick
3.
Öffnen mit Mausklick
Abb.8: Öffnen eines Command-Prompt-Fensters unter Windows 7
Abb.9: Aufruf des GoldenGate Command Interpreter
29
30 GoldenGate Software Command Interface (GGSCI)
Abb.10: GoldenGate Command Interpreter – Beginnmeldungen
2.8.1GoldenGate-Kommandos
Es existieren Kommandogruppen für die einzelnen GoldenGateProzesse und für spezifische GoldenGate-Funktionalitäten.
Gruppe
Kommandos
Manager Commands
INFO, SEND, START,STATUS, STOP
(Manager Process)
(Extract Process)
ADD, ALTER, CLEANUP, DELETE, INFO, KILL, LAG,
SEND, START, STATS, STATUS, STOP
Replicat Commands
(siehe Extract Commands)
Extract Commands
(Replicat Process)
ER Commands
(Multiple E/R Processes)
INFO, KILL, LAG, SEND, START, STATS, STATUS, STOP
GoldenGate Software Command Interface (GGSCI) Gruppe
Kommandos
Trail Commands
ADD, ALTER, DELETE, INFO
(EXTTRAIL/RMTTRAIL)
Database Commands
DBLOGIN, ENCRYPT PASSWORD, LIST TABLES
Trandata Commands
ADD, DELETE, INFO
(Logging)
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
2.8.2Kommando OBEY
Zur Erleichterung der Arbeit besteht die Möglichkeit, Kommandos in einem Flat File abzulegen. Mit dem Kommando
OBEY wird dieses File dann aufgerufen und die Kommandos werden der Reihe nach abgearbeitet. Diese KommandoFiles haben unter Windows die Filenamen-Erweiterung
„OBY“. Diese Funktionalität wird im Beispiel genutzt, um
Kommandos für das Aufsetzen und Löschen der Replikationsumgebung auszuführen. Pro Datenbank gibt es dabei
einen Setup- und einen Cleanup-Skript mit GoldenGateKommandos (siehe Teil 2, Punkt 8.4)
31
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 Datenbank (Ziel) übertragen und dort ebenfalls ausgeführt. Damit
hält man beide Datenbanken synchron und verfügt in beiden
Datenbanken über aktuelle Datenbankobjekte. Das funktioniert aber nur, solange die Datenbankobjekte der Zieldatenbank 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 Spalteninhalt der Zieldatenbank überein (BEFORE-IMAGE falsch!)
DELETE ein Datensatz, der gelöscht werden soll, existiert
nicht mehr
Vermeidung von Konflikten
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 realisierbar, weil Änderungen von mindestens zwei Seiten gemacht
werden können. In solchen Fällen sollte durch technologische 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 Anwendungslogik implementiert werden, die im Falle von Widersprü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.
33
34 Standardkonfliktlösungen
3.3
In der Praxis zeigt sich immer wieder, dass bei jeder Replikation 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 „NonStop“ bereit und unterstützt die Datentypen NUMERIC,
DATE, TIMESTAMP, CHAR/NCHAR und VARCHAR/NVARCHAR, 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.
35
USEDELTA ist nur für Datentyp NUMERIC möglich. Um
Konflikte zu erkennen und zu behandeln, müssen Extractund Replicat-Prozess entsprechend konfiguriert werden.
Tabelle 8 zeigt die Parameter, die in der TABLE-Anweisung
(EXTRACT) beziehungsweise in der MAP-Anweisung (REPLICAT) anzugeben sind, um sowohl die Konflikterkennung als
auch die Konfliktlösung zu aktivieren:
EXTRACT
REPLICAT
Konflikterkennung
Konfliktlösung
--oder
GETBEFORECOLS
---
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.
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 GoldenGateProzesse 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.
37
Globalisierung
Thema
Gegenstand
Character Set
(CS)
Conversion
Database, Session/Client,
Operating System and
Terminal CS
Parameter, Trail and
Definition File
Erläuterung
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
New
Parameters
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
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:
N
LS_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:
N
LS_LANG environment variable does not match
database character set,
o r not set. Using database character set value
of WE8MSWIN1252.
Den Einträgen in Tabelle 9 entsprechend, werden beide Character 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 ReplicatProzess einen falschen Zeichensatz benutzen, wenn Betriebssystem- 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.
Übersicht
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 Datenbanknachrichten, die Tages- und Monatsnamen, die Sortierreihenfolge (LANGUAGE), die Datumsangabe, das Währungszeichen 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.WE8MSWIN1252")
Set environment variable (NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252)
...
5 Sicherheit
5.1
Übersicht
Im Rahmen dieses Dojo werden die Sicherheitsfunktionen
von GoldenGate nur überblicksweise behandelt. Schwerpunkt 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
39
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-AktivReplikation (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 GoldenGateSicherheitsfunktionen aufgeführt. An dieser Stelle möchte ich
darauf hinweisen, dass die in der Tabelle aufgeführte Sicherheitsfunktion „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
Sicherer als das Verstecken eines Passworts ist dessen Verschlüsselung. Oracle GoldenGate bietet dazu verschiedene
Möglichkeiten an. Der BLOWFISH-Algorithmus kann mit
einem selbst erzeugten oder einem Standardschlüssel (DEFAULT KEY) arbeiten. Die AES-Algorithmen benötigen immer
selbst erzeugte Schlüssel. Mit dem GGSCI-Kommando
41
Funktion
Was wird gesichert?
Wie wird gesichert?
Trail File Encryption
Verschlüsselung der Datensätze in
Local Trail oder Remote Trail Files
und bei der Übertragung über
Datenverbindungen
256-key Byte Substitution
Advanced Encryption Security:
AES-128, AES-192, AES-256
Password
Encryption
Verschlüsselung der Passwörter für
den Connect zur Datenbank,
Explizit verschlüsseln über GGSCI
AES-128, AES-192, AES-256
Blowfish
TCP/IP Encryption
Verschlüsselung des Datenverkehrs
über TCP/IP, Entschlüsselung durch
GG Instanz auf der Zielseite, wenn
kein Trail File Encryption aktiviert
AES-128, AES-192, AES-256
Blowfish
Command
Authentication
Überwachung aller über GGSCI
ausgeführten Kommandos
Konfiguration eines
„Command Security File” (CMDSEC)
Trusted Connection
Aktivierung der
Replikationsverbindung vom sicheren
Zielsystem (Trusted System)
Konfiguration eines
„Passive Alias Extract“ in der
GG Instanz auf dem Quellsystem
Hide Password
Benutzung von versteckten
Passwörtern
für den Connect zur Datenbank
Erstellung eines Connect-Makros im
Verzeichnis: ./dirmac
Tab.10: GoldenGate Security Features in 11gR2
ENCRYPT und dem Schlüssel generiert man ein kryptisches
Passwort, das dann beim DBLOGIN angegeben wird.
BLOWFISH: Passwort generieren mit Standardschlüssel (DEFAULT KEY):
D:\ogg_new_src>ggsci
Oracle GoldenGate Command Interpreter for Oracle
Version 11.2.1.0.1 OGGCORE_11.2.1.0.1_PLATFORMS_120423.0230
Windows x64 (optimized), Oracle 11g on Apr 23 2012 04:55:02
42 Passwort-Verschlüsselung
Copyright (C) 1995, 2012, Oracle and/or its affiliates. All
rights reserved.
GGSCI (JJT420) 1> encrypt password GGADMIN blowfish
No key specified, using default key...
Encrypted password:
Algorithm used:
AACAAAAAAAAAAAHADJHJYIDCMIYECBQG
BLOWFISH
BLOWFISH: DBLOGIN mittels verschlüsseltem Passwort:
GGSCI (JJT420) 2> dblogin userid ggadmin password AACAAAAAAAAAAAHADJHJYIDCMIYECBQG BLOWFISH encryptkey DEFAULT
Successfully logged into database.
GGSCI (JJT420) 3>
Für die Verwendung der AES-Algorithmen ist es notwendig,
Schlüssel mit dem Programm KEYGEN zu erzeugen und diese
unter eindeutigen Namen im File ENCKEYS zu speichern.
Das File ENCKEYS muss im GoldenGate-Installationsverzeichnis stehen.
AES-128: Schlüssel (KEY) mit Programm KEYGEN erstellen:
D:\ogg_new_src>keygen 128 1
0xAAF1D027E724633C5C4E8C76B4E77D78
AES-128: File ENCKEYS im GoldenGate-Installationsverzeichnis aufbauen:
# Key Name
Key Value
mykey1281
0xAAF1D027E724633C5C4E8C76B4E77D78
AES-128: DBLOGIN mittels verschlüsseltem Passwort:
GGSCI (JJT420) 4> encrypt password GGADMIN AES128 encryptkey
mykey1281
Encrypted password:
AADAAAAAAAAAAAHAGHXABGQGGBQCDHCDUJDAWC-
JAOADDAIFHTDRCWBOHWATEEJIFDIXGIEQBTEUBMANH
Algorithm used:
AES128
GGSCI (JJT420) 5> dblogin userid ggadmin password AADAAAAAAAAAAAHAGHXABGQGGBQCDHCDUJDAWCJAOADDAIFHTDRCWBOHWATEEJIFDIXGIEQBTEUBMANH aes128 encryptkey mykey1281
GGSCI (JJT420) 6>
43
44 GGSCI-Kommandos und -Reports
6 Administration und Überwachung
6.1
GGSCI-Kommandos und -Reports
Oracle GoldenGate bietet zahlreiche Möglichkeiten zur
Überwachung einer Replikationsumgebung. Die Tabelle 11
liefert eine Übersicht dazu:
Kommando
für Prozess
Ausgabe von
INFO
ALL
MANAGER
EXTRACT
REPLICAT
EXTTRAIL
RMTTRAIL
Statusinformationen zu den
GoldenGate-Prozessen:
Checkpoint-, Lag-, Port-,
Environment-Infos
Local-Trail- und Remote-Trail-FileInformationen:
Data Position, File Size
LAG
EXTRACT
REPLICAT
Zeitdifferenz zwischen letztem
verarbeiteten Satz und
der aktuellen Zeit in der Datenbank
STATUS
MANAGER
EXTRACT
REPLICAT
Statusangabe:
Starting, Running, Stopped, Abended
STATS
EXTRACT
REPLICAT
Statistikinformationen zum aktuellen
Verarbeitungsstand
SEND
MANAGER
EXTRACT
REPLICAT
Zusammenstellung von ProzessInformationen und Erstellung eines
vollständigen oder eines CDR Reports
VIEW REPORT
EXTRACT
REPLICAT
Anzeige eines durch SEND erzeugten
Reports
VIEW GGSEVT
---
Anzeige des Inhaltes des GoldenGate
Error Log
Tab.11: GGSCI-Kommandos
Oracle Management Pack for Oracle GoldenGate
Neben den Status- und Statistikinformationen können über
Kommandos auch umfassende Reports erzeugt werden.
Reports entstehen entweder auf Anforderung oder automatisch nach Beendigung der GoldenGate-Prozesse:
1.Erzeugen über Kommando SEND und anschauen über
VIEW REPORT
2.Report File nach Stoppen des Prozesses im Unterver
zeichnis „dirrpt“ anschauen
Name: „prozess_name.rpt“ → zum Beispiel EX2PRIO.
rpt → letzter erzeugter ReportPro Prozess sind weitere
10 Reports verfügbar → zum Beispiel EX2PRIO0.rpt ...
EX2PRIO9.rpt (ältester!)
6.2
Or acle Management Pack for Or acle
GoldenGate
Die Bezeichnung lässt auf ein zusätzliches Softwarepaket für
den Oracle Enterprise Manager schließen. Das ist nicht falsch
aber auch nicht ganz richtig. Für die Erklärung muss man
in die Vergangenheit blicken. Als Oracle die Firma GoldenGate 2009 kaufte, gab es für die Administration von Oracle
GoldenGate ein grafisches Tool mit dem Namen GoldenGate
Director. Diese Komponente und ihr Name passten ganz und
gar nicht in die Oracle-Produktstrategie, weil bei Oracle das
45
46 Oracle Management Pack for Oracle GoldenGate
gesamte Systemmanagement mit dem Enterprise Manager und
seinen Management Packs durchgeführt wird. Deshalb wurde
sofort das Oracle Management Pack for Oracle GoldenGate
kreiert und der GoldenGate Director unter diesem Produktnamen eingeordnet. Damit wurde der GoldenGate Director dem
Kunden als Management Pack für GoldenGate verkauft, obwohl
beide Komponenten nichts miteinander zu tun hatten. In der
Zwischenzeit hat Oracle hier entscheidend nachgebessert und
zwei völlig neue Produkte entwickelt:
1.Oracle GoldenGate Plug-in für den Oracle Enterprise Manager
12c Cloud Control
2.Oracle GoldenGate Monitor
Damit ist man nun endlich in der Lage, GoldenGate über den
Oracle Enterprise Manager (OEM) zu administrieren und zu überwachen. Mit dem GoldenGate Monitor wird zusätzlich noch ein
eigenständiges Monitoring Tool angeboten, das für alle Kunden
interessant sein könnte, die den OEM nicht einsetzen. Beide Produkte nutzen innerhalb der GoldenGate-Instanz den gleichen Java
Agent Client zur Kommunikation mit dem jeweiligen Server, dem
OEM Plug-in oder dem Monitor-Server. Zukünftige Weiterentwicklungen werden nur noch für diese beiden „java-agent-basierenden“ Produkte stattfinden. Damit ist die strategische Richtung
vorgegeben und der GoldenGate Director ein Auslaufprodukt. Auf
jedem System, auf dem GoldenGate-Instanzen überwacht werden
sollen, muss ein Java Runtime Environment (JRE) 1.6 oder höher
installiert sein. Dabei ist zu beachten, dass eine system
konforme Version installiert ist, das heißt auf einem 64-BitSystem auch eine 64-Bit-JRE beziehungsweise auf einem
32-Bit-Sytem eine 32-Bit-JRE.
6.2.1Or acle Enterprise Manager Plug-in
Das Plug-in für den Oracle Enterprise Manager gibt es erstmals ab OEM Cloud Control 12c Bundle Patch 1 (12.1.1.1.0).
Unterstützt wird GoldenGate ab Version 11.2.1.0.1. Als Verbindung von GoldenGate zum Enterprise Manager fungiert
ein Java Agent Client, der als zusätzlicher GoldenGate-Prozess läuft und über den Parameter ENABLEMONITORING
in der Parameterdatei GLOBALS aktiviert werden muss.
Wenn eine GoldenGate-Instanz das OEM Plug-in verwenden
will, muss in der Datei „config_properties“ im Verzeichnis
„cfg“ der Parameter AGENT_TYPE.ENABLED auf OEM
gesetzt werden (siehe Punkt 8, Tabelle 14). Das Plug-in
unterstützt das Monitoring auf allen Plattformen außer HP
NonStop, IBM iSeries und IBM z/OS. Zum Enterprise Manager 12c Cloud Control existiert das Dojo Nr. 3. Im Punkt 4
„Aktuell bleiben mit Self Update“ sind die Schritte beschrieben, wie man ein zusätzliches Plug-in verfügbar macht
(deployed). In diesem Dojo wird deshalb die Verfügbarkeit
des GoldenGate Plug-in vorausgesetzt.
47
Abb.11.1: OEM Oracle GoldenGate-Homepage – keine Targets vorhanden
Abb.11.2: Abb. 11.2: OEM Oracle GoldenGate-Homepage – Target-Auswahl
Abb.11.3: OEM Plug-in – Self Update – Version des GoldenGate Plug-in
In der Abbildung 11.1 sieht man die GoldenGate-Homepage
ohne registrierte Java Agents (Status AGENT UNREACHABLE).
Über „Targets“ → „GoldenGate“ kann man GoldenGate-Instanzen suchen (Abbildung 11.2). Die Java Agents der Instanzen werden dann unter OEM Cloud Control registriert.
In Abbildung 11.3 sehen wir eine Übersicht der verfügbaren
OEM Plug-ins. Darunter befindet sich auch das GoldenGate
Plug-in in der ersten verfügbaren Version. Über „Self Update“ kann man auf eine aktuellere Version (wenn verfügbar)
wechseln.
6.2.2Or acle GoldenGate Monitor
Das Datenblatt zum Management Pack for Oracle Golden
Gate bezeichnet den Einsatz des Monitors als „Next Generation Monitoring“. Der Monitor ist eine Client/ServerJava-Lösung und nutzt einen Apache Tomcat Web Server der
automatisch mitinstalliert wird. Gegenwärtig unterstützt
der Monitor-Server bis zu zwanzig GoldenGate-Instanzen.
Jede dieser Instanzen kann dabei bis zu fünfzig Prozesse
haben. Für die Nutzung des GoldenGate Monitors gelten die
gleichen Voraussetzungen wie bei Nutzung des OEM Plugin. Über die Parameterdatei GLOBALS muss der Java Agent
Client wie unter 6.2.1 beschrieben, aktiviert werden. Der Para
meter AGENT_TYPE.ENABLED muss aber für die Verbindung
zum Monitor Server auf OGGMON gesetzt werden.
49
Oracle GoldenGate Instance
Monitor
Agend
Manager
External
Monitoring
Service
SNMP
Data
base
Trial
JMX
Command
Line
Integration
E-Mail
Extract/
Replicat
SMPT
Monitor
Server
JMX
Repository
JMX
Monitor
Agend
Manager
Extract/
Replicat
Data
base
Trial
HTTP/
HTTPS
Web
Browser
UI
Monitor
Agend
Manager
Abb.12: Oracle GoldenGate Monitor-Architektur
Auf die Installation des GoldenGate Monitors gehe ich im
Dojo nicht ein. Schauen Sie dazu bitte im Monitor Admin
Guide nach (siehe Punkt 9).
Extract/
Replicat
Data
base
Trial
Konfigurationspunkt
Eingabewert
Bemerkung
Repository Database
Typ: Oracle, SID: ORAP
Speichern von MonitorDaten
Database Connect Info
Localhost:1521:orap
Für Monitor Server
Connect
Repository User ID
ggmon/GGMON
User / PW für Monitor
Server
Windows 7 Service Name
Oracle GoldenGate
Monitor
Im Task Manager:
GGMonitor
GG Monitor Admin User
ID
master/MASTER
User / PW für Tomcat
HTTP Port für Tomcat
5510
Standard: 5500 (DB
Control!)
HTTPS Port für Tomcat
nicht benutzt
Standard: 5505
Shutdown Port
5511
Standard: 5501
JMX Host Name
Localhost
Für den Test ausreichend
JMX Server Port
5512
Standard: 5502
JMX User ID
jmxuser/JMXUSER
User / PW für JMX-Server
SNMP / E-Mail / CLI
Disabled
Für den Test nicht genutzt
Tab.12: Der GoldenGate Monitor-Konfigurationsparameter zeigt
die Konfiguration des hier genutzten GoldenGate Monitors.
51
GG Komponenten Liste
Anzeige einstellen
Aktiv-Aktiv Topologie
Alle GG Prozesse
gestoppt! Abb.13: Data and Alerts View – Aktiv-Aktiv-Replikation – Prozesse im Status STOPPED
Alle GG Prozesse
gestartet! Abb.14: Data and Alerts View – Aktiv-Aktiv-Replikation – Prozesse im Status RUNNING
GoldenGate Monitor – Data and Alerts View
Die Topologie kann auf drei verschiedene Arten angezeigt
werden. Dazu dienen die drei rechten Symbole in der
blau unterlegten Symbolzeile im oberen Teil. Es kann ein
Ausschnitt des gesamten Bildschirmes angezeigt werden,
der dann eine bessere Sichtbarkeit ermöglicht. Im rechten
unteren Fenster werden zur ausgewählten Komponente
Detailinformationen angezeigt (siehe Abbildung 14).
6.2.3Or acle GoldenGate Director
Der GoldenGate Director ist das älteste grafische Administrations- und Monitoring-Tool für eine Oracle GoldenGateReplikationsumgebung. Man muss einen WebLogic Server,
den Director Server und den Director Client installieren, um
mit dem GoldenGate Director arbeiten zu können.
Der Director Client besteht aus drei Komponenten: dem
Client Administrator, dem eigentlichen Client und dem
Director Web, einem Browser-Interface, das automatisch
mitinstalliert wird. Über den Client Administrator wird festgelegt, welche Datenbanken und GoldenGate-Prozesse für
die Clients sichtbar sind. Ein Client sieht also nur das, was
durch den Administrator bereitgestellt wurde. Im Dojo zeige
ich zwei Bildschirminhalte des Director Client, die einen
Eindruck verschaffen, wie die Topologie und die einzelnen
53
Oracle WebLogic Server
Oracle GoldenGate
Director Server domain
Oracle GoldenGate
Director Web
GGSCI
Oracle GoldenGate
Director Server
Application
Oracle GoldenGate
Director Client
Oracle GoldenGate
Director
Administrator
GGSCI
Monitor
Agent
GGSCI
Oracle GoldenGate Director Database
Abb.15: Oracle GoldenGate Monitor-Architektur
Prozesse dargestellt werden. Eine Weiterentwicklung wird
es beim Director nicht geben. Strategische Produkte sind,
wie schon erwähnt, das Plug-in für OEM Cloud Control und
der GoldenGate Monitor. Gegenwärtig ist aber ein Verzicht
auf den Einsatz des GoldenGate Directors nicht in allen
Fällen möglich. Wie Tabelle 13 zeigt, unterstützen die beiden
neuentwickelten Produkte nur die aktuellsten GoldenGateVersionen. Ein weiterer Punkt sind die Funktionen, die zur
zeit nur vom Director unterstützt werden:
1.Editieren, Aktivieren und Deaktivieren von
GoldenGate-Parametern
2.GGSCI-Fenster zum Ausführen von
GoldenGate-Kommandos
3.Starten und Stoppen der GoldenGate-Prozesse
Augenblicklich ist nur der GoldenGate Director als Administrations- beziehungsweise Konfigurationstool einsetzbar.
Monitor und OEM Plug-in sind bis jetzt nur zum Anzeigen
von Informationen in der Lage.
Alle GG Prozesse
gestartet! Aktiv-Aktiv Topologie
Remote-File Details
Abb.16: Topologie der Aktiv-Aktiv-Replikation – Prozesse gestartet
55
Extract/Replicat
Prozesse gestoppt!
RE2SECO Details
Abb.17: Topologie der Aktiv-Aktiv-Replikation – Extract- und Replicat-Prozesse gestoppt (x)
Abb.18: Topologie der Aktiv-Aktiv-Replikation – Ausschnitt oberes Fenster – Topologie
Prozesse können über Mausklick markiert werden. Markierte Prozesse werden über Klick auf das Start- oder Stoppsymbol gestartet beziehungsweise gestoppt. Das passiert durch
Ausführen des entsprechenden Kommandos in der GGSCIUmgebung. Wie bei einem Mediaplayer ist das Startsymbol
das kleine Dreieck und das Stoppsymbol das kleine Viereck
in der Symbolzeile oben.
Sie sehen hier alle GoldenGate-Komponenten der AktivAktiv-Replikation. Die beiden Manager der Instanzen laufen
noch, sonst wären auch die beiden gelben „Data Source“Symbole mit einem roten Kreuz gekennzeichnet. Jede
Komponente kann man mit Mausklick auswählen. Es werden dann alle verfügbaren Informationen dazu im unteren
Fenster des Bildschirms angezeigt (siehe RE2SECO-Details
in Abbildung 17). Die Anordnung der Komponentensymbole
ist frei wählbar und kann jederzeit verändert werden.
6.2.4Gegenüberstellung
Die Funktionsübersicht in Tabelle 13 basiert auf der ersten
Version des GoldenGate Monitors und des OEM Plug-in.
Die fehlenden Funktionalitäten des GoldenGate Directors
sollen so schnell wie möglich in die beiden neuen Tools
übernommen werden. Damit entfällt die Notwendigkeit
der Nutzung des Directors und der Name „Oracle Mana
57
Merkmal
OEM Plug-in
OGG Monitor
OGG Director
Unterstützt GoldenGate V10.4
Nein
Nein
Ja
Unterstützt GoldenGate V11.x
Nein
Nein
Ja
Unterstützt GoldenGate V11.1.1.1.1
Nein
Ja
Ja
Unterstützt GoldenGate V11.2.1.0.1
Ja
Ja
Ja
Parameter Files konfigurieren
Nein
Nein
Ja
Automatische Parameterwahl
Nein
Nein
Ja
Prozesse starten und stoppen
Nein
Nein
Ja
GGSCI-Kommandoumgebung
Nein
Nein
Ja
User Management
Nein
Ja
Ja
View Management
Nein
Ja
Ja
GoldenGate Topologie anzeigen
Ja
Ja
Ja
GoldenGate-Prozesse anzeigen
Ja
Ja
ja
Verzögerungszeit (Lag Time)
anzeigen
Ja
Ja
Ja
Historische Daten anzeigen
Ja
Ja
Ja
ALERT Anzeige
Nein
Ja
Ja
ALERT Definition
Nein
Ja
Ja
ALERT History
Nein
Ja
Ja
SNMP Support
Nein
Ja
Ja
CLI ALERTS
(CLI – Command Line Integration)
Nein
Ja
Ja
E-mail ALERTS
Nein
Ja
Ja
Tab.13: F
unktioneller Vergleich der Produkte des Oracle Management
Pack für Oracle GoldenGate
Oracle GoldenGate Veridata
gement Pack für Oracle GoldenGate“ erlangt vollständige
Berechtigung.
6.3
Or acle GoldenGate Veridata
Oracle Veridata ist ein Tool zum Vergleich zweier Datenbanken während der GoldenGate-Replikation. Das Tool existierte
in seiner jetzigen Form schon bei der Übernahme der Firma
GoldenGate im Jahr 2009. Es ist in der Lage, Unterschiede
zwischen den Datenbankobjekten auf der Quell- und der
Zieldatenbank zu ermitteln und übersichtlich anzuzeigen.
Veridata kann parallel zur Replikation laufen und toleriert
bei der Feststellung von Abweichungen Replikationsverzögerungen. Es ist ein eigenständiges Produkt und muss bei
Nutzung zusätzlich lizenziert werden. Für die hier gezeigte
Aktiv-Aktiv-Replikation ist dieses Tool völlig überflüssig, weil
keinerlei Datenbestände repliziert werden, die auf eventuelle
Inkonsistenzen untersucht werden könnten. Ich beschränke
mich im Dojo deshalb auf eine Architekturübersicht zu
diesem Produkt.
Seit 2009 hat sich an Veridata nichts verändert. Bis auf die
Anpassung der Systemdokumentation an den Oracle-Standard entspricht die Komponente dem Stand bei der Übernahme von GoldenGate durch Oracle. Der Administrator’s
Guide (siehe Link in Punkt 9) weist die Version 3 aus,
59
60 Oracle GoldenGate Veridata
entspricht aber noch der GoldenGate Version 10.4.
GoldenGate
Verdidata
Web
GoldenGate
Verdidata
CLI
GoldenGate
Verdidata
Server
Programm:
VERICOM
Repository
GoldenGate
Verdidata
Agent
Source
Database
GoldenGate
Verdidata
Agent
Target
Database
2 Versionen:
C-Client
Java-Client
Abb.19: Oracle GoldenGate Veridata-Architektur
Oracle GoldenGate Veridata
Teil II
GoldenGate 11gR2
Replikationsbeispiel
61
62 Oracle GoldenGate Veridata
Teil II
GoldenGate 11gR2
Replikationsbeispiel
Im zweiten Teil des Dojo sollen Sie selbst eine Replikation
aufbauen. Dazu müssen Sie die beschriebenen Aktionen
ausführen. Aktionen und Hinweise sind durch diese
Symbole gekennzeichnet:
Aktion
Hinweis
Wenn möglich, verweise ich bei den Aktionen auf die
entsprechenden Punkte des ersten Teils des Dojo.
SQL-Skripte, Parameter Files, OBEY Files sollten Sie mit
Cut & Paste in eigene Dateien kopieren, anpassen und dann
ausführen.
SQL-Skripte führen Sie bitte unter SQLPlus aus. OBEY
Files und OBEY-Kommandos müssen in der GoldenGateKommandoumgebung (GGSCI) ausgeführt werden.
goldengate-installation
7 GoldenGate-Installation
Wie in Punkt 2.4 beschrieben, müssen Sie zuerst Golden
Gate installieren. Dabei ist zu beachten, dass Sie das für Ihre
Plattform passende „Software Build“ auswählen. Da meine
beiden GoldenGate-Verzeichnisse schon existieren, zeige
ich die Installation in einem neuen Verzeichnis. Im Beispiel
benötigen wir GoldenGate 11.2.1.0.1 für Windows 64-Bit für
Oracle 11gR2:
Download
GoldenGate für Oracle 11gR2 auf Windows 7,
Entpacken und Aufbau des Installationsverzeichnisses
Abb.20: GoldenGate – Software-Download
63
64 goldengate-installation
ür den Download von edelivery.oracle.com benötigen
F
Sie einen Login Oracle Account.
An dieser Stelle entpacken Sie das Zip File in einen Ordner
Ihrer Wahl (hier: „GG_Download“) und erzeugen dort die benötigte GoldenGate-Verzeichnisstruktur. Danach müssen Sie
noch zusätzlich den Ordner „dirmac“ für den später benötigten Makro DBCONNECT.MAC anlegen.
Abb.21: GoldenGate – Entpacken der Software
goldengate-installation
Nach dem Entpacken öffnen Sie bitte ein CommandPrompt-Fenster im Ordner „GG_Download“ und rufen den
GoldenGate CommandInterpreter auf (siehe Punkt 2.8).
Dort führen Sie dann den Befehl CREATE SUBDIRS aus:
Abb.22: GoldenGate – Erstellen der Unterverzeichnisse
Jetzt noch das Verzeichnis „dirmac“ erstellen und die
Installation ist beendet.
65
66 Aufbau einer aktiv-aktiv-replikation
8 Aufbau einer Aktiv-AktivReplikation
Tabelle 14 beinhaltet alle im Beispiel der Aktiv-AktivReplikation genutzten GoldenGate-Funktionen.
Bereich
Thema
Beschreibung
A
Databases (EE, 11.2.0.3)
Primary: ORAP | Secondary: ORAS (Same Laptop)
A
GoldenGate (11.2.1.0.1)
ORAP → d:/ogg_new_src | ORAS → d:/ogg_new_tar
A
DB Supplemental Logging
YES | IMPLICIT
A
Replication Object
Table: GG_HEARTBEAT_TABLE
A
Replication Object Logging
Primary Key
A
Replication
Bidirectional aka Multimaster
A
Local Trail or Remote Trail
Remote Trail
A
Checkpoint Table
Specific Table in ORAP | Specific Table in ORAS
P
Replication Processes
Primary Extract (Capture) | Replicat (Apply, Delivery)
P
Extract (Capture)
Classic Capture
P
Collector
Dynamic Collector
P
Replicat (Apply)
1:1 Mapping | Conflict Detection and Resolution (CDR)
P
Java Agent Client
./GLOBALS → ENABLEMONITORING (11gR2)
CI
GGS Command Interface
Commands | OBEY Files
CI
OBEY Files
Setup/Cleanup Scripts for primary and secondary DB
CI
Reporting
SEND p_name, REPORT | STATS p-name, REPORTCDS
Überblick und Voraussetzungen
Bereich
67
Thema
Beschreibung
CDR
TABLE Statement (Extract)
GETBEFORECOLS (ON UPDATE ALL)
CDR
MAP Statement (Replicat)
COMPARECOLS (ON UPDATE ALL) | RESOLVECONFLICT
CDR
RESOLVECONFLICT
UPDATECOLEXISTS
CDR
UPDATECOLEXISTS
USEMAX | default: OVERWRITE | Default: IGNORE
G
Implicit NLS_LANG Setup
If omitted than database or operating system value will be
assumed. (siehe Tabelle 9)
S
Hide Password
USERID / PW information exists only in a connect macro.
Use NOLIST / LIST to suppress parameter info in reports.
(siehe Tabelle 10)
M
Management Pack for OGG
Oracle Enterprise Manager Plug-in | GoldenGate Monitor
Java Agent Client Process must be started! (see above)
M
OEM Plug-in
./cfg/config_properties → agent_type.enabled=OEM
M
GoldenGate Monitor
./cfg/config_properties → agent_type.enabled=OGGMON
Tab.14: A
ktiv-Aktiv-Replikationsbeispiel im Überblick
A – Architecture P – Processes CI – GoldenGate Software Command Interface
CDR – Conflict Detection and Resolution G – Globalization S – Security M – Monitoring
8.1
Überblick und Vor aussetzungen
Werfen wir zuerst einen Blick auf die Topologie der AktivAktiv-Replikation. Die hier abgebildete Replikationsum
gebung soll bis zur vollständigen Lauffähigkeit konfiguriert
werden. Beteiligt sind zwei Datenbanken, die primäre
Datenbank ORAP und die sekundäre Datenbank ORAS.
Da beide Datenbanken sowohl Quelle als auch Ziel sind,
sollte man im Sinne der Übersichtlichkeit von primärer und
68 Überblick und Voraussetzungen
sekundärer Datenbank sprechen. Beide Datenbanken sind
Oracle Enterprise Editions der Basisversion 11.2.0.3, die auf
demselben Rechner laufen. Sie könnten aber auch Datenbanken der Version 11gR1 benutzen. Oracle GoldenGate
muss zwingend Version 11.2.1.0.1 oder höher sein.
Capture
Änderung der Tabelle:
Delivery
LAN/WAN/Internet
Over TCP/IP
Manager
ORAP
Delivery
Trial
File
GG_HEARTBEAT_TABLE
Manager
ORAS
Trial
File
Capture
GG_HEARTBEAT_TABLE
Tab.23: Topologie der Aktiv-Aktiv-Replikation
Beginnen wir jetzt mit dem Konfigurieren der Aktiv-AktivReplikation:
Festlegen
der Namen und Verzeichnisse der eigenen
Umgebung
Merkmal
Umgebung im Dojo
GLOBAL_NAME
Primäre Datenbank
orap.de.oracle.com
oras.de.oracle.com
TNSNAMES Alias
Primäre Datenbank
orap
oras
Eigene Umgebung
Voraussetzungen in primärer und sekundärer Datenbank
Merkmal
Umgebung im Dojo
GoldenGateInstallationsverzeichnis
Primäre Instanz
Sekundäre Instanz
d:\ogg_new_src
d:\ogg_new_tar
GoldenGate Trail Files
Primäre Instanz
Sekundäre Instanz
d:\ogg_new_tar\dirdat\tstact
d:\ogg_new_src\dirdat\tstact
GoldenGate Admin User ID
ggadmin
Name Replikationsobjekt
(Tabelle)
gg_heartbeat_table
Schema des
Replikationsobjektes
tstact
Name der Änderungsprozedur
Primäre Datenbank
gg_heartbeat_proc_p
gg_heartbeat_proc_s
Name des zyklischen
Datenbank-Jobs
Primäre Datenbank
gg_heartbeat_job_p
gg_heartbeat_job_s
Eigene Umgebung
Tab.15: Angaben zur Replikationsumgebung
8.2
Vor aussetzungen in primärer und
sekundärer Datenbank
8.2.1ARCHIVELOG Mode
ARCHIVELOG
Mode kontrollieren beziehungsweise
einstellen
69
70 Voraussetzungen in primärer und sekundärer Datenbank
Grundlage der Oracle-Replikation sind die Redolog-Infor
mationen, die bei allen Änderungen innerhalb der Daten
bank in Online Redolog Files geschrieben werden. Ist ein
Redolog File gefüllt, wird automatisch auf das nächste File
umgeschaltet. Da es nur eine begrenzte Anzahl Redolog Files gibt, werden diese im „Wrap-Around"-Verfahren
wiederverwendet. Im NOARCHIVELOG-Modus passiert das
unabhängig davon, ob der Inhalt des Online Redolog Files
zwischenzeitlich gesichert wurde oder nicht. Um Datenbankänderungen für Recovery-Situationen oder für Replikationszwecke zu archivieren, gibt es den ARCHIVELOG-Modus.
Dieser Modus prüft vor Wiederverwendung eines Online Redolog Files, ob dieses gesichert (archiviert) wurde. Wenn ja,
dann wird das File wiederverwendet, wenn nein, dann wartet
die Datenbank, bis die notwendige Sicherung durchgeführt
wurde. Im ARCHIVELOG-Modus sichert ein Oracle-Hintergrundprozess (zum Beispiel ARC0) den Inhalt sofort, wenn
das Online Redolog File gefüllt ist, und es kommt nicht zum
Stillstand der Datenbank.
SQLPlus → c onnect / as sysdba
archive log list
Voraussetzungen in primärer und sekundärer Datenbank Die ersten beiden Zeilen (rot) müssen so aussehen:
SQL> archive log list
Datenbank-Log-Modus
Archive-Modus
Automatische Archivierung
Aktiviert
Archivierungsziel
D
:\Oracle\archivelogs\
orap
Älteste Online-Log-Sequenz
175
Nächste zu archivierende Log-Sequenz
177
Aktuelle Log-Sequenz
177
SQL>
Ist das nicht der Fall, muss in der Datenbank der ARCHIVELOG-Modus aktiviert werden:
SQLPlus → s hutdown immediate
startup mount
alter database archivelog;
alter database open;
Kontrollieren Sie danach mit dem obigen Kommando, ob
die Änderung erfolgreich war.
Diese Kommandos bitte für beide Datenbanken ORAP und
ORAS ausführen!
71
8.2.2Supplemental Logging
Jede Änderung in der Datenbank wird durch einen Eintrag
in die Redolog-Dateien dokumentiert. Diese Redolog-Infor
mationen bilden die Grundlage für die Replikation der
Änderung zu einer anderen Datenbank. Der Datenbankadministrator kann den Umfang der Redolog-Informationen
festlegen. Dabei sollte immer der Grundsatz gelten: „So viel
wie nötig, aber so wenig wie möglich“. Je größer der Umfang
der Logging-Informationen, desto höher ist der Aufwand
für die Datenbankinstanz, das heißt, die Leistungsfähigkeit
der Datenbank nimmt ab und die Größe der RedologDateien nimmt zu.
Datenbank-Logging
kontrollieren beziehungsweise einstellen
SQLPlus → select supplemental_log_dat_min from v$database;
Das Ergebnis sollte YES oder IMPLICIT sein. Wenn nicht,
dann Logging-Level setzen.
SQLPlus → alter database add supplemental log data;
alter system switch logfile;
Diese Kommandos bitte für beide Datenbanken ORAP und
ORAS ausführen!
Voraussetzungen in primärer und sekundärer Datenbank Für das Replikationsobjekt wird entweder der PRIMARY
KEY oder ein UNIQUE KEY geloggt. Besitzt eine Tabelle
beides nicht, sollte man eines von beiden definieren. Ist das
nicht möglich, kann man selbst Spalten festlegen oder alle
möglichen Spalten ins Logging einbeziehen. Die Tabelle im
Beispiel besitzt einen PRIMARY KEY, für den später über das
GGSCI-Kommando TRANDATA das Logging aktiviert wird
(siehe Punkt 8.5). Ein ALTER TABLE-Kommando mit ADD
SUPPLEMENTAL LOG DATA sollte nicht explizit ausgeführt
werden.
8.2.3Das Replik ationsobjekt
In beiden Datenbanken existiert die Tabelle TSTACT.GG_
HEARTBEAT_TABLE mit einer Zeile pro Datenbank. In der
Spalte DB_NAME steht der GLOBAL_NAME der Datenbank, und die Spalte CURRENT_TIME wird ständig mittels
SYSDATE-Funktion mit dem Datum und der Tageszeit
gefüllt. Diese Zeitänderungen in den Tabellen sollen jeweils
zur anderen Datenbank repliziert werden.
Tabelle: TSTACT.GG_HEARTBEAT_TABLE
Spaltenname
Datentyp
DB_NAME
VARCHAR2(30)
CURRENT_TIME
DATE
Bemerkung
Primary Key
73
Inhalt der Tabelle TSTACT.GG_HEARTBEAT_TABLE
(Datenbank: ORAP)
DB_Name
CURRENT_TIME
ORAP.DE.ORACLE.COM
08.06.2012,10.45.00
→ Zeitaktualisierung pro Minute in ORAP
ORAS.DE.ORACLE.COM
08.06.2012,08.16.00
→ Zeitaktualisierung durch Replikation
Inhalt der Tabelle TSTACT.GG_HEARTBEAT_TABLE
(Datenbank: ORAS)
DB_NAME
CURRENT_TIME
ORAP.DE.ORACLE.COM
08.06.2012,08.15.00
→ Zeitaktualisierung durch Replikation
ORAS.DE.ORACLE.COM
08.06.2012,10.45.00
→ Zeitaktualisierung pro Minute in ORAS
Wenn keine Replikation läuft, wird in jeder Datenbank nur die CURRENT_TIME aktualisiert, wenn der
DB_NAME dem GLOBAL_NAME der Datenbank entspricht. Da die Aktualisierung zu jeder vollen Minute
erfolgt, ist der Sekundenwert „00“.
er Inhalt von CURRENT_TIME der jeweils anderen
D
Datenbank wird durch die Replikation aktualisiert.
Nur wenn die Replikation in beide Richtungen aktiv
ist, beinhaltet CURRENT_TIME jeder Zeile immer die
aktuelle Zeit unabhängig vom Inhalt von DB_NAME.
Voraussetzungen in primärer und sekundärer Datenbank Läuft
keine Replikation, hat immer nur eine Zeile
jeder Tabelle eine aktuelle CURRENT_TIME. Dieser
Zustand ist oben dargestellt.
Im Beispiel gibt es mit der Tabelle TSTACT.GG_HEARTBEAT_TABLE nur ein Replikationsobjekt. In dieser Tabelle
erfolgen zyklische Änderungen, die repliziert werden sollen.
Dazu werden in beiden Datenbanken eine Änderungsprozedur und ein zyklisch-laufender Job definiert. Der Job
ruft jede Minute die Prozedur auf und diese trägt die
aktuelle Zeit (SYSDATE) in die Spalte CURRENT_TIME der
Zeile ein, deren Inhalt der Spalte DB_NAME gleich dem
GLOBAL_NAME der Datenbank ist. Das Replikationsobjekt, die Tabelle GG_HEARTBEAT_TABLE, heißt in beiden
Datenbanken gleich. Das ist nicht zwingend, verbessert
aber die Übersichtlichkeit. Anders ist das bei der Prozedur
und beim Datenbank-Job. Hier bin ich der Meinung, dass
unterschiedliche Namen besser sind, weil man sofort sieht,
in welcher Datenbank die Prozedur beziehungsweise der
Job läuft.
Anlegen
der Tabellen, Änderungsprozeduren und
Datenbank-Jobs
75
SQL-Skript zum Anlegen der Tabelle:
TSTACT.GG_HEARTBEAT_TABLE in beiden Datenbanken
/*
Create Table TSTACT.GG_HEARTBEAT_TABLE on both Databases
C reate Primary Key on Table TSTACT.GG_HEARTBEAT_TABLE on both
Databases
*/
connect tstact/TSTACT@orap
drop table gg_heartbeat_table;
create table gg_heartbeat_table (db_name varchar2(30), current_
time date);
alter table TSTACT.GG_HEARTBEAT_TABLE add constraint
pk_db_name primary key (db_name);
select constraint_name, constraint_type, table_name
from ALL_constraints
where owner = 'TSTACT';
insert into gg_heartbeat_table values ('ORAP.DE.ORACLE.COM',
sysdate);
insert into gg_heartbeat_table values ('ORAS.DE.ORACLE.COM',
sysdate);
commit;
select db_name, to_char(current_time,'dd.mm.yyyy,hh24:mi:ss')
"Current-Time" from gg_heartbeat_table;
connect tstact/TSTACT@oras
Voraussetzungen in primärer und sekundärer Datenbank drop table gg_heartbeat_table;
create table gg_heartbeat_table (db_name varchar2(30), current_
time date);
alter table TSTACT.GG_HEARTBEAT_TABLE add constraint
pk_db_name primary key (db_name);
select constraint_name, constraint_type, table_name
from ALL_constraints
where owner = 'TSTACT';
insert into gg_heartbeat_table values ('ORAP.DE.ORACLE.COM',
sysdate);
insert into gg_heartbeat_table values ('ORAS.DE.ORACLE.COM',
sysdate);
commit;
select db_name, to_char(current_time,'dd.mm.yyyy,hh24:mi:ss')
"Current-Time"
from gg_heartbeat_table;
Der PRIMARY KEY auf die Spalte DB_NAME zeigt an,
dass dieser Inhalt eindeutig ist. Durch gezieltes Logging (GGSCI-Kommando TRANDATA) ist diese Spalte
immer Teil der Redolog-Informationen und dient auf
der Zielseite dem Replicat-Prozess zum Auffinden des
entsprechenden Datensatzes in der Tabelle.
77
SQL-Skript zum Anlegen beider Änderungsprozeduren:
TSTACT.GG_HEARTBEAT_PROC_x
connect tstact/TSTACT@orap
create or replace procedure gg_heartbeat_proc_p
as
time_value date;
begin
select sysdate into time_value from dual;
update tstact.gg_heartbeat_table set current_time = time_value
where db_name = 'ORAP.DE.ORACLE.COM';
end gg_heartbeat_proc_p;
/
connect tstact/TSTACT@oras
create or replace procedure gg_heartbeat_proc_s
as
time_value date;
begin
select sysdate into time_value from dual;
u pdate tstact.gg_heartbeat_table set current_time =
time_value
where db_name = 'ORAS.DE.ORACLE.COM';
end gg_heartbeat_proc_s;
/
Voraussetzungen in primärer und sekundärer Datenbank SQL-Skript zum Anlegen beider Änderungsprozeduren:
TSTACT.GG_HEARTBEAT_PROC_x
connect system@orap as sysdba
begin
dbms_scheduler.create_job(
job_name
=> 'GG_HEARTBEAT_JOB_P',
job_type
=> 'STORED_PROCEDURE',
job_action
=> 'TSTACT.GG_HEARTBEAT_PROC_P',
start_date
=> SYSTIMESTAMP,
repeat_interval
=> 'freq=MINUTELY; BYSECOND=0;',
end_date
=> NULL,
enabled
=> TRUE,
comments
=> 'Keep GG Heartbeat Table current');
end;
/
connect system@oras as sysdba
begin
dbms_scheduler.create_job(
job_name
=> 'GG_HEARTBEAT_JOB_S',
job_type
=> 'STORED_PROCEDURE',
job_action
=> 'TSTACT.GG_HEARTBEAT_PROC_S',
start_date
=> SYSTIMESTAMP,
repeat_interval
=> 'freq=MINUTELY; BYSECOND=0;',
end_date
=> NULL,
enabled
=> TRUE,
comments
=> 'Keep GG Heartbeat Table current');
end;
/
79
Zu
beachten ist hierbei, dass dieser Job nicht unter
dem Replikations-User GGADMIN laufen darf, weil
dieser User von der Replikation ausgeschlossen ist
(siehe TRANLOGOPTIONS EXCLUDEUSER in den Parameterdateien der Extract-Prozesse, Punkt 8.3.3). Der
Ausschluss ist notwendig, weil sonst die replizierten
Änderungen erneut aus den Redolog-Informationen
extrahiert würden. Ein sogenanntes „Data Looping“
wird dadurch verhindert. In unserem Beispiel läuft der
Job unter User SYS.
8.2.4GoldenGate Admin-User
Die Replikation mit GoldenGate (oder einer anderen
Software) erfordert immer einen Administrator-User. Mit
diesem Administrator-User verbinden sich die Replikationsprozesse zur Datenbank. Der Extract-Prozess benötigt nur
für bestimmte Operationen eine Verbindung zur Datenbank, weil er prinzipiell den Inhalt der Redolog-Dateien für
die Replikation verwendet. Der Administrator-User ist ein
Datenbanknutzer mit zusätzlichen Privilegien. In der AktivAktiv-Replikation benutzen wir in jeder Datenbank einen
Administrator mit der User ID GGADMIN. Das folgende
SQL-Skript ist gültig für Oracle-Datenbankversionen ab
11.2.0.2.
Voraussetzungen in primärer und sekundärer Datenbank GoldenGate-Administrator-User
anlegen und Zuweisen der
notwendigen Replikationsprivilegien
SQL-Skript zum Anlegen des GoldenGate-Administrators:
GGADMIN in beiden Datenbanken
--- ggadmin_create_user.sql
-connect sys/OS2@orap as sysdba
--- Create user GGADMIN in Primary Database ORAP
-drop user GGADMIN cascade;
create user ggadmin identified by GGADMIN
temporary tablespace temp default tablespace users;
grant resource, connect, dba to GGADMIN;
--- This GRANT is only needed if you use DDL replication
-grant execute on utl_file to GGADMIN
--- Oracle 11.2.0.2 and later
-begin
dbms_goldengate_auth.grant_admin_privilege('GGADMIN');
end;
/
81
-- Execute the same statements for Database ORAS
connect sys/OS2@oras as sysdba
drop user GGADMIN cascade;
create user GGADMIN identified by GGADMIN
temporary tablespace temp default tablespace users;
grant resource, connect, dba to GGADMIN;
grant execute on utl_file to GGADMIN
begin
dbms_goldengate_auth.grant_admin_privilege('GGADMIN');
end;
/
8.2.5Instantiierung
Die Instantiierung der INITIAL-LOAD wurde schon im Punkt
2.7 erklärt. In unserem Beispiel benötigen wir für unsere Tabelle GG_HEARTBEAT_TABLE kein INITIAL-LOAD. Die Tabelle beinhaltet keine Daten, sondern nur eine Spalte mit Datum
und Zeit, die ständig aktualisiert wird. Es ist deshalb egal, mit
welchem Inhalt der Spalte CURRENT_TIME die Replikation
startet. Anders sieht es mit der Instantiierung aus. Sie legt
den Startpunkt für den Replicat-Prozess fest. Voraussetzung
für die Replikation ist ein durch den Extract-Prozess erstelltes
Local Trail oder Remote Trail File. Im Beispiel beginnen beide Extract-Prozesse die Redolog-Verarbeitung zum Zeitpunkt
der Definition (ADD EXTRACT mit BEGIN NOW) zu starten.
Genauso machen wir es mit den Replicat-Prozessen. Da wir
keinen bestimmten Startpunkt angeben, beginnen auch die
83
Aufbau der GoldenGate-Parameterdateien
Replicat-Prozesse ihre Arbeit beim ersten verfügbaren Trail
File (ADD REPLICAT ohne Angabe eines Startpunktes).
Extract- und Replicat-Prozesse müssen nach Einrichten der
Replikationsumgebung explizit über Kommando gestartet
werden. Sie sehen die entsprechenden ADD-Anweisungen
in den Punkten 8.4.1 und 8.4.2 und das Starten der Prozesse
in Punkt 8.6.
8.3
Aufbau der GoldenGate-Par ameterdateien
Das Einrichten einer Replikation erfordert den Aufbau eines
Flat Files für den Manager-Prozess, jeden Extract- und jeden
Replicat-Prozess. Für die Festlegung von Parametern für die
GoldenGate-Instanz existiert außerdem die Datei GLOBALS.
Abbildung 24 zeigt noch einmal die Replikationstopologie
mit den notwendigen Parameterdateien.
ex2prio.prm
Capture
GLOBALS
Manager
re2seco.prm
mgr.prm
ORAP
Delivery
re2prio.prm
Trial
File
GG_HEARTBEAT_TABLE
Trial
File
LAN/WAN/Internet
Over TCP/IP
mgr.prm
GG_HEARTBEAT_TABLE
Delivery
Manager
GLOBALS
ORAS
Capture
ex2seco.prm
Abb.24: Topologie der Aktiv-Aktiv-Replikation mit Parameterdateien
84 Aufbau der GoldenGate-Parameterdateien
8.3.1Erstellen eines Connect-Makros
Bevor wir mit dem Aufbau der Parameter Files beginnen,
erstellen wir noch einen Makro mit den Connect-Informationen. Der wird vom Extract-Prozess EX2PRIO benutzt, um
die sicherheitsrelevanten Informationen User/Password zu
verstecken.
Aufbau des Makros: DBCONNECT.MAC im
Unterordner „dirmac“ (siehe Punkt 2.4)
Makro: DBCONNECT.MAC
MACRO #oracle_connect_demo1
BEGIN
USERID demo1, PASSWORD DEMO1
END;
BEGIN
END;
BEGIN
END;
MACRO #oracle_connect_ggadmin
BEGIN
USERID ggadmin, PASSWORD GGADMIN
END;
Wie Sie sehen, kann ein Makro die Datenbank-CONNECTInformationen für weitere Replikations-Administratoren beinhalten. Im Replikationsbeispiel wird nur der rot gekenn
zeichnete Eintrag für den Administrator GGADMIN benutzt.
I m Punkt 8.3.3 sehen Sie den Aufruf des Makros
innerhalb des Parameter Files EX2PRIO.PRM.
8.3.2Datei GLOBALS und Manager-Par ameter
Aufbau der Datei GLOBALS in jedem Installationsverzeichnis
Parameterdatei: GLOBALS
-- GLOBALS for both databases
-- Default Checkpoint Table
-- GGADMIN.DEFAULT_CHKPT1
-- Schema for DDL Replication
-- GGSCHEMA GGADMIN
-- Use GoldenGate Monitor
-- ENABLEMONITORING
LOBALS (immer in Großbuchstaben!) beinhaltet
G
Parameter für die GoldenGate-Instanz. Diese Datei
sieht für beide GoldenGate-Instanzen gleich aus.
Notwendig ist sie für DDL-Replikation, die Nutzung
einer Default Checkpoint Table und für die Verbindung der GoldenGate-Instanz (Client) mit dem
85
GoldenGate Monitor Server oder dem Oracle Enterprise Manager.
LOBALS ist die einzige Parameterdatei, die im In
G
stallationsverzeichnis stehen muss.
Aufbau der Manager-Parameterdateien im
Unterordner „dirprm“ (siehe Punkt 2.4)
Parameterdatei: MGR.PRM (Primäre Datenbank ORAP)
-- Manager config file
-- Port number that manager runs on
PORT 7810
-- Forces manager to restart extract, pump and replicat if they
shut down
-- AUTORESTART ER *, RETRIES 12, WAITMINUTES 5, RESETMINUTES 60
-- Manages trail files to conserve space
PURGEOLDEXTRACTS .\dirdat\tstact\*, USECHECKPOINTS, MINKEEPHOURS
1, FREQUENCYMINUTES 30
-- Specifies to log the lag time as a warning in the event log
LAGCRITICALMINUTES 5
-- Specifies how often to report lag info to the event log
LAGREPORTMINUTES 60
LAGINFOMINUTES 0
Parameterdatei: MGR.PRM (Sekundäre Datenbank ORAS)
-- Manager config file
-- Port number that manager runs on
PORT 7811
-- Forces manager to restart extract, pump and replicat if they
shut down
-- AUTORESTART ER *, RETRIES 12, WAITMINUTES 5, RESETMINUTES 60
-- Manages trail files to conserve space
PURGEOLDEXTRACTS .\dirdat\tstact\*, USECHECKPOINTS, MINKEEPHOURS
1, FREQUENCYMINUTES 30
-- Specifies to log the lag time as a warning in the event log
LAGCRITICALMINUTES 5
-- Specifies how often to report lag info to the event log
LAGREPORTMINUTES 60
LAGINFOMINUTES 0
Wichtigster Parameter für den Manager-Prozess ist
der Parameter PORT. Laufen mehrere GoldenGateInstanzen, dann müssen die Manager beider Instanzen unterschiedliche Ports nutzen. Im Beispiel nutzen
die Manager der beiden Instanzen die Ports 7810 und
7811. Das ist auch der einzige Unterschied zwischen
beiden Parameter Files. Lässt man die anderen Parameter weg, hat das Auswirkungen auf das Reporting
von Lag-Zeiten und das „Housekeeping“ für die Trail
Files, die dann nicht mehr automatisch gelöscht werden.
87
8.3.3Extr act- und Replicat-Par ameter
Aufbau
der Extract- und der Replicat-Parameterdateien im
Unterordner „dirprm“ (siehe Punkt 2.4)
Parameterdatei: EX2PRIO.PRM (Primäre Datenbank ORAP)
-- Change Extract EX2PRIO for ORAP
EXTRACT ex2prio
-- Hide Database Connect Information
NOLIST
include .\dirmac\dbconnect.mac
-- Connect to Database
#oracle_connect_ggadmin()
LIST
-- Exclude GGADMIN-User
TRANLOGOPTIONS EXCLUDEUSER ggadmin
-- Send data to remote host
RMTHOST localhost, MGRPORT 7811
-- Send data to remote trail named rt
RMTTRAIL d:\ogg_new_tar\dirdat\tstact\rt
-- Source Table for Replication
TABLE TSTACT.GG_HEARTBEAT_TABLE;
Über
die Anweisungen NOLIST/LIST kann man die
Ausgabe bestimmter Parameteranweisungen im Report-File unterdrücken. In diesem Fall sind die sicher
heitsrelevanten Anweisungen für den CONNECT zur
Datenbank nicht im Report File zu sehen.
Parameterdatei: RE2PRIO.PRM (Primäre Datenbank ORAP)
-- Change Replicat RE2PRIO for ORAP
REPLICAT re2prio
USERID GGADMIN@orap, PASSWORD GGADMIN
-- Throw error records to discard file
DISCARDFILE .\dirrpt\re2prio.dsc, purge
-- 1:1 mapping - No Source Definition File is needed
ASSUMETARGETDEFS
-- Map the Source Table to the Target Table
MAP TSTACT.GG_HEARTBEAT_TABLE, TARGET TSTACT.GG_HEARTBEAT_TABLE;
Parameterdatei: EX2SECO.PRM (Sekundäre Datenbank ORAS)
-- Change Extract for ORAS
EXTRACT ex2seco
USERID ggadmin@oras, PASSWORD GGADMIN
RMTTRAIL d:\ogg_new_src\dirdat\tstact\rt
-- Source Table for Replication
TABLE TSTACT.GG_HEARTBEAT_TABLE;
89
90 OBEY-Kommando-Files
Parameterdatei: RE2SECO.PRM (Sekundäre Datenbank ORAS)
-- Change Replicat for ORAS
REPLICAT re2seco
DISCARDFILE .\dirrpt\re2seco.dsc, purge
-- 1:1 mapping - no Source Definition File is needed
ASSUMETARGETDEFS
-- Map the Source Table to the Target Table
MAP TSTACT.GG_HEARTBEAT_TABLE, TARGET TSTACT.GG_HEARTBEAT_TABLE;
8.4
OBEY-Kommando-Files
Zusätzlich zu den Parameter Files erfordert die Konfiguration von GoldenGate weitere Kommandos. Beispiele dafür
sind das Definieren der GoldenGate-Prozesse und notwendige Aktionen in der Datenbank. Wie schon unter Punkt
2.8.2 beschrieben, können durch den Aufruf eines OBEY
Files mehrere Kommandos am Stück ausgeführt werden.
Für das Einrichten der Replikationsumgebung nutze ich
auf beiden Seiten Setup OBEY Files. Auch für das Löschen
der Umgebung wird für jede GoldenGate-Instanz ein
Cleanup OBEY File genutzt (siehe Punkte 8.4.1 und 8.4.2).
OBEY-Kommando-Files
8.4.1 Primäre Datenbank
Aufbau
der OBEY Files für Setup und Cleanup
(diese Files stehen im Installationsverzeichnis „d:\ogg_new_src“)
OBEY File: SETUP_ORAP.OBY
-- *** Statements to Replicat from ORAP to ORAS ***
-- Database login to primary database
DBLOGIN USERID ggadmin@orap PASSWORD GGADMIN
-- Add table level supplemental log group for heartbeat table
ADD TRANDATA TSTACT.GG_HEARTBEAT_TABLE
-- Verify supplemental log group was created
INFO TRANDATA tstact.gg_heartbeat_table
-- Add log-based change extract process
ADD EXTRACT ex2prio, TRANLOG, BEGIN now
-- Add remote trail to extract process
ADD RMTTRAIL d:\ogg_new_tar\dirdat\tstact\rt, EXTRACT ex2prio
-- GG change extract will be started later manually
-- START EXTRACT ex2prio
-- *** Statements to Replicat from ORAS to ORAP ***
DBLOGIN USERID GGADMIN@orap, PASSWORD GGADMIN
-- Add a specific Checkpoint Table
91
ADD CHECKPOINTTABLE GGADMIN.GG_CHKPT1
-- Add change replicat process
ADD REPLICAT re2prio, EXTTRAIL d:\ogg_new_src\dirdat\tstact\rt,
CHECKPOINTTABLE GGADMIN.GG_CHKPT1
-- GG change replicat will be started later manually
-- START REPLICAT re2prio
-- Info
INFO ALL
OBEY File: CLEANUP_ORAP.OBY
-- *** Stop and delete GG change replicat ***
-- Stop change replicat re2prio
STOP REPLICAT re2prio
DBLOGIN USERID ggadmin@orap PASSWORD GGADMIN
-- Delete supplemental log group for replication table
DELETE TRANDATA TSTACT.GG_HEARTBEAT_TABLE
-- Delete the specific checkpoint table without prompt (!)
DELETE CHECKPOINTTABLE ggadmin.gg_chkpt1 !
-- Delete change replicate re2prio
DELETE REPLICAT re2prio
-- *** Stop and delete GG change extract ***
OBEY-Kommando-Files
-- Stop change extract ex2prio
STOP EXTRACT ex2prio
-- Delete change extract ex2prio
DELETE EXTRACT ex2prio
8.4.2Sekundäre Datenbank
Aufbau der OBEY Files für Setup und Cleanup
(diese Files stehen im Installationsverzeichnis „d:\ogg_new_tar“)
OBEY File: SETUP_ORAS.OBY
-- *** Statements to Replicat from ORAS to ORAP ***
-- Database login to secondary database
DBLOGIN USERID GGADMIN@oras, PASSWORD GGADMIN
-- Add a specific checkpoint table
ADD CHECKPOINTTABLE GGADMIN.GG_CHKPT1
-- Add change replicat process
ADD REPLICAT re2seco, EXTTRAIL d:\ogg_new_tar\dirdat\tstact\rt,
CHECKPOINTTABLE GGADMIN.GG_CHKPT1
-- GG change replicat will be started later manually
-- START EXTRACT re2seco
-- *** Statements to Replicat from ORAP to ORAS ***
-- Log in to create supplemental log group
93
DBLOGIN USERID GGADMIN@oras PASSWORD GGADMIN
-- Add table level supplemental log group for heartbeat table
ADD TRANDATA TSTACT.GG_HEARTBEAT_TABLE
-- Verify supplemental log group was created
INFO TRANDATA TSTACT.GG_HEARTBEAT_TABLE
-- Add log-based change extract process
ADD EXTRACT ex2seco, TRANLOG, BEGIN now
-- Add remote trail to extract process
ADD RMTTRAIL d:\ogg_new_src\dirdat\tstact\rt, EXTRACT ex2seco
-- GG change extract will be started later manually
-- START EXTRACT ex2seco
-- Info
INFO ALL
OBEY File: CLEANUP_ORAS.OBY
-- *** Stop and delete GG change replicat ***
-- Stop change replicat re2seco
STOP REPLICAT re2seco
-- Database login to secondary database
DBLOGIN USERID ggadmin@oras PASSWORD GGADMIN
-- Delete supplemental log group for replication table
DELETE TRANDATA TSTACT.GG_HEARTBEAT_TABLE
-- Delete the specific checkpoint table without prompt (!)
DELETE CHECKPOINTTABLE ggadmin.gg_chkpt1 !
Einrichten der Replikationsumgebung (OBEY Files)
-- Delete change replicat re2seco
DELETE REPLICAT re2seco
-- *** Stop and delete GG change extract ***
-- Stop change extract ex2seco
STOP EXTRACT ex2seco
-- Delete change extract ex2seco
DELETE EXTRACT ex2seco
8.5
Einrichten der Replik ationsumgebung
(OBEY Files)
Ausführen der beiden OBEY Files für Setup
ORAP → ggsci → obey setup_orap.oby
rights reserved.
GGSCI (JJT420) 1> obey setup_orap.oby
95
96 Einrichten der Replikationsumgebung (OBEY Files)
GGSCI (JJT420) 2> -- *** Statements to Replicat from ORAP to
ORAS ***
GGSCI (JJT420) 3> -- Database login to primary database
GGSCI (JJT420) 4> DBLOGIN USERID ggadmin@orap PASSWORD GGADMIN
GGSCI (JJT420) 5> -- Add table level supplemental log group for
heartbeat table
GGSCI (JJT420) 7> ADD TRANDATA TSTACT.GG_HEARTBEAT_TABLE
Logging of supplemental redo data enabled for table TSTACT.
GG_HEARTBEAT_TABLE.
GGSCI (JJT420) 8> -- Verify supplemental log group was created
GGSCI (JJT420) 9> INFO TRANDATA TSTACT.GG_HEARTBEAT_TABLE
Logging of supplemental redo log data is enabled for table
TSTACT.GG_HEARTBEAT_TABLE.
Columns supplementally logged for table TSTACT.GG_HEARTBEAT_TABLE: DB_NAME.
GGSCI (JJT420) 10> -- Add log-based change extract process
GGSCI (JJT420) 11> ADD EXTRACT ex2prio, TRANLOG, BEGIN now
Einrichten der Replikationsumgebung (OBEY Files) EXTRACT added.
GGSCI (JJT420) 12> -- Add remote trail to extract process
GGSCI (JJT420) 13> ADD RMTTRAIL d:\ogg_new_tar\dirdat\tstact\rt,
EXTRACT ex2prio
RMTTRAIL added.
GGSCI (JJT420) 14> -- GG change extract will be started later
manually
GGSCI (JJT420) 15> -- START EXTRACT ex2prio
GGSCI (JJT420) 16> -- *** Statements to Replicat from ORAS to
ORAP ***
GGSCI (JJT420) 18> DBLOGIN USERID GGADMIN@orap, PASSWORD GGADMIN
GGSCI (JJT420) 19> -- Add a specific Checkpoint Table
GGSCI (JJT420) 20> ADD CHECKPOINTTABLE GGADMIN.GG_CHKPT1
Successfully created checkpoint table GGADMIN.GG_CHKPT1.
GGSCI (JJT420) 21> -- Add change replicat process
97
GGSCI (JJT420) 22> ADD REPLICAT re2prio, EXTTRAIL d:\ogg_new_src\dirdat\
tstact\rt, CHECKPOINTTABLE GGADMIN.GG_CHKPT1
REPLICAT added.
GGSCI (JJT420) 23> -- GG change replicat will be started later manually
GGSCI (JJT420) 24> -- START REPLICAT re2prio
GGSCI (JJT420) 25> -- Info
GGSCI (JJT420) 26> INFO ALL
Program
StatusGroupLag at Chkpt
Time Since Chkpt
MANAGERSTOPPED
EXTRACT
STOPPED EX2PRIO00:00:00
00:00:05
REPLICAT
STOPPEDRE2PRIO00:00:00
00:00:01
GGSCI (JJT420) 27>
ORAP → ggsci → obey setup_oras.oby
D:\ogg_new_tar>ggsci
Einrichten der Replikationsumgebung (OBEY Files) Copyright (C) 1995, 2012, Oracle and/or its affiliates. All
rights reserved.
GGSCI (JJT420) 2> obey setup_oras_oby
GGSCI (JJT420) 3> -- *** Statements to Replicat from ORAS to
ORAP ***
GGSCI (JJT420) 4> -- Database login to secondary database
GGSCI (JJT420) 5> DBLOGIN USERID GGADMIN@oras, PASSWORD GGADMIN
GGSCI (JJT420) 6> -- Add a specific checkpoint table
GGSCI (JJT420) 7> ADD CHECKPOINTTABLE GGADMIN.GG_CHKPT1
Successfully created checkpoint table GGADMIN.GG_CHKPT1.
GGSCI (JJT420) 8> -- Add change replicat process
GGSCI (JJT420) 9> ADD REPLICAT re2seco, EXTTRAIL d:\ogg_new_tar\
dirdat\tstact\rt, CHECKPOINTTABLE GGADMIN.GG_CHKPT1
REPLICAT added.
GGSCI (JJT420) 10> -- GG change replicat will be started later
manually
99
GGSCI (JJT420) 11> -- START EXTRACT re2seco
GGSCI (JJT420) 12> -- *** Statements to Replicat from ORAP to
ORAS ***
GGSCI (JJT420) 13> -- Log in to create supplemental log group
GGSCI (JJT420) 14> DBLOGIN USERID GGADMIN@oras PASSWORD GGADMIN
GGSCI (JJT420) 15> -- Add table level supplemental log group for
heartbeat table
GGSCI (JJT420) 16> ADD TRANDATA TSTACT.GG_HEARTBEAT_TABLE
Logging of supplemental redo log data is already enabled for
table TSTACT.GG_HEARTBEAT_TABLE.
GGSCI (JJT420) 17> -- Verify supplemental log group was created
GGSCI (JJT420) 18> INFO TRANDATA TSTACT.GG_HEARTBEAT_TABLE
Logging of supplemental redo log data is enabled for table
TSTACT.GG_HEARTBEAT_TABLE
GGSCI (JJT420) 19>
GGSCI (JJT420) 20> -- Add log-based change extract process
Einrichten der Replikationsumgebung (OBEY Files) 101
GGSCI (JJT420) 21> ADD EXTRACT ex2seco, TRANLOG, BEGIN now
EXTRACT added.
GGSCI (JJT420) 22> -- Add remote trail to extract process
GGSCI (JJT420) 23> ADD RMTTRAIL d:\ogg_new_src\dirdat\tstact\rt,
EXTRACT ex2seco
RMTTRAIL added.
GGSCI (JJT420) 24> -- GG change extract will be started later manually
GGSCI (JJT420) 25> -- START EXTRACT ex2seco
GGSCI (JJT420) 26> -- Info
Program
StatusGroupLag at ChkptTime Since Chkpt
MANAGERSTOPPED
EXTRACTSTOPPEDEX2SECO00:00:00
00:00:02
REPLICATSTOPPEDRE2SECO 00:00:00
00:00:07
GGSCI (JJT420) 28>
102 Starten und Stoppen der Replikation
Bitte
achten Sie darauf, dass Sie die Command-Prompt
Fenster für das richtige Installationsverzeichnis öffnen. Die
Manager-, Extract- und Replicat-Prozesse werden in den
Skripten nicht gestartet (Start-Kommandos auskommentiert!). Das Setup-Skript ist nur einmal beim Einrichten der
Replikation abzuarbeiten.
8.6
Starten und Stoppen der Replik ation
Die Replikationsumgebung ist nun eingerichtet und wir sehen
die drei Prozesse auf der primären und der sekundären GoldenGate-Instanz im Zustand STOPPED. Der Manager-Prozess muss
in jeder GoldenGate-Instanz als erster Prozess gestartet werden.
Die Extract- und Replicat-Prozesse können danach in beliebiger
Reihenfolge gestartet werden. Logisch sinnvoll ist es, einen
Extract-Prozess vor dem entsprechenden Replicat-Prozess zu
starten. Da wir in diesem Beispiel kein INITIAL-LOAD durchführen müssen, können wir die beiden Replikationsrichtungen in
beliebiger Reihenfolge starten. Aus Gründen der Übersichtlichkeit beginnen wir aber mit der Replikation von der primären zur
sekundären Datenbank (ORAP → ORAS) und starten danach die
Gegenrichtung (ORAS → ORAP):
Starten der Manager-, der Extract- und der Replicat-Prozesse
ORAS → ggsci → start manager (→ info all)
103
Starten und Stoppen der Replikation
rights reserved.
GGSCI (JJT420) 1> start manager
Manager started.
GGSCI (JJT420) 2> info all
Program
MANAGERRUNNING
02:02:53
REPLICAT
STOPPEDRE2SECO00:00:00
02:02:45
GGSCI (JJT420) 3>
ORAP → ggsci → start manager → start ex2prio (→ info all)
rights reserved.
GGSCI (JJT420) 1> start manager
Manager started.
GGSCI (JJT420) 2> start ex2prio
Sending START request to MANAGER ...
EXTRACT EX2PRIO starting
Program
MANAGERRUNNING
EXTRACTRUNNINGEX2PRIO00:00:00
00:00:08
REPLICAT
02:03:21
GGSCI (JJT420) 4>
ORAS → ggsci → start re2seco → start ex2seco (→ info all)
GGSCI (JJT420) 3> start re2seco
REPLICAT RE2SECO starting
GGSCI (JJT420) 4> start ex2seco
EXTRACT EX2SECO starting
Program
MANAGERRUNNING
EXTRACTRUNNINGEX2SECO00:00:00
00:00:02
REPLICATRUNNINGRE2SECO00:00:00
00:00:06
GGSCI (JJT420) 6>
105
ORAP → ggsci → start re2prio (→ info all)
GGSCI (JJT420) 4> start re2prio
REPLICAT RE2PRIO starting
Program
MANAGERRUNNING
EXTRACTRUNNINGEX2PRIO00:00:00
00:00:09
REPLICATRUNNINGRE2PRIO00:00:00
00:00:04
GGSCI (JJT420) 6>
enn alle Prozesse im Status RUNNING sind, können
W
Sie über Anzeige des Inhaltes der Tabelle GG_HEARTBEAT_TABLE sehen, dass die Zeitwerte einmal pro
Minute aktualisiert werden und diese UPDATES auch
repliziert werden (siehe Punkt 8.7).
Die Replikation kann jederzeit gestoppt werden. Das heißt, die
Aktualisierung der Tabelleninhalte wird unterbrochen, wenn
entweder der Extract- oder der Replicat-Prozess gestoppt wird.
Startet man einen zuvor gestoppten Prozess wieder, setzt er
seine Arbeit an der Stelle fort, an der er unterbrochen wurde.
Möglich ist das durch Checkpoint-Informationen, die für jeden
GoldenGate-Prozess ständig aktuell gehalten werden. Jeder ExtractProzess benötigt auch die Redolog-Informationen der entsprechenden Datenbank vom letzten Checkpoint bis zum aktuellen Zeitpunkt.
Das Stoppen der Prozesse ist wieder wahlfrei möglich. Stoppt man einen Replicat-Prozess wird das Local Trail oder Remote Trail weiterhin
vom Extract-Prozess gefüllt. Deshalb stoppt man in der Regel zuerst
den Extract- und danach den dazugehörigen Replicat-Prozess. Am
Tabelleninhalt unserer replizierten Tabellen erkennt man sofort, wenn
eine Replikationsrichtung nicht mehr arbeitet. Man kann aber nicht
sagen, ob der Extract-, der Replicat- oder beide Prozesse inaktiv sind.
Um das zu ermitteln, muss man in beiden GoldenGate-Instanzen das
Kommando INFO ALL ausführen.
Stoppen
der Manager-, der Extract- und der Replicat-Prozesse
ORAP → ggsci → stop ex2prio → stop re2prio → stop manager !
(→ info all)
...
GGSCI (JJT420) 9> stop ex2prio
Sending STOP request to EXTRACT EX2PRIO ...
Request processed.
GGSCI (JJT420) 10> stop re2prio
107
Sending STOP request to REPLICAT RE2PRIO ...
Request processed.
Program
MANAGERRUNNING
EXTRACTSTOPPEDEX2PRIO00:00:00
00:00:30
REPLICAT
00:00:09
GGSCI (JJT420) 12> stop manager !
Sending STOP request to MANAGER ...
Request processed.
Manager stopped.
GGSCI (JJT420) 13>
ORAS → ggsci → stop ex2seco → stop ex2seco → stop manager !
(→ info all)
...
GGSCI (JJT420) 8> stop ex2seco
Sending STOP request to EXTRACT EX2SECO ...
Request processed.
GGSCI (JJT420) 9> stop re2seco
Sending STOP request to REPLICAT RE2SECO ...
108 Kontrolle der Replikation
Request processed.
Program
MANAGERRUNNING
00:00:52
REPLICAT
STOPPEDRE2SECO00:00:00
00:00:29
GGSCI (JJT420) 11> stop manager !
Sending STOP request to MANAGER ...
Request processed.
Manager stopped.
GGSCI (JJT420) 12>
8.7
Kontrolle der Replik ation
Zur Kontrolle der Replikation muss man sich den Inhalt der Tabelle
TSTACT.GG_HEARTBEAT_TABLE in beiden Datenbanken anschauen. Das kann man durch Eingabe der SELECT-Kommandos
oder durch Aufruf des SQL-Skripts GG_HB_SELECT_TABLE.SQL
machen.
SQL-Skript: GG_HB_SELECT_TABLE.SQL
/*
Select: GG_HB_SELECT_TABLE.SQL
*/
Kontrolle der Replikation
109
connect ggadmin/GGADMIN@orap
select db_name,
to_char(Current_time,'dd.mm.yyyy,hh24.mi.ss') "Current-Time"
from tstact.gg_heartbeat_table;
connect ggadmin/GGADMIN@oras
select db_name,
to_char(Current_time,'dd.mm.yyyy,hh24.mi.ss') "Current-Time"
from tstact.gg_heartbeat_table;
Anzeigen
des Inhaltes der Tabellen GG_HEARTBEAT_TABLE
SQLPlus → (ORAP oder ORAS) → @gg_hb_select_table
SQL> @gg_hb_select_table
Connect durchgeführt.
GLOBAL_NAME
----------ORAP.DE.ORACLE.COM
DB_NAME
Current-Time
------------------------------ ------------------ORAP.DE.ORACLE.COM
30.07.2012,11.17.00
ORAS.DE.ORACLE.COM
30.07.2012,11.17.00
110 Kontrolle der Replikation
GLOBAL_NAME
-----------------ORAS.DE.ORACLE.COM
DB_NAME
Current-Time
30.07.2012,11.17.00
ORAS.DE.ORACLE.COM
30.07.2012,11.17.00
SQL>
Sind die Zeiteinträge für beide Datenbanken identisch (wie das
Ergebnis zeigt), dann laufen beide Replikationen fehlerfrei. Sollte
das Ergebnis einmal nicht so gut aussehen wie gerade gezeigt, dann
muss man die GoldenGate Reports der einzelnen Prozesse anschauen. Sie beinhalten entsprechende Fehlermeldungen, wenn Replikationsprozesse nicht ordnungsgemäß laufen. Wenn die Replikation
in beide Richtungen gestoppt wurde, wird nur ein Eintrag in jeder
Tabelle aktualisiert. Der Zeitwert des replizierten Eintrages zeigt die
Zeit an, zu der letztmalig eine Replikation erfolgte. Das Ergebnis der
nächsten Inhaltsabfrage beider Tabellen sagt aus, dass beide Replikationsrichtungen am 30.07.2012 zwischen 12:28 und 12:29 gestoppt
wurden:
GLOBAL_NAME
----------ORAP.DE.ORACLE.COM
Einbau einer UPDATE-Konfliktlösung
DB_NAME
Current-Time
30.07.2012,12.39.00
ORAS.DE.ORACLE.COM
30.07.2012,12.28.00
GLOBAL_NAME
-----------
ORAS.DE.ORACLE.COM
DB_NAME
Current-Time
30.07.2012,12.28.00
ORAS.DE.ORACLE.COM
30.07.2012,12.39.00
SQL>
8.8
8.8.1Ergänzen der GoldenGate-Par ameterdateien
In der Aktiv-Aktiv-Replikation benutzen wir eine Tabelle, die
nur aus zwei Spalten besteht. DB_NAME ist vom Datentyp
VARCHAR2 und PRIMARY KEY der Tabelle. CURRENT_
TIME ist vom Datentyp DATE. Durch Implementierung
einer UPDATE-Konfliktlösung soll die beschriebene Replikation gegen Konflikte abgesichert werden. Gegenwärtig kann
die eingerichtete Replikation weder Konflikte erkennen
111
112 Einbau einer UPDATE-Konfliktlösung
noch behandeln, weil beim UPDATE von CURRENT_TIME
kein Vergleich des BEFORE-IMAGE mit dem aktuellen Spalteninhalt erfolgt. Das gilt für beide Replikationsprozesse.
Der alte Inhalt von CURRENT_TIME wird auf beiden Seiten
einfach mit dem aktuellen Zeitwert überschrieben. Das erfolgt immer, unabhängig davon, ob in der letzten Minute der
Inhalt von CURRENT_TIME durch unerlaubte beziehungsweise unbeabsichtigte Modifikation durch Dritte verändert
wurde. Die Konfiguration ist sehr einfach, weil pro Prozess
nur eine Anweisung im Parameter File des entsprechenden
Prozesses angepasst werden muss. Die OBEY Files für Setup
beziehungsweise Cleanup bleiben unverändert. Nach Anpassung sehen die Parameter Files (Punkt 8.3) für EXTRACT und
REPLICAT so aus:
rgänzen der Parameter Files der Extract- und
E
Replikat-Prozesse
Parameterdatei: EX2PRIO.PRM (Primäre Datenbank ORAP)
-- Change Extract EX2PRIO for ORAP
EXTRACT ex2prio
NOLIST
include .\dirmac\dbconnect.mac
#oracle_connect_ggadmin()
LIST
-- Source Table for Replication without BEFORE-IMAGES
-- TABLE TSTACT.GG_HEARTBEAT_TABLE;
-- Source Table for Replication with BEFORE-IMAGES in case of
UPDATE operation
-- BEFORE-IMAGES are required by COMPARECOLS parameter at replication site
TABLE TSTACT.GG_HEARTBEAT_TABLE, GETBEFORECOLS (ON UPDATE ALL);
Alle Parameter Files beinhalten alternative TABLEbeziehungsweise MAP-Anweisungen (auskommentiert).
Der
Parameter GETBEFORECOLS ist die Voraus
setzung für Konfliktlösung auf der Replicat-Seite.
Parameterdatei: RE2PRIO.PRM (Primäre Datenbank ORAP)
-- Change Replicat RE2PRIO for ORAP
REPLICAT re2prio
USERID GGADMIN@orap, PASSWORD GGADMIN
113
DISCARDFILE .\dirrpt\re2prio.dsc, purge
-- 1:1 mapping - No Source Definition File is needed
ASSUMETARGETDEFS
-- Map the Source Table to the Target Table without Conflict
Detection and Resolution
-- MAP TSTACT.GG_HEARTBEAT_TABLE, TARGET TSTACT.GG_HEARTBEAT_TABLE;
-- Map the Source Table to the Target Table with Conflict Detection but without Resolution
-- MAP TSTACT.GG_HEARTBEAT_TABLE, TARGET TSTACT.GG_HEARTBEAT_TABLE, COMPARECOLS (ON UPDATE ALL);
MAP TSTACT.GG_HEARTBEAT_TABLE, TARGET TSTACT.GG_HEARTBEAT_TABLE,
COMPARECOLS (ON UPDATE ALL),
RESOLVECONFLICT (UPDATEROWEXISTS, (DEFAULT, OVERWRITE));
Replicat
RE2PRIO nutzt nur Standardkonfliktlösung
OVERWRITE
Benutzt
man COMPARECOLS ohne RESOLVECON
FLICT (siehe zweite MAP-Anweisung), dann führen
Konflikte zum ABEND des betroffenen Replikationsprozesses, also zum Absturz.
Parameterdatei: EX2SECO.PRM (Sekundäre Datenbank ORAS)
-- Change Extract for ORAS
EXTRACT ex2seco
RMTTRAIL d:\ogg_new_src\dirdat\tstact\rt
-- Source Table for Replication without BEFORE-IMAGES
-- Source Table for Replication with BEFORE-IMAGES in case of
UPDATE operation
-- BEFORE-IMAGES are required by COMPARECOLS parameter at replication site
Parameterdatei: RE2SECO.PRM (Sekundäre Datenbank ORAS)
-- Change Replicat for ORAS
REPLICAT re2seco
-- 1:1 mapping - no Source Definition File is needed
ASSUMETARGETDEFS
115
-- Map the Source Table to the Target Table without Conflict Detection and Resolution
-- MAP TSTACT.GG_HEARTBEAT_TABLE, TARGET TSTACT.GG_HEARTBEAT_TABLE, COMPARECOLS (ON UPDATE ALL);
-- Map the Source Table to the Target Table without Conflict Detection and Resolution
MAP TSTACT.GG_HEARTBEAT_TABLE, TARGET TSTACT.GG_HEARTBEAT_TABLE,
COMPARECOLS (ON UPDATE ALL),
RESOLVECONFLICT (UPDATEROWEXISTS, (max_resolution_method,
USEMAX(CURRENT_TIME),
COLS(CURRENT_TIME)), (DEFAULT, IGNORE));
Replicat RE2SECO nutzt Konfliktlösungsmethode USEMAX und Standardkonfliktlösung IGNORE. Die Angabe
einer Standardkonfliktlösung ist immer erforderlich.
8.8.2Test der Konfliktbehandlung
Nach Aktualisierung der Parameter Files und einem Neustart
der Extract- und Replicat-Prozesse, kann man die Konflikterkennung und deren Behandlung auf einfache und übersichtliche Art mit dem SQL-Skript GG_HB_CONFLICT testen:
/*
Produce a Conflict at both Replication sites for Table GG_
HEARTBEAT_TABLE
*/
connect ggadmin/GGADMIN@orap
-update tstact.gg_heartbeat_table set current_time = sysdate
where db_name = 'ORAS.DE.ORACLE.COM';
commit;
-connect ggadmin/GGADMIN@oras
-update tstact.gg_heartbeat_table set current_time = sysdate
where db_name = 'ORAP.DE.ORACLE.COM';
commit;
Das Skript sollte kurze Zeit nach der Synchronisation aller
Zeitwerte in CURRENT_TIME ausgeführt werden. Damit
sind die über SYSDATE eingetragenen Sekundenwerte mit
Sicherheit ungleich „00“ und sofort als „Konfliktwerte“ zu
erkennen, wenn man sich danach den Inhalt beider Tabellen
GG_HEARTBEAT_TABLE mittels SQL-Skript GG_HB_SELECT_TABLE anschaut.
Test der Konfliktlösung mittels Skript
GG_HB_CONFLICT.SQL
1. Starten der GoldenGate-Prozesse wie in Punkt 8.6
beschrieben
117
→ alle Prozesse müssen im Status RUNNING sein!
2. S
tarten einer SQLPlus-Session und Ausführen der
Kommandos wie dargestellt:
...
...
...
D ie Replikation läuft, alle CURRENT_TIME Werte sind synchron!
(15.23.00)
GLOBAL_NAME
-----------------ORAP.DE.ORACLE.COM
DB_NAME
Current-Time
13.08.2012,15.23.00
ORAS.DE.ORACLE.COM
13.08.2012,15.23.00
GLOBAL_NAME
DB_NAME
Current-Time
13.08.2012,15.23.00
ORAS.DE.ORACLE.COM
13.08.2012,15.23.00
Jetzt wird auf beiden Seiten ein Konflikt ausgelöst
SQL> @gg_hb_conflict
GLOBAL_NAME
1 Zeile wurde aktualisiert.
Transaktion mit COMMIT abgeschlossen.
GLOBAL_NAME
B eide Tabellen besitzen jetzt eine Zeile mit CURRENT_TIME =
15.23.24
E s ist jeweils die Zeile, deren Inhalt durch die Replikation
aktualisiert wird
119
GLOBAL_NAME
DB_NAME
Current-Time
13.08.2012,15.23.00
ORAS.DE.ORACLE.COM
13.08.2012,15.23.24
GLOBAL_NAME
DB_NAME
Current-Time
13.08.2012,15.23.24
ORAS.DE.ORACLE.COM
13.08.2012,15.23.00
...
...
...
N ach Beginn der neuen Minute schauen wir wieder auf die Tabellen.
O bwohl das BEFORE-IMAGE auf beiden Seiten nicht mit dem ak
tuellem Inhalt von CURRENT_TIME übereinstimmt (15.23.24 <>
15.23.00), kommt es nicht zum Fehler. Das heißt, der Konflikt
wurde auf beiden Seiten durch den Replicat-Prozess erkannt
und gelöst.
GLOBAL_NAME
DB_NAME
Current-Time
13.08.2012,15.24.00
ORAS.DE.ORACLE.COM
13.08.2012,15.24.00
GLOBAL_NAME
--------------------------------------------------------------ORAS.DE.ORACLE.COM
DB_NAME
Current-Time
13.08.2012,15.24.00
ORAS.DE.ORACLE.COM
13.08.2012,15.24.00
...
...
...
Jetzt wird auf beiden Seiten ein zweiter Konflikt ausgelöst.
Beide Tabellen besitzen jetzt eine Zeile mit CURRENT_TIME =
15.30.55.
E s ist jeweils die Zeile, deren Inhalt durch die Replikation
aktualisiert wird.
121
SQL> @gg_hb_conflict
GLOBAL_NAME
GLOBAL_NAME
GLOBAL_NAME
DB_NAME
Current-Time
13.08.2012,15.30.00
ORAS.DE.ORACLE.COM
13.08.2012,15.30.55
GLOBAL_NAME
DB_NAME
Current-Time
13.08.2012,15.30.55
ORAS.DE.ORACLE.COM
13.08.2012,15.30.00
S ynchronisationsphase – ORAP-Zeitwert wurde noch nicht re
pliziert
GLOBAL_NAME
DB_NAME
Current-Time
13.08.2012,15.31.00
ORAS.DE.ORACLE.COM
13.08.2012,15.31.00
GLOBAL_NAME
DB_NAME
Current-Time
13.08.2012,15.30.55
123
ORAS.DE.ORACLE.COM
13.08.2012,15.31.00
Beide Tabelleninhalte sind wieder synchron, Konfliktbehandlung
o.k.!
GLOBAL_NAME
--------------------------------------------------------------ORAP.DE.ORACLE.COM
DB_NAME
Current-Time
13.08.2012,15.31.00
ORAS.DE.ORACLE.COM
13.08.2012,15.31.00
GLOBAL_NAME
DB_NAME
Current-Time
13.08.2012,15.31.00
ORAS.DE.ORACLE.COM
13.08.2012,15.31.00
SQL>
Wie sieht das im Report eines GoldenGate-Replicat-Prozesses aus? Im nächsten Punkt schauen wir in die Reports
des Replicat-Prozesses RE2SECO und des Extract-Prozesses
EX2PRIO.
8.8.3GoldenGate Reports
Bis jetzt sehen wir nur, dass der Replikationsprozess
RE2SECO trotz ausgelöster Konflikte noch läuft. Wir
erzeugen deshalb einen Report, der uns alle Aktionen des
Prozesses aufzeigt.
Erzeugen
eines Reports für Replicat RE2SECO
ORAS → ggsci → send replicat re2seco, report
→ view report re2seco
***************************************************************
Oracle GoldenGate Delivery for Oracle
W
indows x64 (optimized), Oracle 11g on Apr 23 2012
06:25:54
rights reserved.
125
Starting at 2012-08-13 15:21:18
***************************************************************
Operating System Version:
Microsoft Windows 7 , on x64
Version 6.1 (Build 7601: Service Pack 1)
Process id: 5936
Description:
***************************************************************
**
Running with the following parameters
**
***************************************************************
2012-08-13 15:21:18
INFO
OGG-03035
Operating system charac-
ter set identified as windows-1252. Locale: en_US, LC_ALL:.
--- Name change replicat RE2SECO on Secondary Database ORAS
-REPLICAT re2seco
USERID GGADMIN@oras, PASSWORD *******
2012-08-13 15:21:18
INFO
OGG-03501
WARNING: NLS_LANG envi-
ronment variable is invalid or not set. Using operating system
character set value of WE8MSWIN1252.
-- 1:1 mapping - no Source Definition File is needed ASSUMETARGETDEFS
127
-- MAP TSTACT.GG_HEARTBEAT_TABLE, TARGET TSTACT.GG_HEARTBEAT_TABLE COMPARECOLS (ON UPDATE ALL);
-- Map the Source Table to the Target Table with Conflict Detection and USEMAX Resolution
MAP TSTACT.GG_HEARTBEAT_TABLE, TARGET TSTACT.GG_HEARTBEAT_TABLE, COMPARECOLS (ON UPDATE ALL), RESOLVECONFLICT(UPDATEROWEXIS
TS, (max_resolution_method, USEMAX(CURRENT_TIME), COLS(CURRENT_
TIME)), (DEFAULT, IGNORE));
2012-08-13 15:21:19
INFO
OGG-01815
Virtual Memory Facili-
ties for: COM
anon alloc: MapViewOfFile
anon free: UnmapViewOfFile
file alloc: MapViewOfFile
file free: UnmapViewOfFile
target directories:
D:\ogg_new_tar\dirtmp.
CACHEMGR virtual memory values (may have been adjusted)
CACHESIZE:
2G
CACHEPAGEOUTSIZE (normal):
8M
PROCESS VM AVAIL FROM OS (min):
CACHESIZEMAX (strict force to disk):
4G
3.41G
Database Version:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE
11.2.0.3.0Production
TNS for 64-bit Windows: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production
Database Language and Character Set:
NLS_LANG
= ".WE8MSWIN1252"
NLS_LANGUAGE
= "AMERICAN"
NLS_TERRITORY
= "AMERICA"
NLS_CHARACTERSET = "WE8MSWIN1252"
***************************************************************
**
Run Time Messages
**
***************************************************************
Opened trail file d:\ogg_new_tar\dirdat\tstact\rt000004 at 201208-13 15:21:19
MAP resolved (entry TSTACT.GG_HEARTBEAT_TABLE):
MAP "TSTACT"."GG_HEARTBEAT_TABLE", TARGET TSTACT.GG_HEARTBEAT_
TABLE, COMPARECOLS (ON UPDATE ALL),
RESOLVECONFLICT(UPDATEROWEXISTS, (max_resolution_method,
USEMAX(CURRENT_TIME), COLS(CURRENT_TIME)),
(DEFAULT, IGNORE));
Using following columns in default map by name:
DB_NAME, CURRENT_TIME
Using the following key columns for target table TSTACT.GG_
HEARTBEAT_TABLE: DB_NAME.
129
Switching to next trail file d:\ogg_new_tar\dirdat\tstact\
rt000005 at 2012-08-13 15:21:22 due to EOF, with current RBA
5420
Opened trail file d:\ogg_new_tar\dirdat\tstact\rt000005 at 201208-13 15:21:22
Processed extract process graceful restart record at seq 5, rba
1017.
2012-08-13 15:32:47
GGSCI: STATS
INFO
OGG-01021
Command received from
OGG-01021
reportcdr.
2012-08-13 15:35:36
INFO
GGSCI: STOP.
***************************************************************
*
** Run Time Statistics **
*
***************************************************************
Last record for the last committed transaction is the following:
______________________________________________________________
Trail name :
d:\ogg_new_tar\dirdat\tstact\rt000005
Hdr-Ind
:
E
(x45)
Partition
:
.
(x04)
UndoFlag
:
.
(x00)
BeforeAfter:
A
(x41)
RecLength
:
51 (x0033)
IO Time
: 2012-08-13
15:35:01.000000
IOType
:
15
(x0f)
OrigNode
:
255
(xff)
TransInd
:
.
(x02)
FormatType :
R
(x52)
SyskeyLen
:
0
(x00)
Incomplete :
.
(x00)
AuditRBA
:
Continued
:
N
0
AuditPos
: 6303248
(x00)
RecCount
:
1
(x01)
2012-08-13 15:35:01.000000 FieldComp
Len
51 RBA 7934
Name: TSTACT.GG_HEARTBEAT_TABLE
________________________________________________________________
Reading d:\ogg_new_tar\dirdat\tstact\rt000005, current RBA 8089,
22 records
Report at 2012-08-13 15:35:36 (activity since 2012-08-13
15:21:22)
From Table TSTACT.GG_HEARTBEAT_TABLE to TSTACT.GG_HEARTBEAT_
TABLE:
#
inserts:
0
#
updates:
22
#
deletes:
0
#
discards:
0
# CDR conflicts
:
2
# CDR resolutions succeeded
:
2
# CDR UPDATEROWEXISTS conflicts :
2
Last log location read:
FILE:
d:\ogg_new_tar\dirdat\tstact\rt000005
SEQNO:
5
RBA:
8089
TIMESTAMP: Not Available
...
...
...
EOF:
YES
READERR:
400
Die interessanten Informationen des Reports, von dem hier
nur der erste Teil gezeigt wird, sind rot hervorgehoben.
Zuerst sind die Parameterzeilen aufgelistet. Die wirksamen
Parameter sehen wir auch noch unter den „Run Time
Messages“. Dort wird noch das Spalten-Mapping angezeigt
und die PRIMARY KEY-Spalte aufgelistet. Es werden zwei
eingegebene Kommandos protokolliert, die eingegeben
wurden: das Kommando STATS mit REPORTCDR und das
Kommando STOP sowie am Schluss dann die Information
zur Anzahl der erfolgten UPDATE-Replikationen und zu den
durchgeführten Konfliktbehandlungen. RE2SECO lief von
15.21.22 bis 15.35.36. In dieser Zeit wurden 22 UPDATES verarbeitet, sprich repliziert. Es traten zwei Konflikte vom Typ
UPDATEROWEXISTS auf, die erfolgreich behandelt wurden.
Die Ausgabe des Kommandos STATS mit Parameter
REPORTCDR sieht so aus:
...
GGSCI (JJT420) 7> stats replicat re2seco, reportcdr
Sending STATS request to REPLICAT RE2SECO ...
Start of Statistics at 2012-08-13 15:32:47.
Replicating from TSTACT.GG_HEARTBEAT_TABLE to TSTACT.GG_HEARTBEAT_TABLE:
131
*** Total statistics since 2012-08-13 15:21:22 ***
Total inserts
0.00
Total updates
19.00
Total deletes
0.00
Total discards
Total operations
0.00
19.00
Total CDR conflicts
2.00
CDR resolutions succeeded
2.00
CDR UPDATEROWEXISTS conflicts
2.00
...
End of Statistics.
Jetzt schauen wir uns auch noch den Report des dazu
gehörigen Extract-Prozesses EX2PRIO an:
Erzeugen eines Reports für Extract EX2PRIO
ORAP → ggsci → send extract ex2prio, report →
view report ex2prio
***************************************************************
Oracle GoldenGate Capture for Oracle
W indows x64 (optimized), Oracle 11g on Apr 23 2012
06:01:56
rights reserved.
133
Starting at 2012-08-13 15:20:45
***************************************************************
Operating System Version:
Microsoft Windows 7 , on x64
Version 6.1 (Build 7601: Service Pack 1)
Process id: 6724
Description:
***************************************************************
**
Running with the following parameters
**
***************************************************************
2012-08-13 15:20:45
INFO
OGG-03035
Operating system charac-
ter set identified as windows-1252. Locale: en_US, LC_ALL:.
--- Change Extract EX2PRIO for primary Database ORAP
-EXTRACT ex2prio
NOLIST
2012-08-13 15:20:45
INFO
OGG-03500
WARNING: NLS_LANG envi-
ronment variable does not match database character set, or not
set. Using database character set value of WE8MSWIN1252.
-- Exclude GG-User
-- Source table for Replication without Before-Images
-- Source table for Replication with Before-Images in case of
UPDATE operation
-- Before-Images are required by COMPARECLOS parameter at replication site
2012-08-13 15:20:45
INFO
OGG-01815
ties for: BR
target directories:
D:\ogg_new_src\BR\EX2PRIO.
Bounded Recovery Parameter:
BRINTERVAL = 4HOURS
BRDIR
= D:\ogg_new_src
2012-08-13 15:20:45
INFO
OGG-01815
ties for: COM
target directories:
D:\ogg_new_src\dirtmp.
135
CACHEMGR virtual memory values (may have been adjusted)
CACHESIZE:
4.16G
CACHEPAGEOUTSIZE (normal):
8M
PROCESS VM AVAIL FROM OS (min):
8.16G
CACHESIZEMAX (strict force to disk):
6.16G
2012-08-13 15:20:45
WARNING OGG-01842
CACHESIZE PER DYNAMIC
DETERMINATION (4.16G) LESS THAN RECOMMENDED: 64G (64bit system)
vm found: 8.16G
Check swap space. Recommended swap/extract: 128G (64bit system).
Database Version:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE
11.2.0.3.0Production
TNS for 64-bit Windows: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production
Database Language and Character Set:
NLS_LANG
= ".WE8MSWIN1252"
NLS_LANGUAGE
= "AMERICAN"
NLS_TERRITORY
= "AMERICA"
NLS_CHARACTERSET = "WE8MSWIN1252"
2012-08-13 15:20:46
INFO
OGG-01513
Positioning to Sequence
148, RBA 19375632, SCN 0.5733271.
2012-08-13 15:20:46
INFO
OGG-01516
Positioned to Sequence
148, RBA 19375632, SCN 0.5733271, Aug 9, 2012 2:51:05 PM.
2012-08-13 15:20:51
INFO
to 27985 (flush size 27985).
OGG-01226
Socket buffer size set
2012-08-13 15:20:51
INFO
OGG-01055
Recovery initialization
completed for target file d:\ogg_new_tar\dirdat\tstact\rt000004,
at RBA 5420.
2012-08-13 15:20:51
INFO
OGG-01478
Output file d:\ogg_new_
tar\dirdat\tstact\rt is using format RELEASE 11.2.
2012-08-13 15:20:51
INFO
OGG-01026
Rolling over remote file
d:\ogg_new_tar\dirdat\tstact\rt000005.
2012-08-13 15:20:51
INFO
OGG-01053
Recovery completed for
target file d:\ogg_new_tar\dirdat\tstact\rt000005, at RBA 1017.
2012-08-13 15:20:51
INFO
OGG-01057
Recovery completed for
all targets.
***************************************************************
**
Run Time Messages
**
***************************************************************
2012-08-13 15:20:51
INFO
OGG-01517
Position of first record
processed Sequence 148, RBA 19375632, SCN 0.5733271, Aug 9, 2012
2:51:05 PM.
TABLE resolved (entry TSTACT.GG_HEARTBEAT_TABLE):
TABLE "TSTACT"."GG_HEARTBEAT_TABLE", GETBEFORECOLS (ON UPDATE
ALL);
Using the following key columns for source table TSTACT.GG_
HEARTBEAT_TABLE: DB_NAME.
2012-08-13 15:20:53
INFO
OGG-00732
Found crash recovery
marker from thread #1 on sequence 148 at RBA 19760144. Aborting
uncommitted transactions.
2012-08-13 15:35:18
GGSCI: STOP.
INFO
OGG-01021
137
***************************************************************
*
** Run Time Statistics **
*
***************************************************************
Report at 2012-08-13 15:35:18 (activity since 2012-08-13
15:20:53)
Output to d:\ogg_new_tar\dirdat\tstact\rt:
From Table TSTACT.GG_HEARTBEAT_TABLE:
#
inserts:
0
#
updates:
21
#
befores:
21
#
deletes:
0
#
discards:
0
REDO Log Statistics
Read ahead buffers
3
Read ahead buffer size
1024000
Read ahead for current log
on
Bytes read
908601856
Bytes read ahead
905529856
Bytes unused
64512000
Bytes parsed
844094464
Bytes output
7072
...
...
...
138 Löschen der Replikationsumgebung
EX2PRIO lief von 15.20.45 bis 15.35.18. In dieser Zeit
wurden 21 UPDATES verarbeitet. Zu jedem UPDATE wurde
noch ein Satz mit den BEFORE-IMAGE in das entsprechende Remote Trail File auf der Zielseite geschrieben. Die Report Files der Prozesse EX2PRIO beziehungsweise EX2SECO
sehen den beiden hier gezeigten sehr ähnlich und werden
deshalb aus Platzgründen nicht aufgelistet.
8.9
Löschen der Replik ationsumgebung
Ausführen der beiden OBEY Files für Cleanup
ORAP → ggsci → obey cleanup_orap.oby
rights reserved.
GGSCI (JJT420) 1> obey cleanup_orap.oby
GGSCI (JJT420) 2> -- *** Stop and delete GG change replicat ***
GGSCI (JJT420) 3> -- Stop change replicat re2prio
Löschen der Replikationsumgebung
GGSCI (JJT420) 4> STOP REPLICAT re2prio
REPLICAT RE2PRIO is already stopped.
GGSCI (JJT420) 6> DBLOGIN USERID ggadmin@orap PASSWORD GGADMIN
GGSCI (JJT420) 7> -- Delete supplemental log group for replication table
GGSCI (JJT420) 8> DELETE TRANDATA TSTACT.GG_HEARTBEAT_TABLE
Logging of supplemental redo log data disabled for table TSTACT.
GG_HEARTBEAT_TABLE.
GGSCI (JJT420) 9> -- Delete the specific checkpoint table without prompt (!)
GGSCI (JJT420) 10> DELETE CHECKPOINTTABLE GGADMIN.GG_CHKPT1 !
Successfully deleted checkpoint table ggadmin.gg_chkpt1.
GGSCI (JJT420) 11> -- Delete change replicate re2prio
GGSCI (JJT420) 12> DELETE REPLICAT re2prio
139
Deleted REPLICAT RE2PRIO.
GGSCI (JJT420) 13> -- *** Stop and delete GG change extract ***
GGSCI (JJT420) 14> -- Stop change extract ex2prio
GGSCI (JJT420) 15> STOP EXTRACT ex2prio
EXTRACT EX2PRIO is already stopped.
GGSCI (JJT420) 16> -- Delete change extract ex2prio
GGSCI (JJT420) 17> DELETE EXTRACT ex2prio
Deleted EXTRACT EX2PRIO.
GGSCI (JJT420) 18> -- info
Program
MANAGER
STOPPED
GGSCI (JJT420) 20>
141
ORAS → ggsci → obey cleanup_oras.oby
Windows x64 (optimized), Oracle 11g on Oct
5 2011 00:28:13
rights reserved.
GGSCI (JJT420) 1> obey cleanup_oras.oby
GGSCI (JJT420) 2> -- *** Stop and delete GG change replicat ***
GGSCI (JJT420) 3> -- Stop change replicat re2seco
GGSCI (JJT420) 4> STOP REPLICAT re2seco
REPLICAT RE2SECO is already stopped.
GGSCI (JJT420) 5> -- Database login to secondary database
GGSCI (JJT420) 6> DBLOGIN USERID ggadmin@oras PASSWORD GGADMIN
GGSCI (JJT420) 7> -- Delete supplemental log group for replica-
tion table
GGSCI (JJT420) 8> DELETE TRANDATA TSTACT.GG_HEARTBEAT_TABLE
Logging of supplemental redo log data disabled for table TSTACT.GG_
HEARTBEAT_TABLE.
GGSCI (JJT420) 9> -- Delete the specific checkpoint table without prompt
(!)
GGSCI (JJT420) 10> DELETE CHECKPOINTTABLE ggadmin.gg_chkpt1 !
Successfully deleted checkpoint table ggadmin.gg_chkpt1.
GGSCI (JJT420) 11> -- Delete change replicat re2seco
GGSCI (JJT420) 12> DELETE REPLICAT re2seco
Deleted REPLICAT RE2SECO.
GGSCI (JJT420) 13> -- *** Stop and delete GG change extract ***
GGSCI (JJT420) 14> -- Stop change extract ex2seco
GGSCI (JJT420) 15> STOP EXTRACT ex2seco
EXTRACT EX2SECO is already stopped.
GGSCI (JJT420) 16> -- Delete change extract ex2seco
GGSCI (JJT420) 17> DELETE EXTRACT ex2seco
Deleted EXTRACT EX2SECO.
GGSCI (JJT420) 18> -- info
Program
StatusGroupLagTime Since Chkpt
MANAGERSTOPPED
GGSCI (JJT420) 20>
I m Beispiel verwenden wir eine spezifische Checkpoint
Table, die nur von einem Prozess genutzt wird. Wir
können sie deshalb auch bedenkenlos löschen, wenn
der dazugehörige Replicat-Prozess (RE2PRIO beziehungsweise RE2SECO) gelöscht wird. Gibt man beim
DELETE kein Ausrufezeichen (!) an, erhält man die
Nachricht:
This checkpoint table may be required for other installations.
Are you sure you want to delete this checkpoint table?
Zur Bestätigung des Löschens muss man „Y“ eingeben.
143
Das
Löschen eines Extract- oder Replicat-Prozesses
benötigt einen Login zur Datenbank:
Extract: UNREGISTER extract_name LOGRETENTION
Replicat: DELETE CHECKPOINTTABLE checkpointtable_name
Nach Abarbeitung der beiden Skripte „cleanup_orap.oby“
und „cleanup_oras.oby“ bitte noch diese Hinweise beachten:
GoldenGate
Remote Trail Files löschen
(Trail File Namen siehe Punkt 2.6):
Primäre GoldenGate-Instanz:
Alle Dateien im Pfad d:\ogg_new_src\dirdat\tstact
Sekundäre GoldenGate-Instanz:
Alle Dateien im Pfad d:\ogg_new_tar\dirdat\tstact
Wenn man das Löschen der Files vergisst, die Replikationsumgebung wieder aufbaut und das gleiche Verzeichnis erneut
verwendet, kann der Replicat-Prozess nicht starten, weil er das
aktuellste Trail File nicht finden kann.
rimäre GoldenGate-Instanz: Löschen der Report
P
Files im Pfad d:\ogg_new_src\dirrpt
Manager: mgr.rpt, mgr0.rpt, ..., mgr9.rpt
Extract-Prozess EX2PRIO:
ex2prio.rpt, ex2prio0.rpt, ..., ex2prio9.rpt
Replicat-Prozess RE2PRIO:
re2prio.rpt, re2prio0.rpt, …, re2prio9.rpt
(Nicht unbedingt nötig, aus Gründen der Übersichtlichkeit empfohlen!)
Sekundäre GoldenGate-Instanz: Löschen der Report
Files im Pfad d:\ogg_new_tar\dirrpt
Manager: mgr.rpt, mgr0.rpt, ..., mgr9.rpt
Extract-Prozess EX2SECO:
ex2seco.rpt, ex2seco0.rpt, ..., ex2seco9.rpt
Replicat-Prozess RE2SECO:
re2seco.rpt, re2seco0.rpt, …, re2seco9.rpt
(Nicht unbedingt nötig, aus Gründen der Übersichtlichkeit empfohlen!)
145
Primäre
GoldenGate-Instanz: Löschen von Checkpoint Files
im Pfad d:/ogg_new_src/dirchk
(Diese Files sollten normalerweise nach dem Löschen der Replikationsumgebung nicht
mehr existieren!)
Extract-Prozess EX2PRIO: ex2prio.cpd, ex2prio.cpe, ex2prio.cps
Replicat-Prozess RE2PRIO: re2prio.cpr, re2prio.cps
Sekundäre
GoldenGate-Instanz: Löschen von Checkpoint Files
im Pfad d:/ogg_new_tar/dirchk
(Diese Files sollten normalerweise nach dem Löschen der Replikationsumgebung nicht
mehr existieren!)
Extract-Prozess EX2SECO: ex2seco.cpd, ex2seco.cpe, ex2seco.cps
Replicat-Prozess RE2SECO: re2seco.cpr, re2seco.cps
Schlusswort
9 Schlusswort
Sie sind nun am Ende des Dojo angekommen. Wenn Sie
alles gelesen haben, sollten „GoldenGate“ und „Replikation“ keine Fremdworte mehr für Sie sein. Vielleicht hat
der eine oder andere auch schon selbst probiert, die hier
vorgestellte Aktiv-Aktiv-Replikation in seiner Umgebung zu
implementieren. Wenn ja, dann hoffentlich erfolgreich. Ich
möchte aber noch ein paar Worte dazu sagen, warum ich
gerade dieses Beispiel zur Grundlage des Dojo gemacht
habe. Leser werden vielleicht Themen vermisst haben, die
für eine Replikation von großer Bedeutung sind. So bin
ich nur kurz auf INITIAL-LOAD beziehungsweise Instantiierung eingegangen. Ich habe auch nur eine Eins-zu-einsReplikation behandelt, bei der das Replikationsobjekt auf
Quell- und Zieldatenbank einen identischen Aufbau hat.
Vielleicht ist auch jemand der Meinung, das Beispiel sei
praxisfremd, weil niemals nur eine Tabelle mit zwei Spalten
repliziert wird? Ja, Sie haben recht! Das Dojo behandelt das
Thema Replikation nicht erschöpfend. Aber das ist auch
nicht das Anliegen dieser kleinen Publikation. Unsere Dojos
sind an Leser gerichtet, die sich erstmals mit einem Thema
beschäftigen und so schnell wie möglich kleine Erfolge erzielen möchten. Damit sind sie motiviert, sich tiefgründiger
mit der Problematik zu befassen. Allein zu GoldenGate gibt
es einen Berg an Dokumentation, den man durchdringen
147
148 SChlusswort
muss, wenn man eine Replikation aufbauen will. Aus folgenden
Gründen wurde diese Aktiv-Aktiv-Replikation zur Basis für das Dojo
gewählt:
1.Einfach und überschaubar durch nur eine kleine Tabelle
2.Schneller Start weil kein INITIAL-LOAD nötig
3.Minimaler Ressourcenbedarf in der Datenbank
4.Replikationszustand am Inhalt der Tabellen schnell erkennbar
5.Bidirektional zum Zeigen einer UPDATE-Konfliktbehandlung
6.Wiederverwendbar und empfohlen für jede Replikationsumgebung
→ HEARTBEAT-Tabelle zur Replikationsüberwachung
Mit dem Beispiel will ich Personen ohne Vorwissen zu GoldenGate
erfolgreich durch die Konfiguration einer Replikation führen. Beginnend mit den Vorbereitungen in der Datenbank, das schrittweise Einrichten der GoldenGate-Umgebung, das Starten und Stoppen der Prozesse, das Lösen von UPDATE-Konflikten, das Erzeugen
und Anschauen von Reports bis zum Löschen der Umgebung,
wurden alle Themen der Replikation behandelt. Wenn Sie das nach
dem Durcharbeiten des Dojo auch so empfinden, wäre das von mir
avisierte Ziel erreicht, und das Dojo hätte seinen Zweck erfüllt.
SChlusswort
Abschließend noch der Hinweis auf Informationen zum hier
nicht behandelten INITIAL-LOAD und zu den Möglichkeiten des Mappings und der Transformation von Replikationsobjekten auf der Zielseite. Auf unserer Community-Seite
(siehe Punkt 10), die speziell für unsere Kunden im deutschsprachigen Raum gedacht ist, finden Sie Präsentationen,
Beschreibungen und entsprechende Demos zu diesen
beiden Themen.
149
150 Weitere Informationen
Oracle GoldenGate Documentation
Oracle GoldenGate Oracle Installation and Setup Guide Release 11.2.1
http://docs.oracle.com/cd/E35209_01/doc.1121/e35957.pdf
Oracle GoldenGate Windows and Unix Administrator’s Guide 11g
Release 2, Patch Set 1 (11.2.1.0.1)
Oracle GoldenGate Windows and Unix Reference Guide 11g Release 2,
Patch Set 1 (11.2.1.0.1)
Oracle GoldenGate Windows and Unix Troubleshooting and Tuning Guide 11g
Release 2, Patch Set 1 (11.2.1.0.1)
Oracle GoldenGate System Monitoring Plug-in Installation Guide
Release 12.1.0.1.0
http://docs.oracle.com/cd/E24628_01/install.121/e27804.pdf
Oracle GoldenGate Monitor Administrator’s Guide 11g Release 1 (11.1.1.1)
Oracle GoldenGate Director Administrator’s Guide 11g Release 2 (11.2.1)
Oracle GoldenGate Veridata Administrator’s Guide Version 3.0
http://docs.oracle.com/cd/E15881_01/doc.104/gg_veridata_admin.pdf
Weitere Informationen
151
Oracle GoldenGate White Papers
Oracle GoldenGate 11g Release 2 New Features Overview
http://my.oracle.com/site/pd/fmw/products/DI/gg/Datasheets/
cnt1619252.pdf
Oracle GoldenGate 11g: Real-Time Access to Real-Time Information
http://www.oracle.com/us/products/middleware/data-integration/
goldengate11g-realtime-wp-168153.pdf
Zero-Downtime Database Upgrades with Oracle GoldenGate
http://www.oracle.com/technetwork/middleware/goldengate/overview/
ggzerodowntimedatabaseupgrades-174928.pdf
Oracle GoldenGate on Oracle Exadata Database Machine Configuration
http://www.oracle.com/technetwork/database/features/availability/
maa-wp-gg-oracledbm-128760.pdf
Best Practices for Migrating/Upgrading Oracle Database Using
Oracle GoldenGate 11g
http://www.oracle.com/jp/gridcenter/partner/fujitsu/20110627-wpggupgrade-en-423587-ja.pdf
Oracle Technology Network
Oracle GoldenGate on Oracle Technology Network (OTN)
http://www.oracle.com/us/products/middleware/data-integration/
goldengate/index.html
Oracle Support Portal
https://support.oracle.com
(Registrierung erforderlich: → Get Started → Register)
Oracle Learning Library
http://www.oracle.com/goto/oll
(Product Familie: Fusion Middleware → Product: GoldenGate)
Deutsche Oracle Data Integration Community
http://apex.oracle.com/pls/otn/f?p=43477:1
(Global Page → Community Data Integration)
Copyright © 2013, Oracle. All rights reserved. Oracle is a registered
trademark of Oracle Corporation and/or its affiliates. Other names may
be trademarks of their respective owners.
Herausgeber: Günther Stürner, Oracle Deutschland B.V.
Design: volkerstegmaier.de // Druck: Stober GmbH, Eggenstein

Oracle GoldenGate 11gR 2 - Oracle Data Warehouse Community

Transcription

Similar documents

Oracle GoldenGate 12c - Oracle Data Warehouse Community Seite