1

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

2

Inhalt

1. Einleitung

2. Die Stellung von Oracle GoldenGate (OGG)

3. Unterstützung der Oracle 12c Multitenant Architektur

4. "Classic" für Alle - "Integrated" für Oracle 4.1. Architekturübersicht 4.2. Integrated Capture für Oracle Datenbanken 4.2.1. Arbeitsweise 4.2.2. Konfiguration 4.2.3. Vorteile 4.3. Integrated Apply für Oracle Datenbanken 4.3.1. Arbeitsweise 4.3.2. Konfiguration 4.3.3. 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

3

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

4

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 x86-64 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.

5

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)

6

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.

7

Abbildung 4: Die klassische Oracle GoldenGate Architektur Im weiteren werden nur noch die Prozesse mit Kontakt zur Datenbank betrachtet. Für den Pump- oder 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"

8

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.

9

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 Datenbank-funktionalitä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).

10

Merkmal

Integrated Capture

Classic Capture

Source Capture ja ja

Download Capture ja nein

Multitenant Database

ja 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 Capture- Prozesse 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

11

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 ...

DOWNSTREAM_REAL_TIME_MINE

Legt fest, ob der LogMining Server im Real-Time oder 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).

MAX_SGA_SIZE Legt den "Shared Memory" für den "LogMining Server" fest (Standard: 1 GB)

PARALLELISM

Legt die Anzahl der "LogMining Server" fest (Standard: 2). Oracle Standard Edition: Parameter muß 1 sein!

Tabelle 2: Parameter für Integrated Capture

4.2.3. Vorteile

Kategorie

Funktionen

Beschreibung

Exadata Exadata Komprimierung (HCC) Unterstützung von Exadata Hybrid Columnar Compression

Komprimierung OLTP- und Segment- Komprimierung

Verteilte Transaktionen XA-RAC, PDML Unterstützt XA Transaktionen von mehreren RAC Knoten

Real Applications Clusters (RAC)

Einfacheres RAC Management

Neue Datentypen XML und XML Binary

Large Objects Teilweise oder ganz vom Redolog gelesen

Redolog Verarbeitung Unterstützung von 2 Threads Capture Thread / Consumer Thread

Parallelverarbeitung, (Multithread Architektur)

Architekturerweiterung Source und Downstream Capture Capture-Process kann auf einer zweiten Datenbank sein

Data Definition Language (DDL)

"Out Of The Box" (Database 11.2.0.4+)

Unterstützung von Tabellen mit Column Level Password

Unterstützt ohne Trigger und zusätzliche Installationsschritte

anderes Unterstützung von IOT mit MAPPING Option

Index Organized Table (IOT)

Tabelle 3: Vorteile von Integrated Capture

12

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

13

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

Parameter: DBOPTIONS Option: INTEGRATEDPARAMS ...

COMMIT_SERIALIZATION

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)

DISABLE_ON_ERROR Apply Server stoppt nach einem Fehler (Standard: No)

EAGER_SIZE Anzahl der LCRs nach denen der Apply beginnt (Standard: 9500) Optimitisches Apply!

MAX_PARALLELISM Legt die maximale Anzahl von Apply Servern fest. Wirkt nur, wenn PARALLELISM ist größer als 1 (Standard: 50)

PARALLELISM Minimale Anzahl von Apply Servern (Standard: 4) Oracle Standard Edition: Parameter muß 1 sein!

WRITE_ALERT_LOG Legt fest, ob der INBOUND Server Nachrichten in das ALERT Log schreibt (Standard: YES).

Tabelle 4: Parameter für Integrated Apply

14

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

Integrated Apply

Der Nutzer definiert die Anzahl der Threads

Parallelisierung erfolgt automatisch basierend auf Foreign Keys und Unique Identifier

Transaktionen werden aufgesplittet Transaktionen werden nicht aufgesplittet

Nutzbar für alle unterstützten Datenbanken Nur für Oracle Datenbank 11.2.0.4 und 12c

SQL Ausführung durch den Apply-Prozeß

SQL Ausführung im Oracle Datenbankserver

Tabelle 5: Coordinated Apply versus Integrated Apply

15

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 Datenbank-Parameter 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 Diagnose-Informationen 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:

16

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

17

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 590 >ghdr on

Logdump 591 >detail on

Logdump 592 >detail data

Logdump 593 >usertoken on

Logdump 594 >next

2014/10/08 10:14:16.420.000 FileHeader Len 1396 RBA 0

