Oracle GoldenGate 12c - Oracle Data Warehouse Community Seite

Oracle GoldenGate 12c - Oracle Data Warehouse Community Seite

Oracle GoldenGate 12c
- Was ist neu seit 11gR2 ? GoldenGate 12c
Database & Middleware, Oracle 12c Multitenant
GoldenGate 12c für Oracle Datenbanken
Classic & Integrated Capture
Classic & Integrated Apply
GoldenGate 12c für Nicht-Oracle Datenbanken
Classic & Coordinated Apply
GoldenGate 12c - Interessantes
Profile Check Scripts
Healtcheck Scripts
LogDump Utility
Streams2OGG
GoldenGate 12c - Zusatzkomponenten
GoldenGate Foundation Suite
(Monitor, EM Plug-In, Director, Veridata und Studio)
GoldenGate Application Adapers
GoldenGate 12cR2 – Neue Produkte
GoldenGate for Big Data
GoldenGate Studio
(GoldenGate Foundation Suite)
GoldenGate Cloud Service
Neue Monitoring Möglichkeiten
GoldenGate 12cR2 – Neue Funktionen
Meta-Daten im Trail-File
Trail-Files mit 9-Ziffernstellen
Automatische Heartbeat-Table
OGG Parameteranalyse
Automatische Tabellen Instantiierung
GoldenGate 12c - Informationsquellen
1
Inhalt
1. Einleitung
2. Die Stellung von Oracle GoldenGate (OGG)
3. Unterstützung der Oracle 12c Multitenant Architektur
4.
4.1.
4.2.
4.2.1.
4.2.2.
4.2.3.
4.3.
4.3.1.
4.3.2.
4.3.3.
"Classic" für Alle - "Integrated" für Oracle
Architekturübersicht
Integrated Capture für Oracle Datenbanken
Arbeitsweise
Konfiguration
Vorteile
Integrated Apply für Oracle Datenbanken
Arbeitsweise
Konfiguration
Vorteile
5. Coordinated Apply für Nicht-Oracle Datenbanken
5.1. Arbeitsweise
5.2. Unterschiede zu Integrated Apply
6. Wichtige Funktionalitäten
6.1. Profile Check Scripts
6.2. Healthcheck Scripts
6.3. LogDump Utility
6.4. Streams2OGG
7. GoldenGate Foundation Suite
7.1. OGG Enterprise Manager Plug-In und OGG Monitor
7.2. OGG Veridata
7.4. OGG Application Adapters
8.
GoldenGate 12cR2 – Neue Produkte
8.1. GoldenGate for Big Data
8.2. GoldenGate Studio
8.3. GoldenGate Cloud Service (GGCS)
8.4. Neue Monitoring Möglichkeiten
8.4.1. Monitoring Points über RESTful Web Services
8.4.2. Oracle GoldenGate Performance Tool Kit (OGGPTK)
9.
GoldenGate 12cR2 – Neue Funktionen
9.1. Meta-Daten im Trail-File
9.2. Trail-File Namen mit 9 Ziffernstellen
9.3. Automatische Heartbeat-Table
9.3.1. Einrichtung
9.3.2. Nutzung
9.4. OGG Parameteranalyse
9.5. Automatische Tabellen Instantiierung
2
10. GoldenGate - Informationsquellen
10.1. Systemdokumentation
10.2. Datenblätter (Data Sheets)
10.3. White Papers
10.4. Oracle Learning Library
10.5. Oracle Technology Network
10.6. My Oracle Support
10.7. Deutsche Oracle Data Warehouse Community
Anhang 1: Oracle GoldenGate – DBA und Performance Views
Anhang 2: Aktualisierungshinweise zum Dojo 6
3
1. Einleitung
Dieses Dokument ist die Fortsetzung des Dojo 6, das im April 2013 erschien und auf der Version
11gR2 von Oracle GoldenGate basierte. Inzwischen sind schon wieder drei Jahre vergangen und die
Versionen 12cR1 und 12cR2 von Oracle GoldenGate sind verfügbar. Es ist höchste Zeit, den
Leistungsumfang der Version 12c in vollem Umfang und vor allem in deutscher Sprache vorzustellen.
Auch wenn es in seiner Form kein neues Dojo ist, soll der Inhalt in diesem Sinne verstanden werden.
Dabei stehen zwei Aspekte im Vordergrund:
1. Oracle GoldenGate 12c für die Oracle Multitenant Architektur
2. Oracle GoldenGate 12c – Funktionen, Komponenten und Produkte
Im weiteren werde ich für den Produktnamen Oracle GoldenGate auch die Akronyme OGG und GG
verwenden oder nur GoldenGate schreiben. Jeder der dieses Dokument liest, sollte vorher am besten
das Dojo 6 gelesen haben, oder über Grundkenntnisse zu GoldenGate verfügen. Das Dojo 6 steht
sowohl als gedrucktes Heftchen oder auch als PDF-Dokument zum Download bereit. Erwähnen muß
ich an dieser Stelle noch, daß alles, was im Dojo 6 niedergeschrieben wurde, uneingeschränkt gültig
ist und das praktische Beispiel im Teil II "Aktiv-Aktiv -Replikation" jederzeit genau so auch in OGG 12c
konfiguriert werden kann. Im Rahmen der vorhandenen Funktionserweiterungen ergeben sich neue
Möglichkeiten für die Nutzung von Oracle GoldenGate. Was ist dadurch im Dojo 6 nicht mehr
aktuell? Die Antwort darauf gibt der Anhang 2 am Ende dieser Schrift. Dort findet man die
notwendigen Aktualisierungen bzw. Ergänzungen für die Version 12c von OGG.
Oracle GoldenGate ist gegenwärtig in den Versionen 12.1.2.und 12.2.0 verfügbar. Jede OGG Software
Version wird als "Build" bezeichnet. Es existieren somit unterschiedliche Builds für die einzelnen
Plattformen, die durch GoldenGate unterstützt werden. Informationen über eine Software Version
von GoldenGate für eine bestimmte Datenbank auf einem bestimmten Betriebssystem findet man
an mehreren Stellen in Internet. Die wichtigsten drei URLs sind hier aufgeführt und sollten
entsprechend ihrer Aktualität auch in dieser Reihenfolge benutzt werden:
1. Support.oracle.com
2. edelivery.oracle.com
3. www.oracle.com/us/products/middleware/data-integration/goldengate/overview/index.html
Zuerst sind immer die Builds für "Oracle GoldenGate for Oracle" auf Linux x86-64 und auf Solaris x8664 verfügbar. Als nächstes folgt das GoldenGate für Oracle auf MS Windows x86-64 und mit etwas
Verzögerung folgen die Builds für weitere unterstützte Datenbanken auf den unterschiedlichen
Betriebssystemplattformen.
2. Die Stellung von Oracle GoldenGate
Als Einzelkomponente zur Replikation von Daten zwischen heterogenen Systemen und Datenbanken
2009 zugekauft, wurde OGG immer mehr in das Portfolio von Oracle integriert. Zugeordnet wird OGG
der Oracle Middleware Produktlinie. Aber - Oracle GoldenGate ist mittlerweile auch sehr stark in die
Oracle Database integriert. Betrachtet man die Oracle Technologien, sellt man fest, daß GoldenGate
auf Grund seiner Funktionalität eine Zwitterstellung bei Oracle einnimmt. Mit Hilfe der GoldenGate
Replikation lassen sich sowohl im Middleware-Bereich als auch im Database-Umfeld bedeutende
Mehrwerte erzielen. Die Einsatzgebiete von GoldenGate wurden bereits im Dojo 6 aufgeführt. Mit
Freigabe der Version 12c der Oracle Datenbank und der Oracle Middleware Infrastruktur wurden
diese Einsatzmöglichkeiten verfeinert, verbessert und erweitert.
4
Im Oracle Press Release vom 17. Oktober 2013 zur Freigabe von Oracle Data Integrator 12c und
Oracle GoldenGate 12c heißt es dazu:
"With the new capabilities in Oracle GoldenGate 12c, customers can benefit from:
Simplified product depleyment and seamless transition to privat cloud environments via tight Integration with Oracle
Database 12c and support for its multi-tenant architecture. Expanded heterogeneity through added support for he latest
versions of major databases such as Sybase ASE v 15.7, MySQL NDB Clusters 7.2, and MySQL 5.6., as well as integration
with Oracle Coherence. Enhanced high availibilty and data protecion via integration with Oracle Data Guard and Fast
Start Failover integration"
Die Positionierung von Oracle GoldenGate im Middleware und im Database Umfeld zeigen die
Abbildungen 1 und 2:
Abbildung 1: Middleware – Oracle Data Integration Solutions (DIS) Komponenten
Oracle GoldenGate ist neben Oracle Data Integrator (ODI) und Oracle Enterprise Data Quality
(OEDQ) und Oracle Enterprise Metadata Management (OEMM) eine der Hauptkomponenten von
Oracle Data Integration Solutions.
Abbildung 2: Database – Oracle Maximal Availability Architecture (MAA)
5
Oracle unterscheidet vier Stufen steigender Verfügbarkeit einer Datenbankumgebung. In Abbildung 2
sind diese ganz allgemein dargestellt. Im Bronze-Level sichert nur ein Backup die Datenbank. Im
Fehlerfall wird die Ausfallzeit vom Einspielen der Sicherung bestimmt. Um Ausfallzeit zu verringern
bzw. zu verhindern sind die drei weiteren Stufen empfohlen. Diese Level erfordern einen steigenden
Aufwand durch zusätzliche Hard- und Software, garantieren aber auf der anderen Seite die benötigte
höhere Verfügbarkeit. Im Kontext von Oracle realisiert man den Silber-Level mit Real Application
Cluster (RAC), im Gold-Level kommt Data Guard (DG) oder Active Data Guard (ADG) dazu und im
Platin-Level noch GoldenGate (GG).
3. Unterstützung der Oracle 12c Multitenant Architektur
Mit der Oracle 12c stellt Oracle mit Multitenant eine neue Datenbankarchitektur bereit. Bei einer
Multitenant Architektur gibt es eine Container Database (CDB) die eine bis maximal 252 Pluggable
Databases (PDB) unterstützt. Die Pluggable Databases nutzen das Data Dictionary, bestimmte
Tablespaces und Hintergrundprozesse der Container Database gemeinsam. Dadurch werden
Ressourcen (z.B.: Arbeitsspeicher und Plattenplatz) gespart sowie Redundanzen verringert. Ein
weiterer Vorteil entsteht durch das einfache Austauschen von PDBs zwischen verschiedenen CDBs.
Oracle GoldenGate unterstützt ab Version 12.1 die Multitenant Architektur (siehe Abbildung 3).
Weitere Informationen dazu liefert die MyOracle Support Note 1634589.1:
„FAQ - Oracle GoldenGate on Oracle 12c cdb/pdb“.
Abbildung 3: Oracle GoldenGate 12c in einer Oracle Multitenant Database Umgebung
4. "Classic" für Alle - "Integrated" für Oracle
4.1. Architekturübersicht
Oracle GoldenGate besteht aus drei Basisprozessen, dem Capture-, dem (Data)Pump- und dem
Replicat-Prozeß. Capture bezeichnet man auch als Extract und Replicat kann auch Delivery oder
Apply heißen. In Abbildung 4 ist die klassische OGG Architektur dargestellt. Sie war und ist für alle
unterstützten Datenbanken identisch.
6
Abbildung 4: Die klassische Oracle GoldenGate Architektur
Im weiteren werden nur noch die Prozesse mit Kontakt zur Datenbank betrachtet. Für den Pumpoder auch DataPump-Prozeß trifft das nicht zu. Er ist ein optionaler Prozeß, der für die
Datenübertragung von der Quell- zur Zielseite eingesetzt werden kann. Wie schon die Abbildung 4
zeigt, liest und schreibt er nur Trail-Files.
Bei der Übernahme der Firma GoldenGate Software, Inc. existierten für alle unterstützten
Plattformen nur der Classic (klassische) Capture- und der Classic Apply-Prozeß. Der Capture-Prozeß
war nur auf das Erfassen der Änderungen einer speziellen Datenbank ausgerichtet. Diese
Änderungen liest der Classic Capture aus den Log- bzw. Journal-Files der jeweiligen Datenbank. Eine
logische Interaktion mit dem entsprechenden Datenbanksystem fand darüber hinaus nur für
bestimmte Datentypen statt. Auch der Classic Apply generierte nur die den Änderungen
entsprechenden SQL-Anweisungen und führte diese über eine aktive Verbindung zur Zieldatenbank
aus. Transformationen, Fehler- und Konfliktbehandlungen werden dabei ausschließlich durch den
Apply-Prozeß realisiert. Datenbankfunktionalität wurde durch den Apply-Prozeß nicht genutzt.
Der Grund für den Zukauf von GoldenGate war die Leistungsfähigkeit im heterogenen Umfeld. Im
Gegensatz zu Oracle Streams, das nur zwischen Oracle Datenbanken einsetzbar ist, konnte man jetzt
zwischen (fast) allen wichtigen Datenbanken replizieren. Diese Situation führte bei Oracle zu den
folgenden drei Entscheidungen:
1. Oracle GoldenGate ist ab sofort die strategische Replikationslösung von Oracle
2. Oracle Streams 11gR2 wird nicht weiterentwickelt ("Function Freeze")
3. Bewährte Oracle Streams Funktionen werden in OGG für Oracle übernommen ("Best of Both")
Hinweis:
Informationen dazu liefert das Oracle - GoldenGate Statement of
Direction vom August 2015. Gegenwärtig ist Oracle Streams im
Status "Deprecated". Das ist die Vorstufe von "Desupported" und
bedeutet, daß es in absehbarer Zeit nicht mehr Bestandteil der
Oracle Datenbank sein wird. Alle Nutzer sind deshalb aufgefordert,
ihre Replikationslösungen auf Oracle GoldenGate umzustellen.
Abbildung 5: Datenbank und GoldenGate Entwicklung - "Alles aus einer Hand"
7
Ergebnisse der "Best of Both" OGG Weiterentwicklung (analog Streams):
11.2: Neue Standard-Konflikterkennung und -behebung (CDR - Conflict Detection and Resolution)
11.2: Register Capture-Prozeß in Quelldatenbank (RMAN löscht keine Redologs, die OGG benötigt)
11.2: Oracle-spezifischer Capture-Prozeß (Integrated Capture)
12.1: Oracle-spezischer parallelisierter Apply-Prozeß (Integrated Apply)
12.1: Paralleler Apply-Prozeß für alle Datenbanken (Coordinated Apply)
Informationen zu den ersten beiden neuen Funktionen findet man im Dojo 6. Ich werde hier deshalb
nur die neuen Prozesse beschreiben.
Abbildung 6: OGG - Integrated Capture und Integrated Apply für die Oracle Datenbank
4.2. Integrated Capture
4.2.1. Arbeitsweise
Integrated Capture und Integrated Apply basieren auf EXtended Stream (XStream) und nutzen
dessen Outbound Server (Capture) bzw. Inbound Server (Apply) Funktionalität. XStream ist ein neues
leistungsfähiges Interface, das ab Oracle 11.2 mit der Datenbank verfügbar ist und im Rahmen der
Oracle GoldenGate Lizenz genutzt werden kann. Das Oracle White Paper "Building Highly Scalable
Web Applications with XStream" erklärt in kurzer übersichtlicher Form die Funktionsweise von
XStream.
Hinweis:
Anwendungsentwickler können das dokumentierte XStream API
(Application Programming Interface) zur Erstellung eigener
Anwendungen nutzen.
Im Gegensatz zum Classic Capture liest der Integrated Capture die Oracle Redolog Files nicht direkt.
Er nutzt dazu den LogMiner. Dieser arbeitet auf der Grundlage des Data Dictionary und baut sich
beim ersten Start ein Abbild davon auf. Der LogMiner kann so die Redolog Informationen
interpretieren und dem Capture Prozeß übergeben. Der XStream Outbund Server erstellt Logical
Change Records (LCRs) und übergibt diese zur weiteren Verarbeitung an den Capture-Prozeß.
Hinweis:
Oracle Streams und XStream bilden auf der Grundlage der Oracle
Redolog Informationen Logical Change Records (LCRs). GoldenGate
benutzt dafür Trail-File Records. Bei Integrated Capture und
Integrated Apply werden beide Formate benutzt, weil diese neuen
GoldenGate Prozesse eine Kombination aus XStream und GoldenGate
Funktionalität sind.
8
Abbildung 7: Oracle GoldenGate Integrated Extract Architektur
Ab OGG Version 12.1.2.1 können mehrere Integrated Capture-Prozesse das gleiche Data Dictionary
Abbild benutzen (Shared Mining Dictionary). Dadurch können zusätzliche Capture-Prozesse schneller
gestartet werden. Jeder Integrated Capture-Prozeß muß in der Datenbank registriert werden. Danach
ist er (wie der Name schon sagt) in die Logik der Datenbank integriert und arbeitet eng mit ihr
zusammen. Über Dictionary Views findet eine ständige Abstimmung zwischen der Datenbank und
dem GoldenGate Prozeß statt. Mit Version 11.2.0.4 wurde der Integrated Capture weiter verbessert
und noch performanter. Man spricht deshalb auch vom "Lightweight Capture" (V2).
Der Integrated Capture läuft im Normalfall auf der Quelldatenbank. Man bezeichnet ihn deshalb als
Source Capture. Ist das aber für eine Produktions-Datenbank aus Gründen der Belastung nicht
gewünscht, kann er auch auf eine andere Datenbank ("Mining Database") ausgelagert werden. Diese
Arbeitsweise bezeichnet man als Downstream Capture. Mittels Downstream Capture kann man auch
eine Oracle Datenbank der Version 10.2 als Quelle benutzen, wenn die Mining Database mindestens
Version 11.2.0.3 hat. Die Konfiguration von Downstream Capture ist aufwendiger, weil man eine
zusätzliche Datenbank benötigt und die Redolog Files zu dieser Datenbank übertragen werden
müssen. Abblildung 8 zeigt die beiden unterschiedlichen Arbeitsweisen.
Abbildung 8: Source Capture (links) und Downstream Capture (rechts)
Mit der Bereitstellung des Integrated Capture ist der Classic Capture für die Oracle Datenbank nicht
mehr relevant. Erweiterungen wie die Unterstützung neuer Datentypen oder Datenbankfunktionalitäten wie Komprimierung (Compression) oder Verschlüsselung (Encryption) werden nur
noch durch Integrated Capture unterstützt. Schon jetzt bietet der Integrated Capture mehr
Möglichkeiten als der Classic Capture (siehe Tabelle 1).
9
Merkmal
Integrated Capture
Classic Capture
Source Capture
Download Capture
Multitenant Database
ja
ja
ja
ja
nein
nein
Tabelle 1: Integrated Capture versus Classic Capture
4.2.2. Konfiguration
Durch die enge Verbindung zur Oracle Datenbank ergeben sich zusätzliche Schritte beim Einrichten
des Integrated Capture-Prozesses. Oracle Datenbank Initialisierungsparameter müssen gesetzt und
und Privilegien in der Datenbank müssen vergeben werden. Erwähnt sei an dieser Stelle nur der
datenbankinterne Streams Pool, dessen Größe von der Anzahl der Integrated Capture-Prozesse
abhängig ist (Parameter: STREAMS_POOL_SIZE). Für die Vergabe der notwendigen Privilegien für
den OGG Administrator existiert in Oracle 12c das DBMS Package DBMS_GOLDENGATE_AUTH. In
Version 11.2.0.x gab es dieses Package noch nicht und man mußte noch das Streams Package
DBMS_STREAMS_AUTH benutzen. Über spezielle Oracle GoldenGate Kommandos und Parameter
wird der Integrated Capture eingerichtet. Vorhandene Classic Capture-Prozesse können sehr einfach
über die Kommandos REGISTER EXTRACT und ALTER EXTRACT ... UPGRADE in Integrated CaptureProzesse gewandelt werden. (siehe Support Note: 1484313.1 - "How to upgrade from GoldenGate
Classic Extract to Integrated Extract"). Auch der Rückweg zum Classic Capture ist gegenwärtig über
UNREGISTER EXTRACT und ALTER EXTRACT ... DOWNGRADE möglich.
Bei Bi-Direktionaler Replikation muß man verhindern, daß die replizierten Änderungen noch einmal
vom Capture-Prozeß der Zielseite erfaßt werden. Passiert das nicht, würden alle replizierten
Transaktionen erneut repliziert werden und ein sogenanntes "Data Looping" auslösen. Beim Classic
Capture verhindert man das auf der Grundlage eines Nutzernamens oder einer Nutzer-ID. Dieses
Verhalten wurde für den Integrated Capture verändert. Wie schon bei Oracle Streams praktiziert,
wird dieses Ausschließen replizierter Änderungen durch das Setzen eines Kennzeichens (auch TAG
genannt) realisiert. Voraussetzung ist dabei, daß der Apply-Prozeß der Zieldatenbank alle
verarbeiteten Änderungen mit diesem TAG kennzeichnet. Der Integrated Capture ignoriert dann alle
Transaktionen, die damit markiert sind. Standardmäßig schreibt der Apply-Prozeß immer den TAG
"00". Abbildung 9 zeigt die notwendige Parametrisierung mittels TAG "99".
Abbildung 9: Verhindern von "Data Looping" durch setzen eines TAGs
10
Konfiguriert man Integrated Capture für die Datenbankversion 11.2 dann müssen diese beiden
Support Notes beachtet werden:
1411356.1 - "11.2.0.3 Database Specific Bundle Patches for Integrated Extract 11.2.x"
1557031.1 - "Oracle GoldenGate - Oracle RDBMS Server Recommended Patches"
Integrated Capture
Parameter: TRANLOGOPTIONS Option: INTEGRATEDPARAMS ...
Legt fest, ob der LogMining Server im Real-Time oder
DOWNSTREAM_REAL_TIME_MINE Archived-Log Mode (Standard) arbeitet.
GETCTASDML
Erlaubt Replikation von "Create table as Select" Funktionalität
INLINE_LOB_OPTIMIZATION
Legt fest, ob LOBs (kleine LOBs) direkt in einem LCR gesendet
werden dürfen (Standard: Yes).
Legt den "Shared Memory" für den "LogMining Server" fest
(Standard: 1 GB)
Legt die Anzahl der "LogMining Server" fest (Standard: 2).
Oracle Standard Edition: Parameter muß 1 sein!
MAX_SGA_SIZE
PARALLELISM
Tabelle 2: Parameter für Integrated Capture
4.2.3. Vorteile
Kategorie
Funktionen
Exadata
Exadata Komprimierung (HCC)
Komprimierung
Verteilte Transaktionen
OLTP- und Segment- Komprimierung
XA-RAC, PDML
Real Applications Clusters
(RAC)
Neue Datentypen
Large Objects
Einfacheres RAC Management
Beschreibung
Unterstützung von Exadata
Hybrid Columnar
Compression
Unterstützt XA Transaktionen
von mehreren RAC Knoten
XML und XML Binary
Teilweise oder ganz vom Redolog
gelesen
Redolog Verarbeitung
Unterstützung von 2 Threads
Parallelverarbeitung,
Capture Thread / Consumer Thread
(Multithread Architektur)
Architekturerweiterung
Source und Downstream Capture
Capture-Process kann auf
einer zweiten Datenbank sein
Data Definition Language "Out Of The Box" (Database 11.2.0.4+)
Unterstützt ohne Trigger und
(DDL)
Unterstützung von Tabellen mit
zusätzliche
Column Level Password
Installationsschritte
anderes
Unterstützung von IOT mit MAPPING Index Organized Table (IOT)
Option
Tabelle 3: Vorteile von Integrated Capture
11
Hinweis:
Die in Tabelle 3 erwähnten Funktionen werden durch den Classic
Capture-Prozeß nicht oder nur eingeschränkt unterstützt.
4.3. Integrated Apply
4.3.1. Arbeitsweise
Die bessere Integration des Apply-Prozesses in die Datenbank war auch der Grund für die
Entwicklung von Integrated Apply. Dieser orientiert sich stark an der bewährten Oracle Streams
Architektur, wie in Abbildung 10 zu sehen ist. Der Apply ist hier reine Datenbankfunktionalität. Der
Oracle GoldenGate Apply-Prozeß übergibt nur noch die Änderungen an den Oracle Extended Stream
(XStream) Inbound Server und der führt die eigentlichen Apply Aktivitäten durch.
Abbildung 10: Oracle GoldenGate Integrated Apply Architektur
Die Abbildung 10 zeigt die Bestandteile der Inbound Server Architekur. Der Apply-Prozeß (Delivery)
erstellt aus den Sätzen im OGG Trail-File Logical Change Records und übergibt diese an den Inbound
Server. Der Receiver liest diese LCRs und der Preparer analysiert die Abhängigkeiten zwischen den
Transaktionen, gruppiert diese und stellt die richtige Reihenfolge her. Der Coordinator übergibt die
Transaktionen an die einzelnen Applier und überwacht diese. Konflikt- und Error-Handling wird auch
vom zuständigen Applier durchgeführt. Im Gegensatz zum Erfassen von Änderungen (Capture) auf
der Quelldatenbank sind beim Anwenden der Änderungen in der Zieldatenbank (Apply) mehr
Aktionen durchzuführen. Während ein Capture-Prozeß nur die laufenden Änderungen der Quelle
erfassen und eventuell Transformationen ausführen muß, hat der Apply-Prozeß auf der Zielseite
aufwendigere Aktionen zu realisieren:
1. Änderungen ausführen
2. Konflikte erkennen und lösen
3. Fehlersituationen beheben
Ist das Transaktionsaufkommen hoch, können das pro Sekunde tausende von Operationen sein.
Treten dabei dann auch noch Konflikte auf, müssen diese behandelt werden und der
Ressourcenbedarf des Apply-Prozesses steigt unvorhergesehen weiter an. Konflikte sind dabei
Situationen in denen das ausgeführte SQL zum Fehler führt und abgewiesen wird. Die notwendigen
und von der Anwendungslogik abhängigen Plausibilitätskontrollen müssen durchgeführt werden um
für einen bestimmten Fehler die richtige Lösung zu finden. In der Praxis wird man in den meisten
12
Fällen feststellen, daß der Apply-Prozeß dadurch zeitlich hinter den Capture-Prozeß zurückfällt. Die
Zeitdifferenz zwischen dem Commit auf der Quellseite und dem auf der Zielseite wird dabei immer
größer. Überschreitet diese Verzögerung einen vereinbarten Maximalwert ist sie für Real-Time
Replikation nicht mehr akzeptabel. Abhilfe schafft in so einem Fall die automatische Parallelisierung
des Integrated Apply. In Abhängigkeit der verarbeiteten LCRs werden mehr oder weniger Applier
gestartet. Die Maximalzahl wird dabei durch den Parameter „MAX_PARALLELISM“ vorgegeben. Beim
Classic Apply mußte man diese Parallelisierung über das Parameter File des Apply-Prozesses
konfigurieren. Dabei mußten voneinander abhängige Tabellen vom selben Apply-Prozeß verarbeitet
werden und die Änderungen zu diesen Tabellen mußten im selben Trail-File stehen.
4.3.2. Konfiguration
Classic Apply benutzt für den Start nach einem Abbruch eine Tabelle (Checkpoint Table) in der Oracle
Datenbank, um den richtige Stelle für den Wiederanlauf zu finden. Integrated Apply benötigt eine
solche Tabelle nicht. Wie beim Capture-Prozeß kann man auch einen Classic Apply-Prozeß mittels
ALTER REPLICAT ... INTEGRATED in einen Integrated Apply wandeln. Dazu sollte der Apply-Prozeß
gestoppt werden. Nach der Änderung kann die bisher genutzte Checkpoint Table gelöscht werden,
wenn sie nicht noch von anderen Apply-Prozessen genutzt wird. Geht man den Weg zurück und
ändert man den Apply-Prozeß wieder in NONINTEGRATED muß man zwingend den Name einer
Checkpoint Table mitliefern. Im Gegensatz zu Integrated Capture sollte sich der Integrated Apply
selbst bei der Oracle Datenbank registrieren. Das REGISTER REPLICAT sollte nur dann benutzt
werden, wenn man die Meldung bekommt, daß ein Integrated Apply-Prozeß noch nicht registriert ist.
Integrated Apply
COMMIT_SERIALIZATION
DISABLE_ON_ERROR
EAGER_SIZE
MAX_PARALLELISM
PARALLELISM
WRITE_ALERT_LOG
Parameter: DBOPTIONS Option: INTEGRATEDPARAMS ...
Abhängige Transaktionen werden korrekt "committed", aber
nicht zwingend in der Reihenfolge wie in der Quelldatenbank
(Standard: DEPENDENT_TRANSACTIONS)
Transaktionen in gleicher Reihenfolge wie auf der
Quelldatenbank "committed" (FULL)
Apply Server stoppt nach einem Fehler (Standard: No)
Anzahl der LCRs nach denen der Apply beginnt (Standard:
9500)
Optimitisches Apply!
Legt die maximale Anzahl von Apply Servern fest. Wirkt nur,
wenn PARALLELISM ist größer als 1 (Standard: 50)
Minimale Anzahl von Apply Servern (Standard: 4)
Oracle Standard Edition: Parameter muß 1 sein!
Legt fest, ob der INBOUND Server Nachrichten in das ALERT
Log schreibt (Standard: YES).
Tabelle 4: Parameter für Integrated Apply
13
5. Coordinated Apply
5.1. Arbeitsweise
Der Aufwand für das Apply der Änderungen auf der Zieldatenbank ist unabhängig von der
betrachteten Datenbank immer größer als das Erfassen der Änderungen durch den Capture-Prozeß.
Deshalb wurde speziell für den Apply-Prozeß von Nicht-Oracle Datenbanken der Coordinated Apply
entwickelt. Dieser neue Apply-Prozeß ist wie der Integrated Apply auch ab Oracle GoldenGate 12c
verfügbar und soll den Nutzer von aufwendiger Parametrisierung bei der Definition von parallelen
Apply-Prozessen entlasten.
Abbildung 11: Oracle GoldenGate Coordinated Apply Architektur
Coordinated Apply berücksichtigt sogenannte "Barrier Operations". Das sind SQL-Anweisungen, die
logisch zusammen gehören und nur in einer bestimmten Reihenfolge ausgeführt werden können.
Coordinated Replicat erkennt diese Abhängigkeiten und stoppt einen Thread bis eine vorher
notwendige Datenbankänderung durch einen anderen Thread ausgeführt wurde. Zum Beispiel kann
ein Update oder ein Insert auf eine zusätzliche Spalte in einer Tabelle erst dann ausgeführt werden,
wenn diese Spalte vorher durch eine DDL Anweisung (ALTER TABLE ... ADD Column) erfolgt ist. Ein
weiteres Beispiel ist die Aktualisierung eines Primary Keys. Inserts und Updates, die sich auf den alten
Wert beziehen müssen vor der Änderung des Schlüssels erfolgen.
5.2. Gegenüberstellung: Coordinated Apply - Integrated Apply
Coordinated Apply
Der Nutzer definiert die Anzahl der Threads
Transaktionen werden aufgesplittet
Nutzbar für alle unterstützten Datenbanken
SQL Ausführung durch den Apply-Prozeß
Integrated Apply
Parallelisierung erfolgt automatisch basierend
auf Foreign Keys und Unique Identifier
Transaktionen werden nicht aufgesplittet
Nur für Oracle Datenbank 11.2.0.4 und 12c
SQL Ausführung im Oracle Datenbankserver
Tabelle 5: Coordinated Apply versus Integrated Apply
14
6. Tools & Utilities
6.1. Profile Check Scripts
Wenn man eine Replikation zwischen zwei Datenbanken aufbaut, muß man zuerst prüfen, ob alle
Datentypen der Quelldatenbank durch den Capture-Prozeß unterstützt sind. Gibt es Datentypen, die
der Capture nicht verarbeiten kann, dann muß man nach Umgehungslösungen suchen. Oracle
GoldenGate liefert für diese Analyse der unterstützten Datenbanken Profile Check SQL-Scripts aus. Es
gibt Profile Check Scripts für die Oracle Datenbank, IBM DB2, Microsoft SQL Server, Oracle MySQL
und weitere Datenbanken. Für Oracle gibt es zwei verschiedene Scripts, einen für die Untersuchung
der gesamten Datenbank und einen Script zur Analyse eines einzelnen Schemas. Aber Vorsicht - diese
beiden Scripts sind heute nur noch für den Classic Capture benutzbar. Der Grund dafür sind die
beiden neuen Integrated Prozesse (Capture und Apply) für die Oracle Datenbank. Für diese Prozesse
wurden neue Scripts entwickelt, die neben der Datentyp-Analyse auch die erforderlichen DatenbankParameter und den Status der Integrated Prozesse prüfen. Diese sogenannten Healthcheck Scripts
sind Gegenstand von Punkt 6.2.
Oracle Support Note
Titel
1296168.1
Oracle GoldenGate Database Schema Profile Check Script for Oracle DB
Classic Extract
1298562.1
Oracle GoldenGate Database Complete Database Profile Check Script for
Oracle DB (All Schemas) Classic Extract
1438514.1
Oracle GoldenGate Database Profile Check Script for DB2 Database
1315720.1
Oracle GoldenGate 11g for SQL Server Database Profile Check Script
1944704.1
Oracle GoldenGate 12.1 for SQL Server Database Profile Check Script
1501176.1
Oracle GoldenGate Database Profile Check Script for MySQL Database
Tabelle 6: Oracle GoldenGate Profile Check Scripts für ausgewählte Datenbanken
6.2. Healthcheck Scripts
Wie schon erwähnt gibt es für Integrated Capture und Integrated Apply keine Profile Check Scripts
sondern umfangreichere Healthcheck Scripts. Beide Prozesse sind tief in der Oracle Datenbank
verwurzelt. Informationen zu diesen Prozessen finden sich in erweiterten und neuen DBA und
Perfomance Views. Es ist damit möglich, den Zustand der Prozesse abzufragen und DiagnoseInformationen zu erhalten. Im Anhang 1 ist eine Zusammenstellung dieser Views zu finden. Um den
GoldenGate Nutzer bei der Analyse der GoldenGate Prozesse zu unterstützen, stellt Oracle (wie
schon bei Oracle Streams) SQL-Scripts bereit, die alle relevanten Informationen übersichtlich in
einem HTML-File darstellen. Diese Scripts werden als Healthcheck Scripts bezeichnet und sind
versionsabhängig. Informationen dazu liefert der Oracle Support Note 1448324.1: "GoldenGate
Integrated Capture and Integrated Replicat Healthcheck Script". Gegenwärtig sind diese 4 Versionen
von Healthcheck Scripts verfügbar:
15
Name
Beschreibung
ogg_12102.sql
Integrated Capture and Integrated Replicat Health Check sccript for Oracle Database 12.1.0.2
ogg_12101.sql
Integrated Capture and Integrated Replicat Health Check sccript for Oracle Database 12.1.0.1
ogg_11204.sql
Integrated Capture and Integrated Replicat Health Check sccript for Oracle Database 11.2.0.4
ichc_11203.sql
Integrated Capture Health Check sccript for Oracle Database 11.2.0.3
Tabelle 7: Oracle GoldenGate Healthcheck Scripts
Die Scripts werden mit jeder neuen Oracle GoldenGate bzw. Oracle Datenbankversion aktualisiert
und spiegeln damit den aktuellen Funktionsumfang wider.
Abbildung 12: Teil eines Healthcheck Reports
Abbildung 12 zeigt einen Ausschnitt aus einem Healthcheck Report. Zu sehen sind ein Integrated
Capure (Integrated Extract) EXCDB12P und ein Integrated Apply (Integrated Replicat) REPDB12S.
Beide Prozesse laufen in einer Oracle 12c Multitenant Database. Der Capture-Prozeß ist mit der
Container Database (CDB) verbunden und der Apply-Prozeß mit einer Pluggable Database (PDB). Zu
sehen ist auch der Outbound Server-Prozeß (LogMiner Session) des Integrated Capture-Prozesses.
6.3. LogDump Utility
Oracle GoldenGate beinhaltet ein sehr hilfreiches Programm zur Analyse der in den Trail-Files
gespeicherten Sätze (Trail-File Records). Seit Version 12 ist dieses Utility in der Schrift "Logdump
Reference for Oracle GoldenGate 12c" beschrieben. Bis Version 11.2 war es noch im Kapitel 4 des
16
Troubleshooting Guide zu finden. Zusätzlich gibt es noch die Oracle Support Note 1446672.1 "Oracle GoldenGate Logdump Complete Reference FAQ".
Das Programm befindet sich im Installationsverzeichnis von GoldenGate und wird über Kommandos
gesteuert (Command Line Tool). Abbildung 13 zeigt ein Beispiel für die Nutzung des Programms:
D:\ogg1212_tar>logdump
Oracle GoldenGate Log File Dump Utility for Oracle
Version 12.1.2.0.0 17185003 OGGCORE_12.1.2.0.0_PLATFORMS_130924.1316
Copyright (C) 1995, 2013, Oracle and/or its affiliates. All rights reserved.
Logdump 588 >open d:\ogg1212_tar\dirdat\rt000020
Current LogTrail is d:\ogg1212_tar\dirdat\rt000020
Logdump 589 >count
LogTrail d:\ogg1212_tar\dirdat\rt000020 has 5082 records
Total Data Bytes
570356
Avg Bytes/Record
112
RestartOK
1
Others
1
After Images
5081
Average of 5082 Transactions
Bytes/Trans .....
160
Records/Trans ...
1
Files/Trans .....
1
Logdump
Logdump
Logdump
Logdump
Logdump
590
591
592
593
594
>ghdr on
>detail on
>detail data
>usertoken on
>next
2014/10/08 10:14:16.420.000 FileHeader
Name: *FileHeader*
3000 0319 3000 0008 4747 0d0a 544c 0a0d
0004 3200 0004 2000 0000 3300 0008 02f2
7ea0 3400 0037 0035 7572 693a 4a4a 5434
653a 6f72 6163 6c65 3a63 6f6d 3a64 7269
3a6f 6767 3132 3132 5f73 7263 3a45 5843
5036 0000 2000 1e64 3a5c 6f67 6731 3231
725c 6469 7264 6174 5c72 7430 3030 3032
Len
3100
2b18
3230
7665
4442
325f
3037
0002
5ba2
3a64
2d44
3132
7461
0000
|
|
|
|
|
|
|
1396 RBA 0
0...0...GG..TL..1...
..2... ...3.....+.[.
~.4..7.5uri:JJT420:d
e:oracle:com:drive-D
:ogg1212_src:EXCDB12
P6.. ..d:\ogg1212_ta
r\dirdat\rt0000207..
Logdump 595 >
Abbildung 13: Oracle GoldenGate Logdump Utility - Beispiel
Nach dem Start des Programmes wird das Trail-File "d:\ogg1212_tar\dirdat\rt000020" geöffnet und
mittels "count" wird die Anzahl der Sätze ermittelt. Danach wird festgelegt, welcher Inhalt des TrailFiles ausgegeben bzw. analysiert werde soll. Diese Optionen können bei Bedarf jederzeit geändert
werden. Mit "next" positioniert man auf den nächsten Satz. Der erste Record im File ist immer der
File Header. Ist "ghdr on" angegeben, wird er auch angezeigt. Die Kommandos "detail on", "detail
data" und "usertoken on" vergrößern die Ausgabe für jeden Trail Record. Ob diese Informationen
gebraucht werden ist abhängig von der Situation die eine Analyse der Records notwendig macht.
Klappt zum Beispiel die Konflikterkennung nicht kann man nachsehen, ob das Before Image eines
bestimmten Spaltenwertes im Trail Record vorhanden ist. Ist es nicht vorhanden, hat man bestimmt
Parameter auf der Quellseite falsch gesetzt. Mit dem Programm kann man Sätze überspringen, auf
den Inhalt von Sätzen positionieren und Filter für die Satzauswahl setzen. Erwähnt sei an dieser Stelle
noch die Möglichkeit, einem User Token einen Wert zuzuweisen. Damit können über User Tokens
zusätzliche Daten in die Trail Records geschrieben werden. Diese Möglichkeit nutzt man um
Informationen von der Quell- zur Zielseite zu transportieren. Dort können deren Inhalte zu
Transformationen benutzt oder als Werte in Zieltabellen eintragen werden. Mittels LogDump kann
17
man überprüfen, ob die Token auch wirklich im Trail Record vorhanden sind. Abbildung 14 zeigt das
Funktionsprinzip der User Tokens:
Abbildung 14: Oracle GoldenGate - User Tokens
Im Beispiel unten (Tabelle 8) wird ein GoldenGate Trail Record durch das Einfügen der User Tokens
um insgeamt 152 Bytes vergrößert (Capture-Prozeß: plus 96 Bytes, Pump-Prozeß plus 56 Bytes).
Im LogDump Utility wird das so angezeigt:
Trail Record nach Capture-Prozeß
2013/06/07 11:52:00.000.000 FieldComp
Name: HBUSER.HB_TAB_ORAP
After Image:
0001 0008 0000 0004 6f72 6170 000f 001f
3133 2d30 362d 3037 3a31 313a 3532 3a30
3130 3030 3030 30
Column
1 (x0001), Len
8 (x0008)
0000 0004 6f72 6170
Column
15 (x000f), Len
31 (x001f)
0000 3230 3133 2d30 362d 3037 3a31 313a
302e 3731 3130 3030 3030 30
User tokens:
96 bytes
544b 5f45 5854 4e41 4d45 0045 5854 4842
5f45 5854 5449 4d45 0032 3031 332d 3036
3131 3a35 323a 3030 2e39 3938 3030 3000
4444 4c44 454c 5441 5354 4154 5300 3000
444d 4c44 454c 5441 5354 4154 5300 3100
Len
47 RBA 1284
Partition 4
GU s
0000 3230 | ........orap......20
302e 3731 | 13-06-07:11:52:00.71
| 1000000
| ....orap
3532 3a30 | ..2013-06-07:11:52:0
| 0.711000000
5000
2d30
544b
544b
544b
3720
5f45
5f45
|
|
|
|
|
TK_EXTNAME.EXTHBP.TK
_EXTTIME.2013-06-07
11:52:00.998000.TK_E
DDLDELTASTATS.0.TK_E
DMLDELTASTATS.1.
Trail Record nach Pump-Prozeß
2013/06/07 11:52:00.000.000 FieldComp
Name: HBUSER.HB_TAB_ORAP
After Image:
0001 0008 0000 0004 6f72 6170 000f 001f
3133 2d30 362d 3037 3a31 313a 3532 3a30
3130 3030 3030 30
Column
1 (x0001), Len
8 (x0008)
0000 0004 6f72 6170
Column
15 (x000f), Len
31 (x001f)
0000 3230 3133 2d30 362d 3037 3a31 313a
302e 3731 3130 3030 3030 30
User tokens: 152 bytes
544b 5f50 4d50 4e41 4d45 0050 4d50 4842
5f50 4d50 5449 4d45 0032 3031 332d 3036
3131 3a35 323a 3336 2e37 3433 3030 3000
5854 4e41 4d45 0045 5854 4842 5000 544b
5449 4d45 0032 3031 332d 3036 2d30 3720
323a 3030 2e39 3938 3030 3000 544b 5f45
454c 5441 5354 4154 5300 3000 544b 5f45
454c 5441 5354 4154 5300 3100
Len
47 RBA 1401
Partition 4
GU s
0000 3230 | ........orap......20
302e 3731 | 13-06-07:11:52:00.71
| 1000000
| ....orap
3532 3a30 | ..2013-06-07:11:52:0
| 0.711000000
5000
2d30
544b
5f45
3131
4444
444d
544b
3720
5f45
5854
3a35
4c44
4c44
|
|
|
|
|
|
|
|
TK_PMPNAME.PMPHBP.TK
_PMPTIME.2013-06-07
11:52:36.743000.TK_E
XTNAME.EXTHBP.TK_EXT
TIME.2013-06-07 11:5
2:00.998000.TK_EDDLD
ELTASTATS.0.TK_EDMLD
ELTASTATS.1.
Tabelle 8: LogDump Utility mit "usertoken on"
6.4. Streams2OGG
Dieses Programm analysiert eine vorhandene Oracle Streams Installation und erstellt alle
notwendigen Kommando- und Parameter-Dateien für Oracle GoldenGate. Da Oracle Streams nur
noch eine begrenzte Zeit Bestandteil der Oracle Datenbank sein wird, empfielt Oracle allen Streams
Anwendern, in Richtung GoldenGate zu migrieren. Streams2OGG soll dabei eine Unterstützung für
alle Oracle Kunden sein, die laufende Streams-Umgebungen durch OGG ablösen wollen. Das
Programm wurde erstmals 2014 auf der Oracle Open World in San Francisco der Öffentlichkeit
vorgestellt. Seitdem existiert auf My Oracle Support die Note 1912338.1. Neben speziellen Hinweisen
zum Programm findet man den Link zum Download der Dokumentation "Documentation for Streams
18
to GoldenGate Migration Tool". Eine weitere, schon etwas ältere Note 1383303.1 wurde aktualisiert
und sollte ebenfalls mit beachtet werden, wenn eine Migration von Streams zu GoldenGate geplant
ist bzw. durchgeführt werden soll. Über diese zweite Note bekommt man das Oracle White Paper
"Best Practice: Oracle Streams to Oracle GoldenGate Conversion".
Note
Inhalt
1383303.1
Prozeß Migration: OS  OGG
GoldenGate Installation
Installation Migration Utility streams2ogg
Stop Oracle Streams Apply-Prozeß (Zielsystem)
Ermitteln der letzten SCN (Last applied transaction)
Start Oracle GoldenGate Replicat (Zielsystem)
Stop Oracle Streams Capture (Quellsystem)
De-Installation Oracle Streams (Quell- und Zielsystem)
1912338.1
Migration Utility: streams2ogg
Installation des Database Packages
Package Funktionen: MAIN und CUSTOMIZE
Analyse der Oracle Streams Konfiguration
Ergebnis-File: ogg_name_map.csv
Optional: Editieren des Ergebnis-Files
Aufbau der Oracle GoldenGate Kommando-Files
Aufbau der Oracle GoldenGate Parameter-Files
Tabelle 9: Oracle Support Notes zur Migration von Streams zu GoldenGate
7. Oracle GoldenGate Foundation Suite
Die OGG Foundation Suite existiert erst ab GoldenGate Version 12.2. Unter diesem Name hat man
jetzt eine neue und zwei bereits existierende Zusatzkomponenten zusammengefaßt:
1. OGG Studio (neu mit Version 12.2)
2. OGG Management Pack
- Enterprise Manager Plug-In
- Monitor
- Director
3. OGG Veridata
Mit der Lizensierung der Foundation Suite ist man berechtigt, alle drei aufgeführten Produkte zu
nutzen. Zum besseren Verständnis noch ein paar weiterführende Erklärungen. OGG Studio ist erst ab
OGG Version 12.2 verfügbar und kann nicht als Einzelkomponente lizensiert werden. Es wird unter
Punkt 8.2 näher beschrieben. Management Pack und Veridata existieren schon seit Version 11 von
GoldenGate und sind im Dojo 6 beschrieben. Beide Komponenten kann der Kunde auch einzeln
erwerben. Mit dem Management Pack stellt Oracle eine grafische Oberfläche für die Konfiguration,
das Überwachen und Steuern der GoldenGate Prozesse bereit.
Die Validierungskomponente heißt GoldenGate Veridata. Mit dieser Software kann man Objekte der
Quelldatenbank mit Objekten der Zieldatenbank vergleichen. Man stellt dabei fest, ob beide
Datenbestände noch konsistent sind. Beide Komponenten werden in einem Installationsfile
19
bereitgestellt. Hat man beide Lösungen lizenziert sollte man auch beide gleichzeitig installieren. Das
spart Zeit, ist übersichtlicher und wird später noch angesprochen.
7.1. GoldenGate Monitor und Enterprise Manager Plug-In
Abbildung 15: GoldenGate Monitor und Enterprise Manger (Plug-In) Architektur
Der GoldenGate Director wird in dieser Schrift nicht mehr erwähnt. Er ist nur noch notwendig, wenn
die "Uralt-Version" 10.4 von GoldenGate verwendet wird. Diese sollte aber heute niemand mehr
einsetzen. In den drei Jahren zwischen Dojo 6 und dieser Beschreibung sind das Plug-In und der
Monitor funktional stark erweitert worden. Das heißt, die Funktionen des GoldenGate Director sind
jetzt auch im Plug-In und im Monitor vorhanden. Der funktionelle Umfang des Plug-In entspricht
dabei dem vom OGG Monitor nur die grafischen Darstellungen weichen voneinander ab. Monitor
und EM Plug-In arbeiten mit identischen Java Agents. Einen EM Agent benötigt man nur in
Verbindung mit der Nutzung des Enterprise Managers Plug-In. Die Installation ist mit Version 12.1.3
aufwendiger geworden. Der Monitor und Veridata wurden in die "Oracle Fusion Middleware
Infrastructure 12c (12.1.3)" integriert. Zu dieser Infrastruktur gehören Oracle Coherence und der
WebLogic Server. Bevor man also Monitor und Veridata installieren und nutzen kann, muß die
Infrastruktur existieren. Man benötigt weiterhin eine Java JDK in der Version 1.7.0.15 oder höher und
eine Repository Datenbank. Diese kann Oracle (11gR1, 11gR2 oder 12c), oder Microsoft SQL Server
(2008 oder 2012) sein. Es ist sinnvoll und erspart Zeit, wenn man beide Komponenten (Monitor und
Veridata) gemeinsam in eine WebLogic Server Domain installiert. Das betrifft auch die GoldenGate
Agents für den Monitor und die für Veridata. Man muß zuerst die richtigen Installationsdateien
finden und die Installationshandbücher genau ansehen. Die Installation der Version 12.1.3 habe ich
in einer Windows-Umgebung auf meinem Laptop durchgeführt und die einzelnen Schritte in diesen
drei Dokumenten beschrieben:
1. "Experiences with OGG Monitor 12c under Windows7, Part One - Installation and Startup"
2. "Experiences with OGG Monitor 12c under Windows7, Part Two - Monitoring"
3. "WebLogic Server - OGG Domain under Windows7,
Startup and Shutdown Admin Server and Managed Servers"
20
Alle drei Dokumente sind in Englisch geschrieben und unter dem Link im Punkt 10.7 zu finden. Zu
beachten ist, daß die aktuellste Version zur Zeit schon 12.2.1 ist. Da der Monitor mit all seinen neuen
Funktionen im zweiten der aufgeführten Beschreibungen ausführlich behandelt wird, möchte ich an
dieser Stelle nicht weiter darauf eingehen. Voraussetzung für jede Art des Monitorings ist der
Parameter „ENABLEMONITORING“ in der Parameterdatei „GLOBALS“. Die Nutzung dieses
Parameters erfordert eine Lizensierung des Management Packs oder der Foundation Suite. Das gilt
auch für die unter Punkt 8.4. aufgeführten zusätzlichen Monitoring Möglichkeiten.
7.2. GoldenGate Veridata
Abbildung 16: Oracle GoldenGate Veridata - Architektur
Oracle Veridata ist eine Komponente zum Datenvergleich zwischen Quell- und Zieldatenbank. Dabei
arbeitet Veridata parallel zur GoldenGate Replikation und erzeugt nur eine geringe Systemlast. Es ist
auch für heterogene Umgebungen einsetzbar, in denen Quell- und Zieldatenbank unterschiedlich
sind. Ab Version 12.1.3 beinhaltet Veridata auch eine "Repair" Funktion. Mit deren Hilfe ist es
möglich, Differenzen bzw. Inkonsistenzen zwischen Quell- und Zieldaten regelbasierend zu
korrigieren. Veridata berücksichtigt dabei definierte Verzögerungszeiten (Replication Latency
Thresholds), die durch die Replikationsprozesse entstehen. Wie die Architektur in Abbildung 16 zeigt,
muß in der Quell- und in der Zielumgebung ein Veridata Agent laufen. Die Agenten erhalten Aufträge
in Form von Jobs. Ein Veridata Job verarbeitet ein oder mehrere Vergleichspaare (Compare Pairs), die
vom Veridata Nutzer definiert wurden. Jeder Agent ist mit der jeweiligen Datenbank verbunden und
liefert die zu einem Compare Pair gehörenden Datensätze an den Veridata Server. Dieser vergleicht
dann beide Datenbestände und stellt einen Ergebnis-Report bereit. Die Aufbereitung der Resultate
erfolgt in Tabellen und in grafischer Form.
7.3 GoldenGate Application Adapters
GoldenGate repliziert im klassischen Sinne zwischen relationalen Datenbanken. Dabei werden
Transaktionen auf der Quelldatenbank erfaßt und in einer Zieldatenbank nochmal ausgeführt. Mit
den OGG (Java) Application Adaptern hat man zusätzliche Möglichkeiten geschaffen, Daten zwischen
unterschiedlichen Systemen auszutauschen, z.B.: Lesen von oder Schreiben von Transaktionsdaten in
Java Message Service Queues oder das Schreiben von Transaktionsdaten in Flat-Files. Alle Adapter
21
sind Java Programme die als Vendor Access Module oder User Exits mit einem Capture-Prozeß
zusammenarbeiten.
Seit Version 11 von GoldenGate existieren die folgenden Java Application Adapter:
1. GoldenGate Message Capture Adapter for JMS (Vendor Access Module – VAM)
2. GoldenGate Message Delivery Adapter for JMS (User Exit – UE)
3. GoldenGate Message Delivery Adapter for Flat-File (User Exit – UE)
Abbildung 17: Oracle GoldenGate JMS Messages Capture Adapter
Abbildung 18: Oracle GoldenGate JMS Messages Delivery Adapter
Abbildung 19: Oracle GoldenGate Message Delivery Adapter for Flat-File
Es ist zu beachten, daß der Message Delivery Adapter auf der Zielseite mit einem GoldenGate Extract
Prozeß zusammen arbeitet. Das Liefern der Daten (Delivery) übernimmt dann der entsprechende
Java User Exit. Das ist beim OGG Flat File Adapter (Abbildung 19) genau so. Inhalt der durch den Flat
File Adapter erstellten Dateien sind entweder durch Trennzeichen separierte Daten oder
längenbegrenzte Daten. Im Control File sind alle gegenwärtig aktiven Ergebnisdateien verzeichnet.
22
Der Message Delivery Adapter erzeugt Daten im XML Format oder „mapped“ die Ergebnisdaten über
JMS.
Es gibt noch einen weiteren Java Adapter für GoldenGate, den Hotcache Coherence Adapter. Dieser
ermöglicht die Synchronisation des Coherence Cache Inhaltes mit dem Inhalt der Oracle Datenbank.
Ein White Paper zu diesem Adapter und ein Installationsbeispiel finden Sie unter dem Link im Punkt
10.7.
8. GoldenGate 12cR2 – Neue Produkte
8.1. GoldenGate for Big Data
Abbildung 20: Oracle GoldenGate for Big Data 12cR2
Mit Version 12c gibt es mit Oracle GoldenGate for Big Data ein neues Produkt. GoldenGate for Big
Data ist eine Java Lösung zur Echtzeit (Real-Time) Belieferung von Big Data Systemen. Unterstützt
werden Big Data Lösungen wie Apache Hadoop, Apache HBASE, Apache Hive und Apache Flume. Mit
Version 12cR2 ist noch Kafka hinzugekommen. OGG for Big Data ist neben dem Oracle Data
Integrator (ODI) 12c eine Schlüsselkomponente der Oracle Big Data Integration. OGG for Big Data
beinhaltet auch GoldenGate for Java mit dem es möglich ist, JMS Provider wie beispielsweise
ActiveMQ zu integrieren. Durch die Arbeit in Real-Time sorgt OGG for Big Data für aktuellste Daten in
den „Big Data Reservoirs“ bzw. „Big Data Lakes“. Oracle GoldenGate for Big Data dient in
Kombination mit dem klassischen GoldenGate als End-to-End Plattform für Datenreplikation
zwischen heterogenen Systemen. GoldenGate for Big Data wird an dieser Stelle nicht ausführlicher
beschrieben. Die Architektur und die Vielzahl der unterstützten Systeme sollten Gegenstand eines
zusätzlichen Dokumentes sein.
23
8.2. GoldenGate Studio
Abbildung 21: GoldenGate Studio - Startbild
Anfang des Jahres 2016 wurde mit Version 12.2 das OGG Studio von Oracle freigegeben. OGG Studio
ist Bestandteil der Foundation Suite (siehe Punkt 7) und bietet eine grafisches Nutzeroberfläche,
über die man schnell und übersichtlich eine Replikationslösung konfigurieren kann, ohne das man
Kenntnisse der GoldenGate Replikationsprozesse und deren Parametrisierung hat. OGG Studio ist
eine Middleware Komponente und arbeitet wie auch der OGG Monitor und OGG Veridata auf der
Grundlage eines Datenbank Repository. Jeder OGG Studio Nutzer benötigt deshalb einen Connect
zur Repository Datenbank. Wie üblich arbeitet man auch auf dieser grafischen Oberfläche mit
Projekten. Ein Projekt beinhaltet eine oder mehrere Solutions denen Mappings zugeordent werden.
Mit anderen Worten gesagt, innerhalb eines Projektes werden die beteiligten Datenbanken, die
Replikationswege und die Replikationsobjekte logisch definiert und als Solutions und Mappings
abgelegt. Eine Solution ist dabei eine Replikationsstrecke und ein Mapping legt fest, welche
Datenbank-Schematas oder Einzelobjekte repliziert werden sollen. Unterstützt wird der Nutzer dabei
durch sogenannte „Wizards“ (Expertenunterstützung) und „Best Practices Templates“ (vorbereitete
Replikationszenarien). Das heißt, die möglichen GoldenGate Replikations-Topologien, wie z. B. UniDirektional, Bi-Direktional und Hub & Spoke, brauchen nur noch ausgewählt werden und OGG Studio
sorgt im Hintergrund für die benötigten GoldenGate Prozesse und deren Konfiguration. Der Nutzer
kann dabei zwischen Online und Offline Konfiguration auswählen. Online bedeutet, die Replikation
wird konfiguriert und die Replikationsprozesse werden sofort gestartet. Die Offline Konfiguration
erstellt alle benötigten Parameter Files und Kommando Files (OBEY Files) und der Nutzer kann sich
diese erst anschauen und eventuelle Änderungen vornehmen.
24
Abbildung 22: GoldenGate Studio – Struktur der Entwicklunsoberfläche
Nachdem das logische Design vorhanden ist werden sogenannte Deployment Profiles definiert. Diese
sorgen dafür, daß ein logisches Design auf die notwendigen physichen Ressourcen abgebildet wird.
Abbildung 23: GoldenGate Studio – OGG Solution „Tokyo to New York”
25
8.3. GoldenGate Cloud Service (GGCS)
Seit März 2016 gibt es den ersten Oracle GoldenGate Cloud Service (GGCS) „On-Premise to Cloud“.
Alle weiteren geplanten GGCS werden in Kürze auch verfügbar sein. Informationen dazu findet man
unter cloud.oracle.com/goldengate. Funktionell gibt es keinen Unterschied zwischen einem OnPremise Service und einem Cloud Service.
Abbildung 24: Verfügbarkeit der Oracle GoldenGate Cloud Services
8.4. Neue Monitoring Möglichkeiten
Jede Art von Monitoring erfordert die Angabe von ENABLEMONITORING in der Parameterdatei
GLOBALS. Für die Nutzung dieses Parameters ist eine Lizeznz für das Management Pack bzw. für die
Foundation Suite erforderlich (siehe Punkt 7.1.).
8.4.1. Monitoring Points über RESTful Web Services
Unter dem Begriff “Extended Metrics“ stellt Oracle GoldenGate ab Version 12.2. RESTful Web
Services zum Überwachen der Replikationsprozesse bereit. Im Gegensatz zum GoldenGate Monitor
sind dafür keine Installationschritte erforderlich. Der Zugriff auf diese Informationen ist sehr einfach
über Browser möglich. Über die Angabe des Rechnername (oder der IP-Adresse) und des ManagerPorts können alle Angaben zu einer GoldenGate Instanz sichtbar gemacht werden:
26
HTTP – Adresse
http://<hostname>:<mgr_port>/registry
http://<hostname>:<mgr_port>/groups
groups/<name>
http://<hostname>:<mgr_port>/messages
http://<hostname>:<mgr_port>/statuschanges
http://<hostname>:<mgr_port>/mpoints
mpointsx
Anzeige
Augenblicklicher Zustand der
Prozesse
Prozeß und
Prozeßinformationen
ggserr.log Meldungen
Alle Prozeß-Statusänderungen
Einen Prozeß anzeigen
Alle Prozesse anzeigen
Tabelle 10: Monitoring Points ab OGG 12.2.
Abbildung 25: Monitoring Points für Extract Prozeß E1NO121P
27
Weitere Infos
über Link
Nein
Ja
Nein
Nein
Ja
Abbildung 26: Monitoring MPOINTSX für Integrated Replicat Prozeß R_NO121P
8.4.2. Oracle GoldenGate Performance Tool Kit (OGGPTK)
Im Rahmen eines Open Source Projektes wurde das OGG Performance Toolkit entwickelt. Das
Programm ist ab Version 12.2. nutzbar und steht unter diesem Link zum Download bereit:
https://java.net/projects/oracledi/pages/OracleGoldenGate
Voraussetzung für die Nutzung sind:
1. GGSCI-Kommando: CREATE DATASTORE
2. Parameter: ENABLEMONITORING in Datei: GLOBALS
3. Restart der OGG Prozesse (Manager, Extract und Replicat)
Aufgerufen wird das Programm über das Kommando: java -jar OGGPTK.jar
Abbildung 27: Monitoring über Java Tool OGGPTK.jar
28
9. GoldenGate 12cR2 – Neue Funktionen
9.1. Meta-Daten im Trail-File
Haben die zu replizierenden Tabellen auf der Quell- und Zielseite eine identische Struktur teilt man
das über den Parameter „ASSUMETARGETDEFS“ dem Replikationsprozeß mit. Wenn nicht, dann muß
man der Zielseite die Struktur der Quelltabelle mitteilen. GoldenGate nutzt dazu ein sogenanntes
„Source Definition File“. Dieses Datei wird mit dem OGG Programm DEFGEN auf der Quell-Instanz
erstellt und dann zur OGG Ziel-Instanz kopiert. Dem Replikationsprozeß wird der Name dieser Datei
mittels Parameter „SOURCEDEFS“ übergeben. Mit Hilfe der in der Datei vorhandenen Informationen
kann die Replikation unter Beachtung der Unterschiede wie gewünscht durchgeführt werden. Mit
OGG 12.2 ist dieser Aufwand nicht mehr nötig, weil das GoldenGate Trail-File die Struktur des Quellobjektes automatisch beinhaltet. Man bezeichnet das Trail-File vom Format 12.2 deshalb als selbstbeschreibendes Trail-File. Damit sind beiden erwähnten Parameter nicht mehr notwendig und ein
„Source Definition File“ wird auch nicht mehr benötig. Das vereinfacht die Konfiguration der
Replikationsprozesse und macht sie weniger fehleranfällig.
Abbildung 28: Selbst-beschreibendes Trail-File ab Version 12.2
Das Trail-File beinhaltet ab OGG Version 12.2 zusätzlich „Metadata Records“. Das sind Database
Definition Records (DDR) und Table Definition Records (TDR). Ein DDR enthält Informationen über
den Zeichensatz der Datenbank (Database Character Set), die Zeitzone (Time Zone) und über die
Kleinschreibung von Objektnamen (Object name case-sensitive). Der erste TDR zu einer Tabelle
beinhaltet Tabellen- und Spalteninformationen. Ein Folgesatz zur gleichen Tabelle ist ein
Referenzsatz und wird als „Ref TDR“ bezeichnet. Er besteht nur aus einem Satzkopf (Record Header)
und verweist auf den bereits vorhandenen TDR mit Informationen zur Struktur der Tabelle.
Über den Parameter “NO_USE_TRAILDEFS” im Parameter File “GLOBALS” kann man in einer OGG
Instanz weiterhin mit „SOURCEDEFS“ und „ASSUMETARGETDEFS“ arbeiten. Will man nur teilweise
nach der alten Methode arbeiten nutzt man die Parameter „SOURCEDEFS OVERRIDE“ und
„ASSUMETARGETDEFS OVERRIDE“.
29
9.2. Trail-File Namen mit 9 Ziffernstellen
Trail-File Namen bestanden bisher aus zwei Alphazeichen und sechs Ziffern. Für jedes neue Trail-File
wird die sechstellige Ziffer um eins erhöht. Damit konnten bis zu 999.999 Trail-Files erstellt werden,
bevor die Nummerierung wieder bei eins begann. Mit Version 12.2. von GoldenGate wurde der
numerische Teil des Names von sechs auf neun Ziffernstellen erweitert. Damit sind jetzt eine
Milliarde Trail-Files möglich (vorher 1 Million).
OGG Version
10, 11, 12.1
12.2+
Trail-File Namen
AA999999
(1 – 999.999)
AA999999999 (1 – 999.999.999)
Tabelle 11: Namensformat der Trail-Files
Die Verwendung des neuen Formats ist empfohlen, aber nicht zwingend. Mit dem Parameter
„TRAIL_SEQLEN_6D“ in der Paramaterdatei „GLOBALS“ kann die Nutzung von sechsstelligen Trail-File
Nummern gewählt werden (Parameter „TRAIL_SEQLEN_9D“ ist der Standard).
Die Umstellung auf das neue Format erfolgt nach dem ordnungsgemäßen Stoppen des ExtractProzesses mittels des Konvertierungsprogramms CONVCHK für alle vorhandenen Trail-Files:
CONVCHK <extract_name> <trail_path> seqlen_9d [-force]
9.3. Automatische Heartbeat-Table
9.3.1. Einrichtung
Zur Überwachung einer Replikation wurde schon immer eine sogenannte Heartbeat-Table bzw. eine
Herzschlagtabelle empfohlen. Das war schon bei Oracle Streams so und ist bei Oracle GoldenGate
nicht anders. Wie funktioniert eine solche Tabelle? In jeder an der Replikation beteiligten Datenbank
wird eine Tabelle mit zwei Spalten definiert. Die erste Spalte beinhaltet den globalen Name der
Datenbank (Primary Key) und die zweite Spalte beinhaltet die aktuelle Zeit. In der Tabelle erstellt
man für jede an der Replikation beteiligte Datenbank einen Datensatz. Bei einer bi-direktionalen
Replikation sind das auf beiden Seiten 2 Datensätze (Rows), einer für die primäre und einer für die
sekundäre Datenbank. Die Herzschlagtabelle bezieht man in beiden Datenbanken in jede laufende
Replikation ein. In einem empfohlenen Zeitintervall von 60 Sekunden aktualisiert man in jeder
Heartbeat-Table den Zeitwert in Spalte zwei. Dabei aktualisiert man aber immer nur die Row, bei der
der Primary Key mit dem Global Name der Datenbank übereinstimmt. Die laufende Replikation sorgt
dann dafür, daß auf der Zieldatenbank die Row mit dem entsprechenden Primary Key in wenigen
Sekunden die aktuelle Zeit beinhaltet. Wird der Wert nicht mehr zeitnah aktualisiert, ist das ein
Zeichen dafür, daß es Probleme bei der Replikation gibt.
Hinweis:
Zum besseren Verständnis sind Aufbau und Inhalt einer
Heartbeat-Table im Dojo 6 ausführlich beschrieben.
30
Eine Neuerung der Version 12.2 von GoldenGate ist die automatische Heartbeat-Table. Über das
Kommando „ADD HEARTBEATTABLE“ werden automatisch alle erforderlichen Datenbankobjekte
(Tabellen, Views, Procedures und Scheduler Jobs) erstellt. Das Kommando erfordert ein Login in die
Oracle Datenbank (DBLOGIN). Bei Nutzung der Multitenant Architektur ist das immer eine PDB. Es
können die Parameter „FREQUENCY“, „RETENTION_TIME“ und „PURGE_FREQUENCY“ angegeben
werden:
Parameter
FREQUENCY
RETENTION_TIME
PURGE_FREQUENCY
Standardwert
Bedeutung
60 Sekunden
30 Tage
Aktualisierungsintervall der Heartbeat-Table
Löschen von Einträgen der HeartbeatHistory-Table die älter sind.
Häufigkeit mit der der Purge Job die
verfallenen Einträge in der HeartbeatHistory-Table löscht.
1 Tag
Tabelle 12: Parameter für das Einrichten einer automatischen Heartbeat-Table
Objekt
Heartbeat-Table
Heartbeat-Seed-Table
Heartbeat-History-Table
GoldenGate Lag
GoldenGate History Lag
Update Procedure
Purge Procedure
Update Job
Purge Job
Typ / Inhalt
Standard Name
Tabelle (1 Zeile)
Tabelle (1 Zeile)
Tabelle (n Zeilen)
View
(1 Zeile)
View (n Zeilen)
Procedure
Procedure
Job
Job
hbschema.GG_HEARTBEAT
hbschema.GG_HEARTBEAT_SEED
hbschema.GG_HEARTBEAT_HISTORY
hbschema.GG_LAG
hbschema.GG_HISTORY_LAG
hbschema.GG_UPDATE_HB_TAB
hbschema.GG_PURGE_HB_TAB
hbschema.GG_UPDATE_HEARTBEATS
hbschema.GG_PURGE_HEARTBEATS
Tabelle 13: Datenbankobjekte für die Unterstützung einer automatischen Heartbeat-Table
Mit dem Parameter „GGSCHEMA hbschema“ in der Datei „GLOBALS“ gibt man das Schema an, unter
dem die Datenbankobjekte erstellt werden sollen.
Die Parameter „ENABLE_HEARTBEAT_TABLE“ bzw. „DISABLE_HEARTBEAT_TABLE“ können im
Parameter File „GLOBALS“ oder im Parameter File eines Extract- oder Replicat-Prozesse gesetzt
werden. „ENABLE_HEARTBEAT_TABLE“ ist der Standard wenn nichts angegeben wurde. Mit
„DISABLE_HEARTBEAT_TABLE“ kann man die Nutzung einer automatischen Heartbeat-Table
verhindern. In der Regel wird man die Herzschlagtabelle für alle Prozesse einer GoldenGate Instanz
nutzen, das heißt, man wird keine Prozesse gezielt ausschließen.
Mit dem GGSCI Kommando „INFO HEARTBEATTABLE“ kann man überprüfen, ob die automatische
Heartbeat-Table für die GoldenGate Instanz bereits konfiguriert ist:
GGSCI (JJAENSCH-T450) 6> info heartbeattable
ERROR: Not logged into database, use DBLOGIN.
GGSCI (JJAENSCH-T450) 7> dblogin userid oggadmin@noc121p password OGGADMIN
Successfully logged into database.
GGSCI (JJAENSCH-T450 as oggadmin@noc121p) 8> info heartbeattable
HEARTBEAT table OGGADMIN.GG_HEARTBEAT exists.
HEARTBEAT table OGGADMIN.GG_HEARTBEAT_SEED exists.
HEARTBEAT table OGGADMIN.GG_HEARTBEAT_HISTORY exists.
31
Frequency interval: 60 seconds.
Purge frequency interval: 1 days.
Retention time: 30 days.
...
Abbildung 29: Ausgabe des Kommandos: INFO HEARTBEATTABLE
9.3.2. Nutzung
Nach dem Einrichten der Herzschlagtabelle erkennt diese automatisch alle aktiven Replikationswege
und liefert dafür die Heartbeat Informationen. Es wird dabei nach Richtungen unterschieden. Ist die
Datenbank das Ziel einer Replikation (Replicat-Prozeß), dann spricht man von einer eingehenden
(Incoming) Verbindung. Ist die Datenbank der Startpunkt für einen Replikationsweg (Extract-Prozeß)
handelt es sich um eine ausgehende (Outgoing) Verbindung. Für jede Richtung beinhaltet der Eintrag
in der Heartbeat-Table die folgenden Werte:
1. Verzögerungszeit (Lag or Lag Time)
2. Alter des letzten Eintrages in der Heartbeat-Table (Age of last Heartbeat)
3. Namen der Lokalen (local) und der Entfernten (remote) Datenbank
Abbildung 30: Verzögerungszeiten im View: GG_LAG (Outgoing und Incoming)
Für die Abfrage des Inhaltes der Herzschlagtabelle ist ein Connect zur Datenbank notwendig. Ist man
nicht mit der Datenbank verbunden, liefert das Kommando „LAG <process_name>“ nur den zweiten
Teil der Ausgabe:
(1. Teil)
GGSCI (JJAENSCH-T450 as oggadmin@noc121s) 11> lag r_no121s
Lag Information From Heartbeat Table
LAG
4.35s
2.81s
AGE
39.08s
58.53s
FROM
NOC121P
NOC121S
TO
NOC121S
NOC121P
32
PATH
E1NO121P ==> P1NO121P ==> R_NO121S
E1NO121S ==> P1NO121S ==> R_NO121P
(2. Teil)
Sending GETLAG request to REPLICAT R_NO121S ...
Last record lag 4 seconds.
Low watermark lag: 13.
High watermark lag: 5.
Low watermark position: 2809689.
High watermark position: 2809711.
At EOF, no more records to process.
Abbildung 31: Nachrichten des Kommandos: LAG R_NO121S
9.4. OGG Parameteranalyse
Die GoldenGate Prozesse Extract, Pump und Replicat werden über Parameter konfiguriert bzw.
gesteuert. Mit OGG Version 12.2 werden drei neue Funktionen bereitgestellt, die dem Administrator
helfen, Parameter sichtbar zu machen und Fehler bei der Parametrisierung der einzelnen Prozesse zu
erkennen:
GGSCI Kommando / Programm
Erklärung
INFO PARAM <parameter_name>
Information über einen bestimmten Parameter
SEND <process_name> GETPARAMINFO
Anzeige der Parameter eines aktiven Prozesses
Programm: CHECKPRM
Prüfen aller Parameter eines OGG Prozesses
Tabelle 14: Möglichkeiten der Parameteranalyse
D:\gg122o_src>ggsci
Oracle GoldenGate Command Interpreter for Oracle
Version 12.2.0.1.0 OGGCORE_12.2.0.1.0_PLATFORMS_151101.1925.2
Windows x64 (optimized), Oracle 12c on Nov 10 2015 21:56:24
Operating system character set identified as windows-1252.
Copyright (C) 1995, 2015, Oracle and/or its affiliates. All rights reserved.
GGSCI (JJAENSCH-T450) 1> info param LOGALLSUPCOLS
param name : logallsupcols
opposite
param name : nologallsupcols
description : For supplementally logged columns this automatically includes in the
trail record the before image for UPDATE operations before image of
all supplementally logged columns for both UPDATE and DELETE
operations. It will also log columns required to support CDR and
Integrated Replicat.
argument
: boolean
default
: true
options
:
component(s): EXTRACT
mode(s)
: all Extract modes
platform(s) : all platforms
versions
:
min ver : 12.1.2
database(s) : Oracle 8
Oracle 9i
Oracle 10g
Oracle 11g
33
status
mandatory
dynamic
relations
:
:
:
:
Oracle 12c
current
false
false
none
param name : logallsupcols
opposite
param name : nologallsupcols
description : For supplementally logged columns this automatically includes in the
trail record the before image for UPDATE operations before image of
all supplementally logged columns for both UPDATE and DELETE
operations. It will also log columns required to support CDR and
Integrated Replicat.
argument
: boolean
default
: false
options
:
component(s): EXTRACT
mode(s)
: all Extract modes
platform(s) : all platforms
versions
:
min ver : 12.1.2
database(s) : Generic
Sybase
DB2LUW 10.5
DB2LUW 10.1
DB2LUW 9.5
DB2LUW 9.7
DB2 Remote
Timesten
Timesten 7
Timesten 11.2.1
MySQL
Ctree8
Ctree9
DB2 for i
DB2 for i Remote
MS SQL
Informix
Informix1150
Informix1170
Informix1210
Ingres
SQL/MX
DB2 z/OS
PostgreSQL
status
: current
mandatory
: false
dynamic
: false
relations
: none
Abbildung 32: Nachrichten des GGSCI Kommandos: INFO PARAM LOGALLSUPCOLS
Für die Abfrage von untergeordneten Parameter (Subparameters) müssen die übergeordneten
Parameter mit angegeben werden. Die Trennung der einzelnen Paramater erfolgt dabei über einen
Punkt. Das folgende Kommando zeigt, wie es richtig gemacht wird:
GGSCI (JJAENSCH-T450) 11> info param dboptions.integratedparams.max_parallelism
param name :
description :
argument
:
default
:
pattern :
options
:
component(s):
mode(s)
:
platform(s) :
versions
:
min ver :
database(s) :
integratedparams.MAX_PARALLELISM
string
50
([0-9]{1,10})
REPLICAT
Integrated Replicat
all platforms
12.1.2
Oracle 11g
34
status
mandatory
dynamic
relations
:
:
:
:
Oracle 12c
current
false
false
none
Abbildung 33: Kommando: INFO PARAM DBOPTIONS.INTEGRATEDPARAM.MAX_PARALLELISM
GGSCI (JJAENSCH-T450) 10> send e1no121p getparaminfo
Sending GETPARAMINFO request to EXTRACT E1NO121P ...
GLOBALS
enablemonitoring
walletlocation
allowoutputdir
allowoutputdir
enableheartbeat
heartbeat_table
trail_seqlen_9d
ggschema
:
:
:
:
:
:
:
:
<enabled>
.\dirwal
d:\gg122aa_tar\dirdat
d:\gg122o_tar\dirdat
<enabled>
GG_HEARTBEAT
<disabled>
OGGADMIN
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
e1no121p
oggadmin@NOC121P
*******
./dirdat/NOC121P/aa
<enabled>
5 minute(s)
<enabled>
1 hour(s)
30 minute(s)
<enabled>
COMPACT
<enabled>
<enabled>
"TSTSTR"."STR_HEARTBEAT"
<enabled>
<enabled>
<enabled>
00
TSTSTR.STR_HEARTBEAT
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
<enabled>
D:\gg122o_src\dirprm\E1NO121P.prm
extract
userid
password
exttrail
reportcount
every
rate
warnlongtrans
checkinterval
logallsupcols
updaterecordformat
ddl
include
objname
ddloptions
report
tranlogoptions
excludetag
table
Default Values
deletelogrecs
fetchoptions
userowid
usekey
missingrow
usesnapshot
uselatestversion
maxfetchstatements
usediagnostics
detaileddiagnostics
diagnosticsonall
nosuppressduplicates
flushsecs
passthrumessages
ptkcapturecachemgr
ptkcaptureift
ptkcapturenetwork
ptkcapturequeuestats
ptkspstats
tcpsourcetimer
tranlogoptions
bufsize
asynctransprocessing
checkpointretentiontime
failovertargetdestid
<enabled>
<enabled>
ALLOW
<enabled>
<enabled>
100
<disabled>
<disabled>
<disabled>
<enabled>
1
<enabled>
<enabled>
<enabled>
<enabled>
<enabled>
<enabled>
<enabled>
1024000
300
7.000000
0
35
getctasdml
minefromsnapshotstby
usenativeobjsupport
retrydelay
allocfiles
allowduptargetmap
binarychars
checkpointsecs
cmdtrace
dynamicresolution
eofdelay
eofdelaycsecs
functionstacksize
numfiles
ptkcapturetablestats
ptkmaxtables
ptktablepollfrequency
varwidthnchar
ptkcaptureprocstats
ptkmonitorfrequency
use_traildefs
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
<disabled>
<disabled>
<enabled>
60
500
<disabled>
<enabled>
10 second(s)
OFF
<enabled>
1
100
200
1000
<enabled>
100
1
<disabled>
<enabled>
1
<enabled>
Abbildung 34: Nachrichten des GGSCI Kommandos: SEND E1NO121P GETPARAMINFO
GGSCI (JJAENSCH-T450) 9> send r_no121p getparaminfo
Sending GETPARAMINFO request to REPLICAT R_NO121P ...
GLOBALS
enablemonitoring
walletlocation
allowoutputdir
allowoutputdir
enableheartbeat
heartbeat_table
trail_seqlen_9d
ggschema
:
:
:
:
:
:
:
:
<enabled>
.\dirwal
d:\gg122aa_tar\dirdat
d:\gg122o_tar\dirdat
<enabled>
GG_HEARTBEAT
<disabled>
OGGADMIN
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
r_no121p
(NLS_LANG)
oggadmin@NOC121P
*******
<enabled>
./dirrpt/r_no121p.dsc
<enabled>
500
<enabled>
5 minute(s)
<enabled>
<enabled>
00
<enabled>
<enabled>
<enabled>
<enabled>
"TSTSTR"."STR_HEARTBEAT"
<enabled>
<enabled>
<enabled>
<enabled>
"TSTSTR"."STR_HEARTBEAT"
"TSTSTR"."STR_HEARTBEAT"
( ON UPDATE ALL, ON DELETE ALL)
( UPDATEROWEXISTS, (DEFAULT, OVERWRITE))
D:\gg122o_src\dirprm\R_NO121P.prm
replicat
getenv
userid
password
assumetargetdefs
discardfile
purge
megabytes
reportcount
every
rate
dboptions
settag
suppresstriggers
deferrefconst
ddl
include
objname
ddloptions
notag
updatemetadata
report
map
target
comparecols
resolveconflict
Default Values
allownoopupdates
applynoopupdates
: <disabled>
: <disabled>
36
auditreps
deferapplyinterval
grouptransops
maxdiscardrecs
maxsqlstatements
ptkcapturebatchsql
ptkirstatsfrequency
restartcollisions
retrydelay
warnrate
allocfiles
allowduptargetmap
binarychars
checkpointsecs
cmdtrace
dboptions
limitrows
reparselobsql
skiptemplob
dynamicresolution
eofdelay
eofdelaycsecs
functionstacksize
numfiles
ptkcapturetablestats
ptkmaxtables
ptktablepollfrequency
varwidthnchar
ptkcaptureprocstats
ptkmonitorfrequency
use_traildefs
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
<enabled>
0 second(s)
50
0
250
<enabled>
10
<disabled>
60
100
500
<disabled>
<enabled>
10 second(s)
OFF
<enabled>
<disabled>
<enabled>
<enabled>
1
100
200
1000
<enabled>
100
1
<disabled>
<enabled>
1
<enabled>
Abbildung 35: Nachrichten des GGSCI Kommandos: SEND R_NO121P GETPARAMINFO
D:\gg122o_src>checkprm dirprm\e1no121p.prm
(e1no121p.prm) line 11: Parameter [LOGALLSUPCOL] is unrecognized and will be ignored.
No parameter definition with that name could be found.
2016-05-19 11:49:42 INFO OGG-10139 Parameter file dirprm\e1no121p.prm: Validity check: FAIL.
D:\gg122o_src>checkprm dirprm\p1no121p.prm
2016-05-19 11:50:01 INFO OGG-10139 Parameter file dirprm\p1no121p.prm: Validity check: PASS.
Runtime parameter validation is not reflected in the above check.
D:\gg122o_src>checkprm dirprm\r_no121p.prm
2016-05-19 11:50:16 INFO OGG-10139 Parameter file dirprm\r_no121p.prm: Validity check: PASS.
Runtime parameter validation is not reflected in the above check.
Abbildung 36: Nachrichten des Programms CHECKPRM für drei Parameterdateien
Der Fehler in der Parameterdatei E1NO121P.PRM wurde gezielt eingebaut um die Reaktion des
Programmes CHECKPRM zu zeigen.
9.5. Automatische Tabellen Instantiierung
Bei einer homogenen Oracle Replikation stehen für die Erstbefüllung (Initial-Load) der ZielDatenbank mehrere Möglichkeiten zur Verfügung. Diese können sein Create Table as Select (CTAS),
ein RMAN Backup, Export / Import oder besser DataPump Export / Import. Alle diese Methoden
gestatten die Angabe der Oracle System Change Number (SCN), das heißt die Daten sind konsistent
und der Startpunkt für die Replikation der Änderungen ist durch die SCN eindeutig festgelegt. Bisher
mußte man die aktuelle SCN vor dem Kopieren der Daten abfragen und dem Oracle Tool beim Start
37
mitgeben (siehe Dojo 6, Punkt 2.7.). Mit Oracle GoldenGate 12.2 und Oracle Datenbank 12.1.0.2
wurde die automatische Tabellen Instantiierung für DataPump Export / Import eingeführt. Damit
entfällt die Angabe der SCN beim Erstellen der Datenkopie und jede Tabelle hat ihre eigene SCN.
Nach dem Initial-Load auf der Zieldatenbank filtert der Replicat-Prozeß auf der Basis der SCN für jede
einzelne Tabelle die Transaktionen, die repliziert werden müssen.
Abbildung 37: Ablauf der automatischen Tabellen Instantiierung
38
10. GoldenGate - Informationsquellen
10.1. Systemdokumentation
Oracle GoldenGate Oracle Installing and Configuring Oracle GoldenGate for Oracle 12c (12.2.0.1)
http://docs.oracle.com/goldengate/c1221/gg-winux/GIORA/GIORA.pdf
Oracle GoldenGate Administering Oracle GoldenGate for Windows and UNIX 12c (12.2.0.1)
http://docs.oracle.com/goldengate/c1221/gg-winux/GWUAD/GWUAD.pdf
Oracle GoldenGate Reference for Oracle GoldenGate for Windows and UNIX 12c (12.2.0.1)
http://docs.oracle.com/goldengate/c1221/gg-winux/GWURF/GWURF.pdf
Oracle Fusion Middleware Installing Oracle GoldenGate Studio 12c (12.2.1)
http://docs.oracle.com/goldengate/s1221/gg-studio/INGGT/INGGT.pdf
Oracle Fusion Middleware Using Oracle GoldenGate Studio 12c (12.2.1)
http://docs.oracle.com/goldengate/s1221/gg-studio/GGSUG/GGSUG.pdf
Oracle Enterprise Manager Oracle GoldenGate System Monitoring Plug-In Installation Guide 13c (13.1.1)
https://docs.oracle.com/goldengate/em1311/gg-emplugin/EMGGP/E68921-01.pdf
Oracle GoldenGate Enterprise Manager Plug-In Release Notes 13c (13.1.1.0.0)
https://docs.oracle.com/goldengate/em1311/gg-emplugin/GEMRN/E69610-01.pdf
Oracle GoldenGate Installing and Configuring Oracle GoldenGate Monitor 12c (12.2.1)
http://docs.oracle.com/goldengate/m1221/gg-monitor/GMINS/GMINS.pdf
Oracle GoldenGate Installing, Configuring and Upgrading Oracle GoldenGate Monitor Agent 12c (12.2.1)
http://docs.oracle.com/goldengate/m1221/gg-monitor/GGAIN/GGAIN.pdf
Oracle GoldenGate Administering Oracle GoldenGate Monitor 12c (12.2.1)
http://docs.oracle.com/goldengate/m1221/gg-monitor/GMNAD/GMNAD.pdf
Oracle GoldenGate Using Oracle GoldenGate Monitor 12c (12.2.1)
http://docs.oracle.com/goldengate/m1221/gg-monitor/GMNCH/GMNCH.pdf
Oracle GoldenGate Installing and Configuring Oracle GoldenGate Veridata 12c (12.2.1)
http://docs.oracle.com/goldengate/v1221/gg-veridata/GVDIS/E60969-01.pdf
Oracle GoldenGate Administering Oracle GoldenGate Veridata 12c (12.2.1)
http://docs.oracle.com/goldengate/v1221/gg-veridata/GVDAD/E60970-01.pdf
10.2. Datenblätter (Data Sheets)
Oracle GoldenGate
http://www.oracle.com/us/products/middleware/data-integration/oracle-goldengate-ds-2030490.pdf
Oracle GoldenGate for Big Data
http://www.oracle.com/us/products/middleware/data-integration/goldengate-for-big-data-ds-2415102.pdf
Oracle Management Pack for Oracle GoldenGate
http://www.oracle.com/us/products/middleware/data-integration/goldengate/059449.pdf
Oracle GoldenGate Veridata
http://www.oracle.com/us/products/middleware/059493.pdf
Oracle GoldenGate Application Adapters
http://www.oracle.com/us/products/middleware/data-integration/goldengate/goldengate-app-adapters-1449776.pdf
Oracle GoldenGate Studio
http://www.oracle.com/technetwork/middleware/goldengate/overview/ds-oggstudio-12-2-1-0-2868485.pdf
Oracle GoldenGate Cloud Service
https://cloud.oracle.com/_downloads/Datasheet_GoldenGate_1/Oracle_GoldenGate_Cloud_Service_DataSheet.pdf
10.3. White Papers
Transparent Zero Data-Loss Role Transition with Oracle Data Guard and Oracle GoldenGate
http://www.oracle.com/technetwork/database/availability/maa-consolidation-2186395.pdf
Oracle Goldengate With Oracle Real Application Clusters Configuration
http://www.oracle.com/technetwork/database/features/availability/maa-goldengate-rac-2007111.pdf
Ensuring Data Consistency with Oracle GoldenGate Veridata
http://www.oracle.com/us/products/middleware/data-integration/data-consistency-with-gg-veridata-1975236.pdf
39
10.4. Oracle Learning Library
http://www.oracle.com/goto/oll (Product Familie: Fusion Middleware  Product: GoldenGate)
10.5. Oracle Technology Network
Oracle GoldenGate on Oracle Technology Network (OTN)
http://www.oracle.com/us/products/middleware/data-integration/goldengate/index.html
10.6. Oracle Support Portal
https://support.oracle.com (Registrierung erforderlich:  Get Started  Register)
10.7. Oracle Data Warehouse Community
http://www.oracledwh.de/downloads/14_Oracle_Data_Integration/Data_Integration_Solutions_start.html
40
Anhang 1: Oracle GoldenGate DBA und Performance Views
Name
Beschreibung
DBA_GG_INBOUND_PROGRESS
Infos zum Verarbeitungsstand aller GoldenGate
Inbound- Server in der Datenbank
DBA_GOLDENGATE_INBOUND
Infos über alle GoldenGate Inbound-Server in der
Datenbank
DBA_GOLDENGATE_PRIVILEGES
Detaillierte Infos über die GoldenGate Privilegien
DBA_GOLDENGATE_RULES
Infos über alle GoldenGate Server Rules in der
Datenbank
DBA_GOLDENGATE_SUPPORT_MODE
Infos zum GoldenGate Capture Support der Tabellen in
der Datenbank
V$GG_APPLY_COORDINATOR
Infos über jeden GoldenGate Apply-Process Coordinator
(Integrated Apply)
V$GG_APPLY_READER
Infos über jeden GoldenGate Apply Reader
(Integrated Apply)
V$GG_APPLY_RECEIVER
Infos über den Message Receiver des Apply-Prozesses
V$GG_APPLY_SERVER
Infos über jeden GoldenGate Apply Server und seine
Aktivitäten (Integrated Apply)
V$GOLDENGATE_CAPTURE
V$GOLDENGATE_MESSAGE_TRACKING
Infos über jeden Capture-Prozeß, der LCRs an den
GoldenGate Outbound Server sendet (Integrated
Capture)
Infos über verfolgte ("tracked") LCRs auf ihrem Weg von
der Quell- zur Zieldatebank
V$GOLDENGATE_TABLE_STATS
Statistische Infos über alle Tabellen die von jedem
GoldenGate Apply Server genutzt werden
V$GOLDENGATE_TRANSACTION
Infos über Transaktionen, die vom GoldenGate CaptureProzeß, dem Outbound Server und dem Inbound Server
verarbeitet werden
Tabelle 1: Oracle GoldenGate (Static) DBA Views und (Dynamic) Performance Views
Hinweis:
Es existieren auch DBA... und V$... Views für den Oracle LogMiner
und für Oracle XStream.
Alle DBA... und V$... Views findet man in der Database Reference 12c.
41
Anhang 2: Aktualisierungshinweise zum Dojo 6
Inhalt
Dojo 6
Neu in OGG 12c
OGG Nutzung voll integriert in ODI Studio
Unterstützung E-Business Suite & ATG Web
Integration mit ADG
Unterstützt Oracle Cloud Konzept
Einsatzgebiete
Punkt 2.2
Unterstützte Plattformen
Punkt 2.3
Oracle 12c Multitenant
DB2 System i
Informix Dynamic Server (IDS)
Installation
Punkt 2.4
Für "OGG for Oracle" kann Oracle Universal Installer
genutzt werden
(Richtige OGG Version wird automatisch gewählt.)
Unterverzeichnisse
Punkt 2.4
Capture, Extract
Punkt 2.5.3
Für "OGG for Oracle" kann Integrated Capture
verwendet werden (ab 11.2.0.4, In Dojo 6 nur kurz
erwähnt und hier ausführlich beschrieben
Trail-Files
Punkt 2.6
(siehe auch Punkt 4!)
Beinhalten jetzt Source Character Set und die
Source Time Zone (NLS_LANG entfällt!)
Apply, Delivery
Punkt 2.7
Für "OGG for Oracle" kann Integrated Apply
verwendet werden
Hier ausführlich beschrieben
dircrd - Credential Store Files
dirdmp - Trace or Dump Files
Tabelle 1: Korrekturen im Dojo 6
München, 01. Juni 2016
Joachim Jaensch
Principal Sales Consultant
[email protected]
[email protected]
42