Follow Us on Twitter

Datareplicatie met Oracle GoldenGate

Gepubliceerd in

Januari 2013 – Stel, je wilt data van operationele systemen naar het datawarehouse sturen. Of je wilt een rapportageomgeving opzetten waarvan de data up-to-date is met de produktiedatabases , al dan niet van verschillende leveranciers. Vroeger moesten hiervoor zelf interfaces opgezet worden die gebruik maakten van allerlei technologieën als flat-files, XML-berichten of, in het geval van Oracle naar Oracle, mogelijk Streams. Sinds 2009 heeft Oracle GoldenGate onder haar hoede, de voorkeursoplossing voor real-time data-integratieproblematiek. Maar is het echt zo goed en simpel te configureren als wordt beweerd? Hoe verhoudt het zich tot de andere Oracle-technologieën voor replicatie?

Wanneer GoldenGate?

Het doel van Oracle GoldenGate is om te voorzien in een technische oplossing voor de replicatie van gegevens tussen databases van mogelijk verschillende leveranciers zoals Oracle, MySQL, SQL-Server en DB2. Hierbij moet uiteraard de consistentie van de data en snelheid van overdracht niet in het geding zijn. Mogelijke scenario’s waar GoldenGate ingezet kan worden volgens Oracle zijn:

  • Een rapportageomgeving van data voorzien.
  • Datadistributie naar meerdere locaties binnen een bedrijf.
  • Consolidatie van data uit meerdere systemen ten behoeve van ETL/Datawarehousing.
  • Failover, waarbij bi-directioneel data kan worden gerepliceerd: zodra de primary site down gaat neemt de standby het over, waarbij de wijzigingen van de standby later toegepast kunnen worden op de primary.

Architectuur

De architectuur van GoldenGate ziet er schematisch als volgt uit:


 
In dit plaatje worden de volgende onderdelen benoemd:

Data-extractie of capture

In een replicatieproces is de eerste stap de extractie van data uit het bronsysteem. GoldenGate doet dit op basis van de (online) redo logfiles van de Oracle database. Databases zoals SQL-Server en DB2 gebruiken soortgelijke logfiles. Voor databases waar dit niet zo is worden speciale API’s gebruikt om toegang te krijgen tot gecommitte transacties. Dit betekent dat er geen wijzigingen aangebracht hoeven te worden aan het schema van de databaseapplicatie zoals triggers die de gewijzigde records markeren. Een vereiste is wel dat de tabellen een primary key hebben of op zijn minst een unieke index.

Doordat bij het extractieproces gebruikgemaakt wordt van de database logfiles kan GoldenGate de wijzigingen van de database registreren met een minimale performance impact. Een mooie feature is dat ook extract-configuraties gemaakt kunnen worden die op de klassieke manier tabellen lezen ten behoeve van initiële loads.
In het extractieproces is er de mogelijkheid om filters op te nemen die bepalen van welke tabellen of kolommen data gewenst is in het doelsysteem. Hierbij kunnen ook datatransformaties ingevoerd worden op basis van code of databaseprocedures. Dit heeft uiteraard wel een negatieve impact op de performance.

Trailfiles

Trailfiles bevatten de gewijzigde data van het extractieproces in een formaat dat door alle extractieprocessen op verschillende databases wordt gebruikt. Je kunt een extractieproces indien gewenst XML, ASCII, SQL-statements of SQL*Loader-bestanden laten genereren. Trailfiles kunnen direct worden afgeleverd op het doelsysteem. Encryptie van de trailfiles is mogelijk. Dit is gewenst in beveiligde omgevingen. Ondanks dat de standaard trailfiles binair zijn kun je er toch wel enige informatie uit halen.
Trailfiles worden volgeschreven tot een maximum grootte, daarna wordt een nieuwe trailfile met een opvolgend nummer aangemaakt. De trailfiles kunnen automatisch worden opgeruimd indien de wijzigingen succesvol zijn toegepast op het doelsysteem en ouder zijn dan de retentieperiode.

Datapump

Trailfiles kunnen dus meteen afgeleverd worden op het doelsysteem, maar ze kunnen ook lokaal opgeslagen worden op het bronsysteem voor verdere verwerking. Het voordeel van lokaal opslaan is dat uitval van het doelsysteem door netwerkproblemen of anders, niet zal leiden tot het foutief beëindigen van het extractieproces op het bronsysteem. De data in de trailfiles zal zich dus opstapelen voor latere verwerking. Hiermee voorziet GoldenGate in een losgekoppelde architectuur.

Een ander voordeel van het lokaal zetten van trailfiles is dat er gebruikgemaakt kan worden van de GoldenGate Datapump-module (niet te verwarren met de Oracle database datapump). In plaats van rechtstreekse aflevering van extractiedata naar het doelsysteem door het extractieproces kun je met Datapump meerdere afleveringspunten configureren, ook wel routing genoemd. Ook hier geldt weer een hogere veiligheidsmarge: Het uitvallen van een route naar een specifiek doel leidt niet tot uitval op de bron of andere doelsystemen. De trailfiles worden op het doelsysteem neergezet waarna het Delivery proces de wijzigingen toepast.