Name: *FileHeader*

3000 0319 3000 0008 4747 0d0a 544c 0a0d 3100 0002 | 0...0...GG..TL..1...

0004 3200 0004 2000 0000 3300 0008 02f2 2b18 5ba2 | ..2... ...3.....+.[.

7ea0 3400 0037 0035 7572 693a 4a4a 5434 3230 3a64 | ~.4..7.5uri:JJT420:d

653a 6f72 6163 6c65 3a63 6f6d 3a64 7269 7665 2d44 | e:oracle:com:drive-D

3a6f 6767 3132 3132 5f73 7263 3a45 5843 4442 3132 | :ogg1212_src:EXCDB12

5036 0000 2000 1e64 3a5c 6f67 6731 3231 325f 7461 | P6.. ..d:\ogg1212_ta

725c 6469 7264 6174 5c72 7430 3030 3032 3037 0000 | 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 Trail- Files 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

18

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ß

Trail Record nach Pump-Prozeß

2013/06/07 11:52:00.000.000 FieldComp Len 47 RBA 1284

Name: HBUSER.HB_TAB_ORAP

After Image: Partition 4 GU s

0001 0008 0000 0004 6f72 6170 000f 001f 0000 3230 | ........orap......20

3133 2d30 362d 3037 3a31 313a 3532 3a30 302e 3731 | 13-06-07:11:52:00.71

3130 3030 3030 30 | 1000000

Column 1 (x0001), Len 8 (x0008)

0000 0004 6f72 6170 | ....orap

Column 15 (x000f), Len 31 (x001f)

0000 3230 3133 2d30 362d 3037 3a31 313a 3532 3a30 | ..2013-06-07:11:52:0

302e 3731 3130 3030 3030 30 | 0.711000000

User tokens: 96 bytes

544b 5f45 5854 4e41 4d45 0045 5854 4842 5000 544b | TK_EXTNAME.EXTHBP.TK

5f45 5854 5449 4d45 0032 3031 332d 3036 2d30 3720 | _EXTTIME.2013-06-07

3131 3a35 323a 3030 2e39 3938 3030 3000 544b 5f45 | 11:52:00.998000.TK_E

4444 4c44 454c 5441 5354 4154 5300 3000 544b 5f45 | DDLDELTASTATS.0.TK_E

444d 4c44 454c 5441 5354 4154 5300 3100 | DMLDELTASTATS.1.

2013/06/07 11:52:00.000.000 FieldComp Len 47 RBA 1401

Name: HBUSER.HB_TAB_ORAP

After Image: Partition 4 GU s

0001 0008 0000 0004 6f72 6170 000f 001f 0000 3230 | ........orap......20

3133 2d30 362d 3037 3a31 313a 3532 3a30 302e 3731 | 13-06-07:11:52:00.71

3130 3030 3030 30 | 1000000

Column 1 (x0001), Len 8 (x0008)

0000 0004 6f72 6170 | ....orap

Column 15 (x000f), Len 31 (x001f)

0000 3230 3133 2d30 362d 3037 3a31 313a 3532 3a30 | ..2013-06-07:11:52:0

302e 3731 3130 3030 3030 30 | 0.711000000

User tokens: 152 bytes

544b 5f50 4d50 4e41 4d45 0050 4d50 4842 5000 544b | TK_PMPNAME.PMPHBP.TK

5f50 4d50 5449 4d45 0032 3031 332d 3036 2d30 3720 | _PMPTIME.2013-06-07

3131 3a35 323a 3336 2e37 3433 3030 3000 544b 5f45 | 11:52:36.743000.TK_E

5854 4e41 4d45 0045 5854 4842 5000 544b 5f45 5854 | XTNAME.EXTHBP.TK_EXT

5449 4d45 0032 3031 332d 3036 2d30 3720 3131 3a35 | TIME.2013-06-07 11:5

323a 3030 2e39 3938 3030 3000 544b 5f45 4444 4c44 | 2:00.998000.TK_EDDLD

454c 5441 5354 4154 5300 3000 544b 5f45 444d 4c44 | ELTASTATS.0.TK_EDMLD

454c 5441 5354 4154 5300 3100 | 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

19

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

20

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"

21

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

22

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.

23

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.

24

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. Uni-Direktional, 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.

25

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”

26

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 On-Premise 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 Manager-Ports können alle Angaben zu einer GoldenGate Instanz sichtbar gemacht werden:

27

HTTP – Adresse

Anzeige

Weitere Infos

über Link

http://<hostname>:<mgr_port>/registry Augenblicklicher Zustand der Prozesse

Nein

http://<hostname>:<mgr_port>/groups groups/<name>

Prozeß und Prozeßinformationen

Ja

http://<hostname>:<mgr_port>/messages ggserr.log Meldungen Nein

http://<hostname>:<mgr_port>/statuschanges Alle Prozeß-Statusänderungen Nein

http://<hostname>:<mgr_port>/mpoints mpointsx

Einen Prozeß anzeigen Alle Prozesse anzeigen

Ja

Tabelle 10: Monitoring Points ab OGG 12.2.

Abbildung 25: Monitoring Points für Extract Prozeß E1NO121P

28

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

29

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 Quell-objektes automatisch beinhaltet. Man bezeichnet das Trail-File vom Format 12.2 deshalb als selbst-beschreibendes 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“.

30

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

Trail-File Namen

10, 11, 12.1

AA999999 (1 – 999.999)

12.2+

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 Extract-Prozesses 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.

31

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

Standardwert

Bedeutung

FREQUENCY 60 Sekunden Aktualisierungsintervall der Heartbeat-Table

RETENTION_TIME 30 Tage Löschen von Einträgen der Heartbeat-History-Table die älter sind.

PURGE_FREQUENCY

1 Tag

Häufigkeit mit der der Purge Job die verfallenen Einträge in der Heartbeat-History-Table löscht.

Tabelle 12: Parameter für das Einrichten einer automatischen Heartbeat-Table

Objekt

Typ / Inhalt

Standard Name

Heartbeat-Table Tabelle (1 Zeile) hbschema.GG_HEARTBEAT

Heartbeat-Seed-Table Tabelle (1 Zeile) hbschema.GG_HEARTBEAT_SEED

Heartbeat-History-Table Tabelle (n Zeilen) hbschema.GG_HEARTBEAT_HISTORY

GoldenGate Lag View (1 Zeile) hbschema.GG_LAG

GoldenGate History Lag View (n Zeilen) hbschema.GG_HISTORY_LAG

Update Procedure Procedure hbschema.GG_UPDATE_HB_TAB

Purge Procedure Procedure hbschema.GG_PURGE_HB_TAB

Update Job Job hbschema.GG_UPDATE_HEARTBEATS

Purge Job

Job

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.

32

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 AGE FROM TO PATH

4.35s 39.08s NOC121P NOC121S E1NO121P ==> P1NO121P ==> R_NO121S

2.81s 58.53s NOC121S NOC121P E1NO121S ==> P1NO121S ==> R_NO121P

33

(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

34

Oracle 12c

status : current

mandatory : false

dynamic : false

relations : 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 : integratedparams.MAX_PARALLELISM

description :

argument : string

default : 50

pattern : ([0-9]{1,10})

options :

component(s): REPLICAT

mode(s) : Integrated Replicat

platform(s) : all platforms

versions :

min ver : 12.1.2

database(s) : Oracle 11g

35

Oracle 12c

status : current

mandatory : false

dynamic : false

relations : 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 : <enabled>

walletlocation : .\dirwal

allowoutputdir : d:\gg122aa_tar\dirdat

allowoutputdir : d:\gg122o_tar\dirdat

enableheartbeat : <enabled>

heartbeat_table : GG_HEARTBEAT

trail_seqlen_9d : <disabled>

ggschema : OGGADMIN

D:\gg122o_src\dirprm\E1NO121P.prm

extract : e1no121p

userid : oggadmin@NOC121P

password : *******

exttrail : ./dirdat/NOC121P/aa

reportcount : <enabled>

every : 5 minute(s)

rate : <enabled>

warnlongtrans : 1 hour(s)

checkinterval : 30 minute(s)

logallsupcols : <enabled>

updaterecordformat : COMPACT

ddl : <enabled>

include : <enabled>

objname : "TSTSTR"."STR_HEARTBEAT"

ddloptions : <enabled>

report : <enabled>

tranlogoptions : <enabled>

excludetag : 00

table : TSTSTR.STR_HEARTBEAT

Default Values

deletelogrecs : <enabled>

fetchoptions :

userowid : <enabled>

usekey : <enabled>

missingrow : ALLOW

usesnapshot : <enabled>

uselatestversion : <enabled>

maxfetchstatements : 100

usediagnostics : <disabled>

detaileddiagnostics : <disabled>

diagnosticsonall : <disabled>

nosuppressduplicates : <enabled>

flushsecs : 1

passthrumessages : <enabled>

ptkcapturecachemgr : <enabled>

ptkcaptureift : <enabled>

ptkcapturenetwork : <enabled>

ptkcapturequeuestats : <enabled>

ptkspstats : <enabled>

tcpsourcetimer : <enabled>

tranlogoptions :

bufsize : 1024000

asynctransprocessing : 300

checkpointretentiontime : 7.000000

failovertargetdestid : 0

36

getctasdml : <disabled>

minefromsnapshotstby : <disabled>

usenativeobjsupport : <enabled>

retrydelay : 60

allocfiles : 500

allowduptargetmap : <disabled>

binarychars : <enabled>

checkpointsecs : 10 second(s)

cmdtrace : OFF

dynamicresolution : <enabled>

eofdelay : 1

eofdelaycsecs : 100

functionstacksize : 200

numfiles : 1000

ptkcapturetablestats : <enabled>

ptkmaxtables : 100

ptktablepollfrequency : 1

varwidthnchar : <disabled>

ptkcaptureprocstats : <enabled>

ptkmonitorfrequency : 1

use_traildefs : <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 : <enabled>

walletlocation : .\dirwal

allowoutputdir : d:\gg122aa_tar\dirdat

allowoutputdir : d:\gg122o_tar\dirdat

enableheartbeat : <enabled>

heartbeat_table : GG_HEARTBEAT

trail_seqlen_9d : <disabled>

ggschema : OGGADMIN

D:\gg122o_src\dirprm\R_NO121P.prm

replicat : r_no121p

getenv : (NLS_LANG)

userid : oggadmin@NOC121P

password : *******

assumetargetdefs : <enabled>

discardfile : ./dirrpt/r_no121p.dsc

purge : <enabled>

megabytes : 500

reportcount : <enabled>

every : 5 minute(s)

rate : <enabled>

dboptions : <enabled>

settag : 00

suppresstriggers : <enabled>

deferrefconst : <enabled>

ddl : <enabled>

include : <enabled>

objname : "TSTSTR"."STR_HEARTBEAT"

ddloptions : <enabled>

notag : <enabled>

updatemetadata : <enabled>

report : <enabled>

map : "TSTSTR"."STR_HEARTBEAT"

target : "TSTSTR"."STR_HEARTBEAT"

comparecols : ( ON UPDATE ALL, ON DELETE ALL)

resolveconflict : ( UPDATEROWEXISTS, (DEFAULT, OVERWRITE))

Default Values

allownoopupdates : <disabled>

applynoopupdates : <disabled>

37

auditreps : <enabled>

deferapplyinterval : 0 second(s)

grouptransops : 50

maxdiscardrecs : 0

maxsqlstatements : 250

ptkcapturebatchsql : <enabled>

ptkirstatsfrequency : 10

restartcollisions : <disabled>

retrydelay : 60

warnrate : 100

allocfiles : 500

allowduptargetmap : <disabled>

binarychars : <enabled>

checkpointsecs : 10 second(s)

cmdtrace : OFF

dboptions :

limitrows : <enabled>

reparselobsql : <disabled>

skiptemplob : <enabled>

dynamicresolution : <enabled>

eofdelay : 1

eofdelaycsecs : 100

functionstacksize : 200

numfiles : 1000

ptkcapturetablestats : <enabled>

ptkmaxtables : 100

ptktablepollfrequency : 1

varwidthnchar : <disabled>

ptkcaptureprocstats : <enabled>

ptkmonitorfrequency : 1

use_traildefs : <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 Ziel-Datenbank 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

38

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

39

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

40

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

41

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

Infos über jeden Capture-Prozeß, der LCRs an den GoldenGate Outbound Server sendet (Integrated Capture)

V$GOLDENGATE_MESSAGE_TRACKING

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 Capture-Prozeß, 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.

42

Anhang 2: Aktualisierungshinweise zum Dojo 6

Inhalt

Dojo 6

Neu in OGG 12c

Einsatzgebiete

Punkt 2.2

OGG Nutzung voll integriert in ODI Studio Unterstützung E-Business Suite & ATG Web

Integration mit ADG Unterstützt Oracle Cloud Konzept

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

dircrd - Credential Store Files dirdmp - Trace or Dump Files

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

Tabelle 1: Korrekturen im Dojo 6

München, 01. Juni 2016 Joachim Jaensch Principal Sales Consultant joachim.jaensch@oracle.com Joachim.jaensch@web.de