Massendatenreplikation in Echtzeit – ein Erfahrungsbericht mit GoldenGate
Gegen das Leiden von langsamer, teurer und unter großen zeitlichen Verzug stehender Datenversorgung des Businesses und Marketings aufgrund von langlaufenden Delta-Ermittlungen für das Data Warehouse gibt es ein Mittel: die Datenreplikation in Echtzeit.
Oracle’s GoldenGate ermöglicht es, Datenänderungen aus Datenbanken zu erfassen und in andere Datenbanken zu replizieren ggf. auch mit Datenanreicherung und -umkonvertierung und zwar auch heterogen zwischen Oracle, DB2, SQL Server, Teradata und anderen Datenbanken sowie zu Big-Data-Plattformen. Das erlaubt neben der hier implementierten DWH Datenversorgung u.a. folgende UseCases:
• Data Lakes mit Daten aus vielen Quellsystemen zu versorgen
• Daten ins DWH zu historisieren
• Datenbanken bidirektional zu replizieren, um sie aktiv-aktiv zu betreiben
• Reportinglast auf ein repliziertes System zu verlagern
• Data Marts kaskadierend aus dem DWH zu versorgen
• Datenbank-Upgrades mit Zero Downtime durchzuführen
Konkrete Erfahrungen
Durch Einführung der Oracle GoldenGate-Replikation bei einer großen Versicherung konnten die hohen Kosten für die genutzte CPU-Verarbeitung der Delta-Ermittlung vermieden werden und Daten aus den Quellsystemen in Echtzeit im DWH zur Verfügung gestellt werden. Durch die parallele Einführung des Oracle Data Integrator und der darauf basierenden Implementierung eines metadaten-getriebenen Generators (vgl. Data Warehouse Automation mit MTGen – Metadaten statt Handarbeit) konnten Folgeverarbeitungen im Data Warehouse schnell umgestellt werden und die GoldenGate-Parametrisierung für die hohe Zahl an Quelltabellen generiert werden.
Installation und Konfiguration
Bei der GoldenGate-Replikation zwischen Oracle-Datenbanken im Integrated Mode können sowohl der Capture- als auch der Replicat-Prozess remote also auf einem separaten Rechner laufen. So kommen wir im konkreten Fall mit einer produktiven Installation aus, auf der inzwischen 20 Prozesse laufen.
Eine Hochverfügbarkeit von GoldenGate wurde durch die Einbindung in die Oracle Cluster Software – der Grid Infrastructure erreicht. Bei Ausfall des Servers, auf dem GoldenGate läuft, wird GoldenGate auf einem anderen Server im Cluster automatisch gestartet.
Stabilität
Nach über zwei Jahren Betriebs dieser Implementierung freut sich der Kunde über die Stabilität der Lösung. Da GoldenGate sich über Checkpoints genau merkt, was extrahiert und was repliziert wurde, sind Abbrüche und Ausfälle der beteiligten Datenbanken oder von GoldenGate selbst unkritisch. Die Replikation ist zudem so konfiguriert, dass automatisch Restarts versucht werden.
Inzwischen wurde die Replikation deutlich erweitert: es wurde eine Near-Realtime-Strecke ins DWH eingezogen und genutzt sowie weitere Datenbanken und -Tabellen angebunden, sodass nun ca. 400 Tabellen aus sechs Datenbanken in das DWH repliziert werden.
Upgrades
Ältere GoldenGate-Versionen werden nicht mit neueren Datenbank-Versionen zertifiziert. So war beim Datenbank-Umzug und Upgrade von 11.2 nach 18.1 auch GoldenGate umzuziehen und upzugraden von 12.2 auf 18.
Historisierung
Initial wurde eine Replikation mit Historisierung aufgesetzt bei der UPDATE- und DELETE-Statements auf der Quelle umkonvertiert wurden zu INSERT-Statements in die Staging Area auf dem DWH, um ein Changelog der Tabellen zu erhalten und die DWH-Weiterverarbeitung zunächst nicht umstellen zu müssen. Um in den Changelog-Zieltabellen eine Spalte mit einer fortlaufenden ID zu befüllen, wurde über in einem GoldenGate-SQLEXEC ein tabellenspezifischer Sequenzwert gezogen und gesetzt. Ein generisches GoldenGate-Makro vereinfachte die hierfür notwendige Parametrisierung.
Massendaten-Replikation
Nach längerem Betrieb fiel auf, dass etwa vierteljährlich der Replikationsverzug mehrere Stunden groß wurde. Die Analyse ergab, dass hier innerhalb einer Stunde einige Millionen DML-Statements gegen wenige Quelltabellen liefen. Mit einem Testgenerator wurde dieses Verhalten bestätigt. Der Verzug tritt dagegen nicht auf, wenn man den Replicat auf den Classic Mode umstellt oder wenn man den Sequenzwert für die Changelog-Tabellen nicht per SQLEXEC holt und setzt, sondern über eine Identity Column in der Zieltabelle. Eine Oracle Support Note bestätigt den Slowdown der Replikation bei Nutzung von SQLEXEC. Zum Zeitpunkt der Implementation lief das DWH noch auf Version 11.2, auf der es noch keine Identity Columns gab. Die Lösung hierfür besteht also darin, entweder auf Classic Mode oder auf Identity Columns in den Zieltabellen umzustellen.
Echtzeit-Replikation
Bei der Einführung der Near Realtime-Replikation sollte der Replikationsverzug minimiert werden und möglichst die von Oracle im GoldenGate Data Sheet genannte „sub-second latency“ erreicht werden. Nachdem Optimierungen im Integrated Mode den Verzug nicht auf unter 2 Sekunden bringen konnten, wurde die Replikation auf Classic Mode umgestellt und mit weiteren Optimierungen Verzugswerte um eine Sekunde erreicht.
Kundenzufriedenheit
Mit der Einführung von GoldenGate konnte der Kunde die Kosten und die Wartezeiten für die Delta-Ermittlungen vermeiden und das DWH in Echtzeit mit Daten versorgen. GoldenGate wird rege genutzt, um weitere Datenbanken und Tabellen anzubinden und Daten und Analysen in Echtzeit bereitzustellen.