Upload
dangkhue
View
335
Download
2
Embed Size (px)
Citation preview
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 [email protected] [email protected]