Oracle GoldenGate: Datenaustausch zwischen Oracle und MySQL

In meinem zweiten DOAG-Vortrag ging es darum, wie man eine Oracle Datenbank und eine MySQL Datenbank im laufenden Betrieb synchronisieren kann, so dass beide den gleichen Datenstand haben.

Oracle DB und MySQL sind – beide – stark verbreitet. Sie werden häufig im selben Unternehmen, wennauch für verschiedene Anwendungen, eingesetzt. In bestimmten Fällen müssen die Daten der Oracle Datenbank auch für MySQL Clients verfügbar gemacht werden und zwar so, dass jede Aktualisierung der Oracle Daten auch für MySQL-Clientanwendungen sofort sichtbar ist. Oracle GoldenGate ist in solchen Fällen die passende technologische Lösung. Oracle GoldenGate ist in der Lage, Daten zwischen unterschiedlichen Datenbanken (Oracle, SQLServer, DB2, Sybase, PostgreSQL u.a.), auch bei nicht identischen Datenstrukturen, zu replizieren. Neben der laufenden Synchronisation unterstützt GoldenGate auch das einmalige Laden von Daten aus einer Oracle Datenbank in eine MySQL Datenbank, beispielweise im Falle einer Migration.

Die Präsentation gibt eine kurze Einführung in GoldenGate und behandelt anschließend die unidirektionale Replikation von Oracle nach MySQL.

Advertisements

Die Oracle Datenbank: ein Service der Oracle Public Cloud

Oracle Datenbanken werden typischerweise im eigenen Rechenzentrum betrieben oder bei einem externen Anbieter gehostet. Seit kurzem hat man die Möglichkeit die Oracle Datenbank auch als Service in der Oracle Public Cloud zu nutzen. Die Oracle Public Cloud -offiziell Oracle Cloud- ist im Internet auf cloud.oracle.com zu finden. Darin bietet Oracle, neben der Datenbank, eine Reihe weiterer Produkte verpackt als Services: von einer Java Plattform zur Entwicklung von Java EE Applikationen bis hin zu fertigen Unternehmensanwendungen im Bereich ERP oder CRM.

Der Oracle Database Cloud Service bietet Zugang zu einem Schema der Oracle Datenbank Enterprise Edition mit Werkzeugen für Upload, Download und Verwaltung der Daten. Außerdem bietet der Dienst eine Plattform zur Entwicklung von Webanwendungen auf Basis der Oracle Datenbank. Man beantragt den Datenbankservice über ein Selfservice Portal und kann die Datenbank von überall nutzen, wo ein Internetanschluss zur Verfügung steht. Es wird pro Monat oder Jahr, in Abhängigkeit von der Storagekapazität, abgerechnet. Die Nutzungspauschale beinhaltet alle anfallenden Kosten: die von Oracle bereitgestellte Exadata-Infrastrukur, die Softwarelizenzen, den Support sowie die Administration durch Oracle.

Ich habe den Oracle Database Cloud Service in einem Vortrag auf der diesjährigen DOAG Konferenz vorgestellt. Dabei ging es um die Architektur, die Werkzeuge und den Zugriff auf die Oracle Datenbank in der Oracle Public Cloud. Die Folien finden Sie hier.
 

 

Kurz und knapp: Ausfallsicherheit für Oracle Datenbanken

In diesem Video stellen wir Basistechnologien im Bereich Hochverfügbarkeit und Desasterschutz vor. Es geht um Clustering auf physikalischer Ebene mit Real Application Clusters (RAC) und den Betrieb von Standby Datenbanken mit Active Data Guard. Eine Einführung. Danke an Peter für die Produktion!

 

 

Oracle Database Appliance, Stand Juni 2012

Gestern hat das DOAG Regionalgruppentreffen Berlin/Brandenburg stattgefunden. Ich habe die Oracle Database Appliance vorgestellt und ein Update zu den unterstützten Features und Erweiterungen gegeben. Die Folien dazu sind hier verlinkt.
 

 
Die wichtigsten Updates sind:

  • es ist erlaubt an die Oracle Database Appliance einen externen NFS-Storage anzuschließen. Darauf können  auch Datenbankdateien gespeichert werden, zusätzlich zu Backups. So stellt der lokale Storage der Appliance (netto 4 TB) keine Einschränkung mehr dar.  Ist der NFS-Storage eine ZFS Storage Appliance von Oracle, so darf man darauf Hybrid Columnar Compression nutzen (letzeres ist kein Feature der Oracle Database Appliance, sondern mit  jeder Oracle Datenbank 11.2.0.3 EE auf Oracle Storage möglich);
  • alle Softwareagenten (zur Überwachung, Sicherung, Authorisierung,..) sind zugelassen. Die  White List von Agenten wird nicht weiter geführt;
  • es ist erlaubt Fremdanwendungen zu installieren. Die Anwendungen müssen für Oracle Linux 5.8 (Unbreakable Enterprise Kernel) und für die Oracle Datenbank 11.2.0.3 zertifiziert sein. Auf der Appliance muss die aktuelle Version des Appliance Managers (2.2) laufen. Erforderliche RPMs können beim Oracle Support angefordert werden.