Collector

De collector is een achtergrondproces op het doelsysteem dat gegevens van de trailfiles ontvangt via netwerk en ze weer lokaal in trailfiles wegschrijft.

Delivery (replicat)

De delivery module is verantwoordelijk voor het toepassen van de wijzigingen uit de lokale trailfiles die van de verschillende bronsystemen afkomstig zijn. De data wordt toegepast in de volgorde zoals ze vastgelegd was in het bronsysteem. Hiermee wordt de referentiele integriteit van de data gewaarborgd.
De aflevering op databases van verschillende leveranciers is uiteraard mogelijk. Daarnaast kunnen, doormiddel van plugins, JMS-queues of specifieke applicatiemodules via Java API’s aangeroepen worden.

Transformatie, filtering en tabel- en kolom-mapping is (net als in de configuratie van de extractiemodule) mogelijk. Hiermee zou je dus in het geval van replicatie naar meerdere doelsystemen een canoniek formaat voor extractie kunnen definiëren. Bij de aflevering kan je dit formaat weer transformeren naar een systeem- of applicatie-specifiek formaat.

Manager

Het managerproces voert verschillende functies uit, zoals het regisseren van de voorgaande modules. Daarnaast is het verantwoordelijk voor het genereren van rapportages en de configuratie voor de interactie tussen de verschillende systemen.

Het mooie aan de GoldenGate softwarearchitectuur is dat je geen specifieke onderdelen hoeft te installeren, of je nu op een systeem data wil onttrekken of toepassen: in een enkele installatie op de databaseserver kun je alle modules gebruiken. Op deze manier kun je een opzet maken waarbij data bi-directioneel wordt uitgewisseld.

GoldenGate installatie en configuratie

Het installeren van GoldenGate is vrij simpel. Op elke databaseserver maak je een directory aan waarin de database-vendor specifieke installatiefile wordt geplaatst. Deze pak je uit en daarna kun je de GoldenGate command line interface (GGSCI) opstarten om de configuraties aan te maken.

Voor zowel de bron als doelinstallatie moet een manager geconfigureerd worden. Hierbij moet onder meer een poort opgegeven worden waarop de manager bereikbaar is. Opdrachten, geïnitieerd vanuit bijvoorbeeld een captureproces op een andere databaseserver kunnen dan aangeroepen worden.

Voordat verdere configuraties worden aangemaakt, moet wel gezorgd worden dat de database waar de extractie (capture) op plaats vindt, in het geval van Oracle, supplemental logging op databaseniveau aan heeft staan. Dit is nodig omdat Oracle standaard geen primary key gegevens logt bij updates op andere kolommen. Dit is echter wel noodzakelijke informatie wanneer wijzigingen moeten worden toegepast.

Ook moet in de database een administratie schema/user bestaan die gebruikt wordt door GoldenGate om:

  • toegang te verkrijgen tot logfile locaties;
  • eventueel database dictionary lookups te doen ten behoeve van filtering / mapping;
  • wijzigingen toe te passen op objecten;
  • in het geval van een target database een checkpoint tabel te plaatsen waarin bijgehouden wordt tot hoever de transacties van de trailfiles succesvol zijn toegepast. Je kunt in de configuratie van een replicatiegroep aangeven of je hier wel of niet gebruik van maakt. Indien niet zullen de checkpoints uit de /dirchk-directory gebruikt worden. Aangeraden wordt om altijd gebruik te maken van een database checkpoint tabel omdat het bijwerken ervan onderdeel uitmaakt van dezelfde databasetransactie als de replicatie zelf. Hiermee voorkom je dus inconsistentie in een uitval scenario.

Daarna kan je starten met het aanmaken van een extractie- en/of replicatiegroep. Een groep bevat de configuratie van databaseobjecten die op dezelfde wijze gerepliceerd moeten worden. Zo moet je dus op de bron een extractiegroep maken voor een set met tabellen ten behoeve van een initiële load (geen continu proces), en een extractiegroep voor de capture van alleen de wijzigingen. Hetzelfde geldt voor de doeldatabase: een aparte groep voor de toepassing(replicatie) van de initiële load en wijzigingen.

Hieronder een voorbeeld van een extractiegroep waarin wijzigingen van de tabel ORDER_HEADER worden gecaptured op de brondatabase:

GGSCI (source.vanluytelaar.com) 2> edit param egrp01