Weitere Auskunft geben die aktuellen FAQs zur Oracle Database Appliance auf My Oracle Support > Note ID 1463638.1.

Oracle Hybrid Columnar Compression oder Advanced Compression?

In der Vergangenheit wurde häufiger angefragt, wo der Unterschied zwischen Advanced Compression und Hybrid Columnar Compression ist und ob es Sinn macht, beide Komprimierungstechniken der 11g Datenbank gleichzeitig einzusetzen. Advanced Compression (ACO) ist seit Version 11g eine kostenpflichtige Option zur Oracle Datenbank Enterprise Edition (EE). Hybrid Columnar Compression (HCC) hingegen, ist ein kostenloses EE-Feature, das ab Version 11.2.0.3 für alle Oracle Storage Systeme freigegeben wurde (Exadata Storage, ZFS Storage Appliance, Pillar Axiom).

Als erstes stellt sich die Frage, was komprimiert werden soll.

Sind es Tabellendaten, so hat man die Wahl zwischen 4 Verfahren: OLTP Table Compression (Bestandteil von ACO), Warehouse Compression (Bestandteil von HCC), Archive Compression (Bestandteil von HCC) und Basic Compression (Feature der Enterprise Edition).  In derselben Datenbank können die Verfahren koexistieren. Welche Komprimierungsmethode mehr Sinn macht, hängt von der Art des Zugriffs auf die Tabellendaten ab. OLTP Table Compression eignet sich für Tabellen, in denen die Daten häufig verändert werden. Tabellen, auf die überweigend lesend zugegriffen wird, sollten mit Basic Compression oder -noch speicherplatzeffizienter- mit Warehouse Compression komprimiert werden. Archive Compression ist das beste Komprimierungsverfahren für Tabellen, die für Compliance-Zwecke aufbewahrt und kaum verwendet werden. Sind die Tabellen Tabellen partitioniert, so können sie mit ACO und HCC gleichzeitig komprimiert werden. In meinem kürzlich erschienenen Artikel erfahren Sie mehr über die einzelnen Algorithmen und deren Einsatzgebiete.

Unstrukturierte und semistrukturierte Daten in der Oracle Datenbank (Bilder, Textdokumente, XML-Dateien u.ä.) lassen sich nur mit Advanced Compression komprimieren und nur wenn sie als SecureFiles LOBs gespeichert sind. Ab 11g R1 ist SecureFiles eine neue Storage Architektur für Large Objects.

Indizes können unabhängig von den dazugehörigen Tabellen komprimiert werden. Dazu benötigen Sie weder ACO noch HCC. Die Komprimierung von Indizes ist eine Funktionalität jeder Datenbankedition.

Möchte man Datensicherungen (Backups) mit Mitteln der Oracle Datenbank komprimieren, müssen die Backups mit Oracles Sicherungswerkzeug – dem Recovery Manager (RMAN) – durchgeführt werden. Weiterhin müssen die Backups als Backup Sets (und nicht als Image Copy) gespeichert werden. Bei der Erstellung der Backups hat man die Wahl zwischen 4 Komprimierungsalgorithmen BASIC, LOW, MEDIUM, HIGH. Hinter BASIC verbirgt sich die Default RMAN Compression. Sie ist in jeder Datenbankedition (Standard oder Enterprise Edition) ohne Zusatzkosten erlaubt. Die anderen 3 Algorithmen sind Bestandteil von Advanced Compression.

Mit Data Pump exportierte Daten können ebenfalls komprimiert werden. Metadaten kann man ohne Weiteres in jeder DB-Edition komprimieren. Möchte man Daten und Metadaten komprimieren oder nur die Daten, so ist Advanced Compression erforderlich.

Nicht zuletzt kann auch den Netzwerkverkehr zwischen Primary und Standby Datenbank (genauer die Redo Logs) in einer Data Guard Konfiguration komprimieren, um Bandbreite einzusparen. Dafür benötigt man auch Advanced Compression.

Fazit: Advanced Compression und Hybrid Columnar Compression lassen sich kombinieren, um das gesamte Komprimierungspotenzial der Oracle Datenbank auszuschöpfen.

Welche Oracle Datenbank Features nutzen Sie?

In einem anderen Blogeintrag ging es darum, wie man die Nutzung von Optionen und Packs – also der lizenzpflichtigen Add-ons zur Oracle Datenbank Enterprise Edition – aufdecken kann.

Darüber hinaus, stellt sich u.a. bei einem Downgrade der Enterprise Edition (EE) auf die Standard Edition (SE) die Frage, ob Funktionalität verwendet wird, die nur zur EE gehört.  Oracle LMS und divese Oracle Partner bieten Dienstleistungen an, um die Nutzung von Features zu auditieren und Ihnen Lizenz-Compliance zu bescheinigen. Ein solcher Service ist sinnvoll, denn die selbstständige Untersuchung ähnelt Detektivarbeit und hat keinen Anspruch auf Vollständigkeit und Verbindlichkeit. Warum, das werden wir hier beleuchten.

Der Startpunkt einer solchen Untersuchung ist die Data Dictionary View DBA_FEATURE_USAGE_STATISTICS. Sie gibt Auskunft über einen Teil der verwendeten Funktionalität.

sql> SELECT name, detected_usages, version, TO_CHAR(last_usage_date, 'dd-mm-yyyy hh12:mi:ss'), TO_CHAR(last_sample_date,'dd-mm-yyyy hh12:mi:ss') FROM dba_feature_usage_statistics WHERE detected_usages > 0  ORDER BY name;

Die Ausgabe ist eine Aufzählung von Funktionen, wie in der folgenden Tabelle:

NAME LAST_USAGE_DATE
Audit Options 23-04-2012 01:06:09
Automatic Maintenance – Optimizer Statistics Gathering 23-04-2012 01:06:09
Automatic Maintenance – Space Advisor 23-04-2012 01:06:09
Automatic SGA Tuning 23-04-2012 01:06:09
Automatic SQL Execution Memory 23-04-2012 01:06:09
Automatic Segment Space Management (system) 23-04-2012 01:06:09
Automatic Undo Management 23-04-2012 01:06:09
Character Set 23-04-2012 01:06:09
Deferred Segment Creation 23-04-2012 01:06:09
HeapCompression 23-04-2012 01:06:09
Locally Managed Tablespaces (system) 23-04-2012 01:06:09
Locally Managed Tablespaces (user) 23-04-2012 01:06:09
Oracle Java Virtual Machine (system) 23-04-2012 01:06:09
Oracle Utility Datapump (Import) 23-04-2012 01:06:09
Partitioning (system) 23-04-2012 01:06:09
Recovery Area 23-04-2012 01:06:09
SecureFiles (system) 23-04-2012 01:06:09
SecureFiles (user) 23-04-2012 01:06:09
Server Parameter File 23-04-2012 01:06:09
Virtual Private Database (VPD) 23-04-2012 01:06:09

Man sollte bei der Interpretation der Ausgabe Folgendes beachten:

  1.  Das Ergebnis ist potentiell veraltet. DBA_FEATURE_USAGE_STATISTICS wird einmal alle 7 Tage aktualisiert. Der dazugehörige Job wird von internen Datenbankprozessen angestoßen und kann nicht bei Bedarf (ohne weiteres) gestartet werden. Die Spalte last_sample_date zeigt, wann die letzte Statistikensammlung durchgeführt wurde, somit auch wie alt die Ergebnisse sind.
  2. Das Ergebnis ist nicht vollständig. Zur Abgrenzung zwischen den Editionen sollte man die Feature-Matrix aus der Oracle 11gR2 Dokumentation und dem Oracle Database 11gR2  Licensing Information Guide heranziehen, siehe dazu auch Blogeintrag. DBA_FEATURE_USAGE_STATISTICS berücksichtigt um die 150 Features. Das sind nicht alle EE-Features aus der Feature-Matrix. Ein einfaches Beispiel: Flashback Table wird von DBA_FEATURE_USAGE_STATISTICS nicht berücksichtigt.
  3. Das Ergebnis ist nicht immer relevant. DBA_FEATURE_USAGE_STATISTICS differenziert nicht immer, ob ein Feature von Datenbanknutzern oder intern, von Oracle, verwendet wird. z.B. Virtual Private Database ist in allen Datenbankeditionen aufgelistet, auch wenn es rein intern, für die Implementierung der XML Funktionalität in der Datenbank verwendet wird. Features, die von Standard Oracle Usern verwendet werden (z.B. XDB) fallen nicht unter der Lizenzpflicht. Eine solche Nutzung ist bei einigen Funktionen in Klammern angegeben (system). Wenn keine Kennzeichnung vorhanden und sollten Zweifel an der Nutzung einer Funktionalität bestehen,  sind weitere Untersuchungen notwendig. z.B. bei Virtual Private Database sollte man sich anzeigen lassen, welcher User die Policies angelegt hat und ob es ein Standard Oracle User ist oder nicht.
  4. Die Zuordnung eines Features aus DBA_FEATURE_USAGE_STATISTICS zu einer Edition ist nicht immer einfach. Die Feature-Namen in DBA_FEATURE_USAGE_STATISTICS und im Oracle Whitepaper sind leider nicht identisch.