-- Change Data Capture parameter file to extract
-- OLTP table changes
EXTRACT EGRP01
-- Omgeving en user waarmee source gecaptured kan worden
SETENV (ORACLE_SID=orcl)
USERID ggs_admin, PASSWORD ggs_admin
-- Lokale trailfiles in ./dirdat/sa
EXTTRAIL ./dirdat/sa
-- capture ook truncates op brontabel
GETTRUNCATES
TABLE GGS_SOURCE.ORDER_HEADER;

Vervolgens kun de de daadwerkelijke overdracht van de trailfiles over het netwerk naar de doeldatabase(s) configureren (datapump):

GGSCI (source.vanluytelaar.com) 2> edit param pgrp01

-- Data Pump parameter file to read the local
-- trail of table changes
EXTRACT PGRP01
-- Source en target tabeldefinitie zijn hetzelfde, geen secifieke mappings of conversies: passthru
PASSTHRU
-- Remote host manager op poort 7810
RMTHOST target.vanluytelaar.com, MGRPORT 7810
-- de trailfiles worden op de remote GG-installatie in .dirdat/ta geplaatst
RMTTRAIL ./dirdat/ta 
TABLE GGS_SOURCE.ORDER_HEADER;

Op de target-database kun je op soortgelijke manier het replicatieproces inregelen:

GGSCI (target.vanluytelaar.com) 2> edit param rgrp01

-- Replicator parameter file to apply changes
-- to tables
REPLICAT RGRP01
-- user waarmee changes toegepast worden op target
SETENV (ORACLE_SID=orcl)
USERID ggs_admin, PASSWORD ggs_admin
-- Source en targetstructuur zijn gelijk
ASSUMETARGETDEFS
-- File waarin replicatiefouten worden gelogd, opruimen als replicatie herhaald wordt
DISCARDFILE ./dirrpt/rgrp01.dsc, PURGE
-- Truncateopdrachten vanuit source ook toepassen
GETTRUNCATES
MAP GGS_SOURCE.ORDER_HEADER, TARGET GGS_TARGET.ORDER_HEADER;

Na een correcte inregeling kun je de manager en de verschillende capture en replicatieprocessen opstarten vanuit de commandline. Het is mogelijk om groepen automatisch met het manager-proces te starten door deze in de manager-configuratie op te nemen.

Conclusie

De installatie en configuratie van GoldenGate is vrij simpel. Laat je niet afschrikken door het vele commandline- en configuratiefile-geweld: eens je een goede planning hebt gemaakt van je replicatiearchitectuur vind je hier snel je weg in terug. Daarnaast is het handig dat de configuraties gewoon als tekstbestanden in de ./dirprm- directory terug te vinden zijn. Je zou dus bij complexe configuraties zelfs delen ervan kunnen genereren vanuit de database (denk aan kolom mappings etc.).

De vraag blijft wel: wat is nu een goede reden om GoldenGate in te zetten? Het gemakkelijkste antwoord hierop is: indien je data vanuit databases van verschillende leveranciers transparant wil repliceren. Als pure failover-oplossing is het wellicht minder geschikt: Oracle heeft hier DataGuard voor, waarbij gegarandeerd de standby database in zijn geheeld synchroon gehouden wordt zonder extra configuratie. Een kanttekening daarbij is wel dat een physical standbydatabase niet gemanipuleerd kan worden als de primary in de lucht is. Voor een scenario waarbij een tweede database, naast bijvoorbeeld produktie, up-to-date moet worden gehouden voor testdoeleinden (lezen en schrijven) zal GoldenGate dus meer van toepassing zijn.

Je kunt je ook afvragen wat de meerwaarde van GoldenGate is als je een replicatie van Oracle naar Oracle wil doen. Je zou dit immers ook via Streams kunnen doen. Omdat Oracle zelf GoldenGate aanprijst als strategisch product voor replicatiedoeleinden is er wellicht meer aan de hand. Streams is natuurlijk onlosmakelijk met de Oracle database verbonden waarbij GoldenGate een loosely coupled architectuur heeft. Volgens een Oracle Blog zal er aan Streams zelf niet veel meer veranderen, maar de technologie erachter zal wel meer gebruikt worden om efficiënt replicatie te kunnen doen met GoldenGate.

Referenties

Waardering:
 

Reacties

hey Maarten,

Erg goed verhaal! Een kleine opmerking/aanvulling: Ook met dataguard kan je een standby database voor bijvoorbeeld testdoeleinden bijhouden dmv een 'snapshot' standby. Wordt dan alleen niet realtime bijgehouden.

Groet,

Tony

Zag deze blog bij Frank staan. Misschien aardige aanvulling wat de minimale latency is tussen optreden DML en landen in doelomgeving. Ik gok dat die gelijk is aan de wisseltijden van logfiles. Maar weet niet zeker. Ken het alleen van Unisys mainframe.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.

Meer informatie over formaatmogelijkheden

CAPTCHA
Deze vraag is om te testen of u een persoon bent en om spam te voorkomen
Image CAPTCHA
Enter the characters shown in the image.