Fazit: DBA_FEATURE_USAGE_STATISTICS ist ein hilfreiches Werkzeug bei der Ermittlung der eingesetzten Datenbankfeatures. Aus den o.g. Gründen sollte die Auskunft aus  DBA_FEATURE_USAGE_STATISTICS nicht als verbindlich angesehen werden. Weitere Untersuchungen und ergänzende Abfragen sind erforderlich.

Technische Abgrenzung zwischen der Oracle Datenbank Standard Edition und Enterprise Edition

Eine Frage, die mir immer wieder begegnet, ist ob sich  Oracles Datenbankeditionen Standard (SE) und Enterprise (EE) in der Basisfunktionalität, also abgesehen von den Enterprise Edition Erweiterungen (Management Packs und Datenbankoptionen), unterscheiden. Oder ob die Unterscheidung rein formell ist und der Lizenzierung dient, sprich die Funktionalität ist in beiden Editionen vorhanden. Dieser Frage soll in diesem Eintrag nachgegangen werden.

Ein Blick in den Database Installation Guide zeigt, dass man für eine Enterprise Edition Installation knapp 2% mehr Speicherplatz auf der Festplatte benötigt. Nicht nur die Oracle Homes sind unterschiedlich groß: das Data Dictionary einer Enterprise Edition Datenbank enthält Datenbankobjekte, die in der Standard Edition nicht vorhanden sind. Aus diesem Grund ist empfohlen, bei einem Downgrade von EE auf SE einen Export/Import vorzunehmen. Die SYS-Schemaobjekte werden nicht exportiert; somit wird man die EE-spezifischen Data Dictionary Objekte los (My Oracle Support > Support Note ID 139642.1). Die SE-Funktionalität hingegen ist in der EE gänzlich enthalten; deswegen ist der Konvertierungsprozess einer SE zu einer EE recht einfach (My Oracle Support > Support Note ID 117048.1).

Man kann sagen, dass die installierte Software für SE und EE fast identisch ist: es werden standardmäßig alle Features und Komponenten der EE installiert. So lässt sich prüfen, welche Komponenten installiert wurden:

sql> select comp_id, comp_name, status, schema from dba_registry order by comp_name;

Der DB-User in der Spalte schema ist der Eigentümer der  jeweiligen Datenbankkomponente und deren Objekte, z.B. MDSYS für Oracle Spatial. Die Abfrage liefert identische Ergebnisse in der SE und in der EE (Version 11gR2). Man sieht, dass EE  Optionen wie Spatial auch in der SE installiert werden.

Die EE-Funktionalität  steht in der SE jedoch nur bedingt zur Verfügung. Die kostenplichtigen Optionen der EE (wie Advanced Compression oder Partitioning) sind in der SE standardmäßig deaktiviert. So wird der Versuch eine Tabelle mit dem Zusatz compress for oltp anzulegen oder zu partitionieren scheitern, mit der Fehlermeldung ORA-00439: feature not enabled. Leider sind nicht alle EE-Funktionen gesperrt. Man kann in SE 11gR2 problemlos über flashback table to before drop gelöschte Tabellen aus dem Recyclebin wiederherstellen, obwohl dieses Feature der EE vorbehalten ist. Flashback Database ist wiederum gesperrt.

Es bleibt Aufgabe des Nutzers sicherzustellen, dass nur lizenzierte Features im Einsatz sind. Welche Features in welcher Datenbankedition erlaubt oder Teil der lizenzpflichtigen Optionen sind, beschreibt der Oracle Database 11gR2  Licensing Information Guide. Die Feature Matrix findet man auch auf My Oracle Support in der Support Note ID 1084132.1. Diese Dokumente sollten vor der Nutzung  einer Datenbankfunktionalität immer herangezogen werden.