Der Oracle Database In-Memory Advisor ist da

Der In-Memory Advisor hilft bei der Evaluierung der In-Memory Option, speziell bei der Beantwortung der Frage, ob sich eine Performance-Verbesserung erzielen lässt.

Das Tool hilft auch bei der Konfiguration der In-Memory Option, indem es die optimale Größe des In-Memory Column Stores berechnet und die Datenbankobjekte auflistet, die von der In-Memory Option am meisten profitieren. Der Advisor kann bereits in einer Oracle DB 11g ausgeführt werden. Die Handhabung ist trivial, wie diese Präsentation zeigt.

Advertisements

15 Basisbefehle für Oracle DB 12c

  1. Welche Oracle Datenbanken sind auf meinem Server vorhanden?
    Wie heißen die Datenbanken? In welchem Oracle Home Verzeichnis laufen die Datenbanken?

    $ more /etc/oratab

    Die Ausgabe hat die Form ORACLE_SID:ORACLE_HOME:N|Y

  2. Verbindung zu einer Datenbankinstanz als SYSDBA aufbauen:
    $ . oraenv
    ORACLE_SID = [oracle] ? cdb1
    The Oracle base has been set to /u01/app/oracle
    $ sqlplus / as sysdba

    Mit der Utility oraenv werden die Umgebungsvariablen ORACLE_SID (hier cdb1) und ORACLE_HOME interaktiv gesetzt. Syntax: {Punkt}{Leerzeichen}oraenv

  3. Datenbank starten und öffnen (erforderlich, falls die Meldung „Connected to an idle instance“ erscheint)
    sql> startup
  4. Ist meine Datenbank eine Multitenant Container Datenbank (CDB) oder eine Non-CDB?
    sql> select name, cdb, con_id from v$database;
  5. Welche Container sind in meiner CDB definiert?
    Alle Container (Root Container und Pluggable Databases):

    sql> select name, con_id, open_mode from v$containers;  

    Nur Pluggable Databases (PDBs):

    sql> select name, con_id, open_mode from v$pdbs;  
    sql> show pdbs
  6. Mit welchem Container bin ich aktuell verbunden?
    sql> show con_name  
    sql> show con_id
  7. Redo Log Files der CDB
    sql> col member format a40
    sql> select group#, con_id, member from  v$logfile;  
  8. Control Files der CDB
    sql> col name format a60
    sql> select name, con_id from v$controlfile;
  9. Data Files der CDB
    sql> col name format a50
    sql> select file#, name, con_id from v$datafile order by con_id; 
  10. Tablespaces der CDB
    sql> col name format a8
    sql> select ts#, name, con_id from v$tablespace order by con_id; 

    Tablespaces und dazugehörige Data Files

    sql> col file_name format a50
    sql> col tablespace_name format a8
    sql> select ts.name tablespace_name, df.name file_name, df.con_id from v$datafile df, v$tablespace ts where df.ts#=ts.ts# and df.con_id=ts.con_id order by df.con_id;
  11. Alle User der CDB („common user“ und „local user“)
    sql> col username format a30
    sql> select username, common, con_id from cdb_users order by con_id;
  12. Eine PDB öffnen
    sql> alter pluggable database pdb1 open; 
    sql> alter pluggable database all open;
  13. Verbindung zu einer PDB als User SYSTEM aufbauen
    $ sqlplus system/pw@hostname:port/pdb

    z.B.

    $ sqlplus system/oracle@localhost:1521/pdb1

    Statt dem Easy Connect String „hostname:port/service“ kann ein Net Service Name angegeben werden, der vorher in tnsnames.ora definiert wurde.

  1. CDB herunterfahren
    sql> shutdown immediate
  2. Listener-Status und verfügbare DB-Services
    $ lsnrctl status

Oracle Database In-Memory Option

Oracle Database In-Memory ist in aller Munde. Erste-Hand-Informationen finden Sie im In-Memory Whitepaper, in der Oracle Dokumentation und im Product Management Blog. In diesem Beitrag werden einige häufig gestellte Fragen beantwortet.

1. Ist Oracle Database In-Memory eine neue Datenbank?
Nein. Die Oracle Database In-Memory Option ist eine Erweiterung der Oracle Datenbank (DB), verfügbar in der Enterprise Edition ab Version 12.1.0.2. Sie ist kompatibel mit allen Features der Oracle DB wie RAC, Data Guard, Advanced Security u.a.

2. Basiert die Oracle DB In-Memory Option auf TimesTen?
Nein. Oracle DB In-Memory ist eine komplett neue DB-Technologie. (TimesTen bleibt als eigenständige Datenbank sowie als Cache für die Oracle Datenbank – unter dem neuen Produktnamen „Oracle TimesTen Application-Tier Database Cache“ – weiterhin erhalten)

3. Wofür brauche ich die Oracle DB In-Memory Option?
Für Hochgeschwindigkeitsabfragen, um Auswertungen im analytischen oder im transaktionalen Umfeld zu beschleunigen.

4. Brauche ich neue Hardware für die Oracle DB In-Memory Option?
Nein. Die Oracle DB In-Memory Option kann auf jeder Hardwareplattform betrieben werden, auf der die Oracle DB 12.1.0.2 (und höher) zertifiziert ist.

5. Wie wird die Oracle DB In-Memory Option installiert?
Bei der Installation der Oracle DB 12.1.0.2 (und höher) wird die Oracle DB In-Memory Option automatisch installiert. Es ist keine zusätzliche Installation erforderlich.

6. Wie aktiviere ich die Oracle DB In-Memory Option für meine Datenbank?
Nach der Installation der Oracle Datenbank ist die In-Memory Option inaktiv. Das lässt sich an dem Datenbankparameter inmemory_size = 0 erkennen.

Die In-Memory Option benötigt einen dedizierten Hauptspeicherbereich (In-Memory Column Store), in dem die Daten im Spaltenformat abgelegt werden. Um die In-Memory Option zu aktivieren, müssen Sie 1. dem In-Memory Column Store Speicher zuweisen und 2. die Datenbank neustarten, wie in diesem Beispiel:

sql> alter system set inmemory_size = 10G scope=spfile;
sql> shutdown immediate;
sql> startup;

Der In-Memory Column Store wird im Oracle Hauptspeicher (System Global Area, SGA) erzeugt. Da die SGA auch für andere Zwecke benötigt wird, sollten Sie die Gesamtgröße der SGA überprüfen und ggf. anpassen. Initialisierungsparameter sga_target.

7. Wie verwende ich die In-Memory Option?
Die Handhabung der In-Memory Option ist sehr einfach. Sie müssen der Datenbank nur mitteilen, welche Datenbankobjekte in den In-Memory Column Store geladen werden sollen, wie in diesem Beispiel:

sql> alter table sales.customers inmemory;

Die In-Memory Option lässt sich für einzelne Tabellen, Partitionen, Tablespaces und Materialized Views einschalten. Der Oracle Optimizer kennt den In-Memory Column Store und nutzt ihn automatisch, jedes Mal wenn eine Datenbankabfrage davon profitiert.

8. Welche Tabellen befinden sich im In-Memory Column Store?
Die View v$im_segments gibt Auskunft über den Inhalt des In-Memory Column Stores:

sql> select v.owner, v.segment_name, v.populate_status from v$im_segments;

9. Muss die gesamte DB in den Hauptspeicher passen um Oracle DB In-Memory Option zu nutzen?
Nein. Mit der In-Memory Option bestimmen Sie selbst, welche Tabellen in den In-Memory Column Store geladen werden. Oracle vertritt die Ansicht, dass es nicht erforderlich ist, die gesamte Datenbank im teuren Hauptspeicher zu halten (meistens werden nur einige wenige Tabellen aktiv genutzt bzw. sind performancekritisch für Ihre Applikation).

Stattdessen implementiert Oracle ein mehrschichtiges Speichermodell, bei dem die Daten, in Abhängigkeit von der tatsächlichen Nutzung, auf unterschiedlichen Storage-Ebenen gespeichert werden. Die „heißen“ Daten (häufig im Zugriff) liegen im Hauptspeicher, die aktiven Daten (seltener abgefragt) liegen auf SSD, die “kalten“ (älteren) Daten liegen auf Festplatte. Eine SQL-Abfrage kann auf alle Daten transparent zugreifen.

10. Muss ich meinen Hauptspeicher verdoppeln um die Oracle DB In-Memory Option nutzen zu können?
Nein. Sie können dem In-Memory Column Store so viel oder so wenig Speicher zuweisen, wie Sie es möchten (die Mindestgröße beträgt 100 MB). Je größer der In-Memory Column Store, desto mehr Daten können darin vorgehalten werden. Um den verfügbaren Speicher maximal zu nutzen, können die Daten komprimiert werden.

11. Werden durch die In-Memory Option 4 Kopien meiner Daten erzeugt?
Nein. Die Behauptung, man bräuchte 4 Kopien der Daten, ist schlichtweg falsch. Die Oracle Datenbank speichert eine Kopie der Daten auf Festplatte (Zeilenformat). Eine kleine Untermenge der Daten – die aktivsten Zeilen, die häufig im Zugriff sind – werden zur Steigerung der Performance im Hauptspeicher im sog. Buffer Cache vorgehalten (Zeilenformat). Mit der In-Memory Option können einige DB-Objekte in den In-Memory Column Store geladen werden  (Spaltenformat). Die Daten, die im In-Memory Column-Store vorliegen, müssen nicht zwingend im Buffer Cache vorhanden sein und umgekehrt.

12. Kann eine Tabelle sowohl im Zeilen- als auch im Spaltenformat vorliegen?
Ja. Die gleiche Tabelle kann im Hauptspeicher sowohl im Buffer Cache (Zeilenformat) als auch im In-Memory Column Store (Spaltenformat) vorliegen. Die DB sorgt für die transaktionale Konsistenz der beiden Repräsentationen.

13. Wird der In-Memory Column Store auf Festplatte gespeichert?
Nein. Die Daten liegen auf Festplatte, wie bisher, im Zeilenformat vor. Die spaltenbasierte Repäsentation gibt es nur im Hauptspeicher.

14. Wann wird der Buffer Cache, wann der In-Memory Column Store verwendet?
Der Optimizer entscheidet automatisch, welcher Speicherbereich für die SQL-Ausführung genutzt wird. Liegen die Daten im Hauptspeicher sowohl im Zeilen- als auch im Spaltenformat vor, werden analytische Abfragen gegen den Column Store ausgeführt. Änderungsoperationen laufen gegen den Buffer Cache.

15. Muss meine Applikation agepasst werden, um die In-Memory Option nutzen zu können?
Nein. Die Oracle DB In-Memory Option wird auf DB-Ebene konfiguriert. Die Applikation muss nicht angepasst werden.

16. Für welche Applikationen eignet sich die Oracle DB In-Memory Option?
Die Oracle DB In-Memory Option erhöht die Performance von analytischen Abfragen.

Da die meisten Analysen in DWH-Umgebungen vorkommen, werden diese Umgebungen von der In-Memory Option am meisten profitieren.

Aber auch OLTP-Umgebungen (z.B. ERP-Applikationen) profitieren von der In-Memory Option, denn auch hier finden Auswertungen statt. Bis jetzt waren analytische Indizes erforderlich um transaktionale Daten performant abzufragen und zu durchsuchen. Der negative Nebeneffekt von analytischen Indizes ist, dass sie bei jeder Datenänderung aktualisiert werden müssen, was den OLTP-Betrieb insgesamt verlangsamt. Nun können analytische Indizes zugunsten der In-Memory Option entfernt werden.

17. Was passiert mit den Daten aus dem In-Memory Column Store nach einem unerwarteten Ausfall des DB-Servers?
Wenn Sie Ihre Datenbank als Single Instance betreiben (Non-RAC), muss der In-Memory Column Store nach einem Datenbankausfall neu befüllt werden. Je nach Datenmenge, kann dieser Vorgang unterschiedlich lange dauern. Aber: während der In-Memory Column Store befüllt wird, ist die Datenbank aktiv und kann genutzt werden. Analytische Abfragen werden ggf. länger dauern (weil manche Daten von der Festplatte geholt werden müssen) aber sie funktionieren. Im Gegensatz dazu, ist eine reine In-Memory Datenbank nicht zugänglich, bis die gesamte Datenbank im Hauptspeicher vorliegt.

Um Ausfallzeiten und Verzögerungen zu minimieren, können Sie Ihre Datenbanken als RAC betreiben. Im RAC hat jede Datenbankinstanz ihren eigenen In-Memory Column Store. Eine Tabelle kann in mehreren Column Stores als Kopie vorliegen. Bei Ausfall einer Datenbankinstanz wird der In-Memory Column Store einer anderen DB-Instanz genutzt.

18. Welche Komprimierungsmöglichkeiten gibt es?
Beim Laden in den In-Memory Column Store können die Daten komprimiert werden. Die 5 Komprimierungsalgorithmen (memcompress for dml, memcompress for query low | high, memcompress for capacity low | high) unterscheiden sich in der Komprimierungsrate und in der Abfrageperformance. Hier sind die Details.

19. Wird Exadata durch den Einsatz der Oracle DB In-Memory Option überflüssig?
Nein, Exadata und die In-Memory Option ergänzen sich sehr gut. Exadata ist die beste Pattform um eine Oracle DB mit In-Memory Option zu betreiben. Als Komplettsystem beinhaltet Exadata alle HW- und SW-Komponenten, die für einen ausfallsicheren Oracle Datenbankcluster erforderlich sind. Das System ist von Oracle vorkonfiguriert, gestetet und optimiert für maximale Performance.

Unidirektionale Replikation zwischen einer Oracle und einer MySQL Datenbank mit Hilfe von Oracle GoldenGate: eine Anleitung

1. Einführung
2. Die Demo-Umgebung, Ablauf der Demo
3. Oracle Beispieldaten erzeugen
4. MySQL Datenbank erzeugen (Tabellendefinition, keine Daten)
5. Installation von Oracle GoldenGate
    5.1. Installation von Oracle GoldenGate für Oracle
    5.2. Installation von Oracle GoldenGate für MySQL
6. Vorbereitung der Oracle Datenbank
    6.1. Datenbankbenutzer für Oracle GoldenGate anlegen
    6.2. Oracle Datenbank in den Archivelog Modus versetzen (optional)
    6.3. Supplemental Logging einschalten
7. Vorbereitung der MySQL Datenbank
    7.1. Datenbankbenutzer für Oracle GoldenGate anlegen
8. Oracle GoldenGate Vorbereitung
    8.1. Checkpoint Tabelle in der MySQL Datenbank anlegen
    8.2. Datendefinitionen auf dem Quellsystem generieren und ans Zielsystem übertragen
    8.3. Manager Prozess auf Quell- und Zielsystem konfigurieren und starten
9. Initial Load
    9.1. Initial Load auf dem Oracle Quellserver konfigurieren
    9.2. Initial Load auf dem MySQL Zielserver konfigurieren
    9.3. Initial Load durchführen
    9.4. Initial Load testen
10. Dauerhafte Synchronisation
    10.1  Synchronisation auf dem Oracle Quellserver konfigurieren
    10.2. Synchronisation auf dem MySQL Zielserver konfigurieren
    10.3. Synchronisation starten
    10.4. Synchronisation testen
11. Fazit
12. Quellen und weitere Informationen

1. Einführung

Seit der Akquise im Jahr 2009 ist Oracle GoldenGate die Nummer 1 Replikationslösung von Oracle und der strategische Nachfolger von Oracle Streams.

Oracle GoldenGate repliziert Daten auf Transaktionsebene, bei Bedarf zwischen unterschiedlichen Datenbanken. Es unterstützt eine Vielzahl von Datenbankmanagementsystemen und –versionen und unterschiedliche Plattformen: Oracle Database, Microsoft SQL Server, IBM DB2, Sybase, MySQL, PostgreSQL u.a. (für die komplette Liste der unterstützten Datenbank-/Plattform-Kombinationen siehe http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html).

Oracle GoldenGate kann für zwei Zwecke verwendet werden:

  1. Initial Load. Dabei wird eine leere Zieldatenbank mit den Daten einer Quelldatenbank befüllt. Oracle GoldenGate kann als Ladewerkzeug im Kontext von Datenbankumzügen oder -migrationen (auch im heterogenen Umfeld) in Betracht gezogen werden.
  2. Dauerhafte Synchronisation. Das Haupteinsatzgebiet von Oracle GoldenGate besteht darin, zwei Datenbanken auf dem gleichen Stand zu halten. Sobald die Quelldatenbank verändert wird, werden die Änderungen auf das Zielsystem übertragen und dort bereitgestellt. Man kann für eine exakte Kopie der Daten sorgen oder die Daten transformieren, je nachdem ob die Datenstrukturen des Quell- und Zielsystems identisch oder unterschiedlich sind. In den meisten Fällen werden Änderungen repliziert, die durch DML Operationen hervorgerufen werden (INSERT, UPDATE, DELETE eines Datensatzes). Für bestimmte Datenbanken können auch DDL Operationen, also Änderungen an der Datenstruktur, repliziert werden.

Oracle GoldenGate kann in einer Vielzahl von Topologien eingesetzt werden: one-to-one (eine Datenbank repliziert Änderungen an eine andere Datenbank), many-to-one (mehrere Datenbanken replizieren Änderungen an eine zentrale Datenbank), one-to-many (eine Datenbank repliziert Änderungen an mehrere Zieldatenbanken, u.U. in  verschiedenen Rechenzentren), in bidirektionalen und Multi-Master Konfigurationen (bei denen die Datenbanken gleichzeitig aktiv genutzt werden).

In diesem Artikel wird gezeigt, wie man eine einfache unidirektionale Replikation zwischen einer Oracle Quelldatenbank und einer MySQL Zieldatenbank konfigurieren kann.

2. Die Demo-Umgebung, Ablauf der Demo

Ich verwende eine virtuelle Maschine (Oracle VirtualBox) mit 2 CPUs, 4 GB Arbeitsspeicher und Oracle Linux 6.4 64-Bit. Die Oracle Datenbank 11.2.0.3 Enterprise Edition und MySQL Server 5.5.25a Enterprise Edition sind darin bereits installiert. Der Einfachheit halber befinden sich beide Datenbanken auf demselben Server (in der Praxis werden die Datenbankserver häufig auf getrennten Maschinen laufen).

Zunächst erzeugen wir in der Oracle Datenbank die Beispieltabelle warehouse.catalog und füllen sie mit Inhalt. Die Tabelle stellt ein vereinfachtes Produktkatalog eines zentralen Warenlagers dar.

WAREHOUSE.CATALOG
PROD_ID NAME PRICE CURRENCY
111111 Canon EOS 700D 569.50 EUR
222222 Panasonic Lumix DMC-G6 579.10 EUR
333333 Sony Alpha 58 404.81 EUR

Als nächstes erzeugen wir die leere MySQL Tabelle filiale.artikel mit einer leicht veränderten Datenstruktur. Sie soll den stark vereinfachten Warenbestand einer Filiale darstellen.

FILIALE.ARTIKEL
ARTIKEL_ID NAME EUR

Nach der Installation von Oracle GoldenGate 11.2.1 und den vorbereitenden Schritten auf der Quell- und Zieldatenbank, wird der Ladeprozess konfiguriert, um die Oracle Daten in die leere MySQL Datenbank zu importieren.

Anschließend konfigurieren wir den Synchronisationsmodus, um beide Datenbanken auf dem gleichen Stand zu halten.

3. Oracle Beispieldaten erzeugen

Ich verwende SQL*Plus, um in der Oracle Datenbank das Schema warehouse, die Tabelle catalog und ein paar Beispieldaten anzulegen. Dafür folgende SQL-Befehle in einen Texteditor kopieren und unter dem Namen setup_oracle.sql speichern.

-- setup_oracle.sql
-- create and populate sample schema in Oracle Database

create tablespace warehouse_ts
datafile '/u01/app/oracle/oradata/ORCL/datafile/warehouse_01.dbf'
size 100m autoextend on extent management local segment space management auto;

create user warehouse identified by welcome1 default tablespace warehouse_ts
quota unlimited on warehouse_ts;

grant connect, resource to warehouse;

create table warehouse.catalog
(
	prod_id varchar2(6),
	name varchar2(30),
	price number(8,2),
	currency varchar2(3),
	primary key (prod_id)
);

insert into warehouse.catalog values ('111111', 'Canon EOS 700D', 569.50, 'EUR');
insert into warehouse.catalog values ('222222', 'Panasonic Lumix DMC-G6', 579.10,
'EUR');
insert into warehouse.catalog values ('333333', 'Sony Alpha 58', 404.81, 'EUR');
commit;

Dann das Skript mit SQL*Plus ausführen:

[oracle@source ~]$ sqlplus sys/welcome1 as sysdba @setup_oracle.sql
4. MySQL Datenbank erzeugen (Tabellendefinition, keine Daten)

Auf dem MySQL-Server erstellen wir eine neue Datenbank mit dem Namen filiale. Darin definieren wir die Tabelle artikel mit einer leicht veränderten Struktur als die Tabelle catalog aus der Oracle Datenbank (weniger Spalten, andere Spaltennamen). Die notwendigen SQL-Befehle kann man in eine Textdatei kopieren und über den MySQL Client ausführen:

[mysql@target ~]$ mysql –uroot –pwelcome1 < setup_mysql.sql
-- setup_mysql.sql
-- create new database and one table in MySQL

create database filiale;
create user 'filialeadmin'@'%' identified by 'welcome1';
grant all privileges on filiale.* to ' filialeadmin'@'%' with grant option;
flush privileges;

create table filiale.artikel
(
	artikel_id varchar(6),
	name	varchar(40),
	eur   decimal(8,2),
	primary key (artikel_id)
);
5. Installation von Oracle GoldenGate

Wir werden Oracle GoldenGate zweimal installieren: Oracle GoldenGate for Oracle auf dem Quellserver und Oracle GoldenGate for MySQL auf dem Zielserver.

5.1. Installation von Oracle GoldenGate für Oracle

Laut Dokumentation ist es ratsam, einen dedizierten Betriebssystembenutzer für Oracle GoldenGate anzulegen. Oracle GoldenGate wird über diesen User installiert und ausgeführt. In diesem Beispiel soll der Oracle GoldenGate-User auf dem Oracle Server oggoracle heißen.

oggoracle wird den Betriebssystemgruppen oinstall  (Oracle Inventory Eigentümer) und dba (Datenbankadministratoren) zugewiesen. Letzteres stellt sicher, dass oggoracle die Redo Log Files der Datenbank lesen kann, wenn der Extract Prozess im Classic Capture Modus konfiguriert wird. Als root-User folgende Befehle ausführen:

[root@source ~]# /usr/sbin/useradd -g oinstall -G dba oggoracle
[root@source ~]# passwd oggoracle

Das Installationsverzeichnis für Oracle GoldenGate soll in diesem Beispiel /u01/app/oggoracle sein, analog zum OFA-Basisverzeichnis der Oracle Datenbank /u01/app/oracle.

[root@source ~]# mkdir -p /u01/app/oggoracle
[root@source ~]# chown -R oggoracle:oinstall /u01/app/oggoracle
[root@source ~]# chmod -R 775 /u01/app/oggoracle

Als nächstes müssen ein paar Umgebungsvariablen gesetzt werden. Dafür in den oggoracle Benutzerkontext wechseln und die .bash_profile-Datei um folgende Zeilen ergänzen:

[root@source ~]# su – oggoracle
[oggoracle@source ~]$ vi $HOME/.bash_profile
# .bash_profile
# … (other variables)
OGG_ORACLE_HOME=/u01/app/oggoracle; export OGG_ORACLE_HOME
ORACLE_HOME=/u01/app/oracle/product/11.2/db_1; export ORACLE_HOME
ORACLE_SID=orcl; export ORACLE_SID
LD_LIBRARY_PATH=$ORACLE_HOME/lib:$OGG_ORACLE_HOME:/lib:/usr/lib; export LD_LIBRARY_PATH

Wir müssen nur noch die Umgebungsvariablen für die aktive Shell setzen:

[oggoracle@source ~]$ . $HOME/.bash_profile

Die Installationsdateien von Oracle GoldenGate 11.2.1 für Oracle können von edelivery.oracle.com heruntergeladen werden. Man findet sie unter Product Pack Oracle Fusion Middleware, Plattform Linux x86-64, Oracle GoldenGate for Oracle v11.2.1 Media Pack for Linux x86-64.

01

Die Installation von Oracle GoldenGate besteht aus zwei Schritten. Wir entpacken zuerst als oggoracle-User das heruntergeladene zip-Archiv ins OGG_ORACLE_HOME Verzeichnis.

[oggoracle@source OGG_ORACLE_HOME]$ unzip V34339-01.zip
[oggoracle@source OGG_ORACLE_HOME]$ tar -xvf fbo_ggs_Linux_x64_ora11g_64bit.tar

Als nächstes starten wir die Kommandozeilenschnittstelle von Oracle GoldenGate ggsci (steht für GoldenGate Software Command Line Interface) und erzeugen die Arbeitsverzeichnisse.

[oggoracle@source OGG_ORACLE_HOME]$ ./ggsci
GGSCI (source) 1>  create subdirs
GGSCI (source) 2>  exit
5.2. Installation von Oracle GoldenGate für MySQL

Die Installation von Oracle GoldenGate für MySQL verläuft ähnlich wie die Installation von Oracle GoldenGate für Oracle. Wir benötigen einen dedizierten Betriebssystembenutzer. In diesem Beispiel heißt der User oggmysql. Er gehört zur Gruppe mysql, wie der Benutzer, mit dem der MySQL Server installiert wurde.

[root@target ~]# /usr/sbin/useradd –g oinstall –G mysql oggmysql
[root@target ~]# passwd oggmysql

Das Home Verzeichnis der Oracle GoldenGate Installation auf dem MySQL Server in diesem Beispiel ist /u01/app/oggmysql.

[root@target ~]# mkdir -p /u01/app/oggmysql
[root@target ~]# chown -R oggmysql:oinstall /u01/app/oggmysql
[root@target ~]# chmod -R 775 /u01/app/oggmysql

Wir setzen ein paar Umgebungsvariablen für den oggmysql User am Ende der .bash_profile-Datei:

[oggmysql@target ~]$ vi $HOME/.bash_profile
# .bash_profile
# … (other variables)
OGG_MYSQL_HOME=/u01/app/oggmysql; export OGG_MYSQL_HOME
MYSQL_HOME=/etc; export MYSQL_HOME
LD_LIBRARY_PATH=$OGG_ MYSQL_HOME:/lib:/usr/lib; export LD_LIBRARY_PATH

MYSQL_HOME ist der Pfad zur MySQL Server Konfigurationsdatei my.cnf.

Mit dem folgenden Befehl werden die Umgebungsvariablen für die aktive Shell gesetzt:

[oggmysql@target ~]$ . $HOME/.bash_profile

Die Installationsdateien von Oracle GoldenGate für MySQL 5.x auf Linux x86-84 befinden sich auf edelivery.oracle.com in der Produktkategorie Oracle Fusion Middleware, Plattform Linux x86-64, Oracle GoldenGate for Non Oracle Database v11.2.1 Media Pack for Linux x86-64.

Wir melden uns als User oggmysql bei dem Betriebssystem des Zielrechners an und entpacken das Installationsarchiv im Ordner OGG_MYSQL_HOME.

[oggmysql@target OGG_MYSQL_HOME]$ unzip V32399-01.zip
[oggmysql@target OGG_MYSQL_HOME]$ tar -xvf ggs_Linux_x64_MySQL_64bit.tar

Als nächstes starten wir ggsci und erzeugen die Arbeitsverzeichnisse für Oracle GoldenGate auf dem Zielsystem:

[oggmysql@target OGG_MYSQL_HOME]$ ./ggsci
GGSCI (target) 1> create subdirs
GGSCI (target) 2> exit

Die Installation von Oracle GoldenGate ist nun abgeschlossen.

6. Vorbereitung der Oracle Datenbank
6.1. Datenbankbenutzer für Oracle GoldenGate anlegen

Oracle GoldenGate benötigt einen dedizierten Datenbankbenutzer in der Oracle Datenbank, in erster Linie um auf Metadaten zuzugreifen.  Die notwendigen Berechtigungen sind im Installation and Setup Guide Abschnitt 4.6. aufgeführt. In diesem Beispiel soll der DB-User oggsrc heißen.

[oracle@source ~]$ sqlplus sys/welcome1 as sysdba
sql> create tablespace oggsrc_ts
datafile '/u01/app/oracle/oradata/ORCL/datafile/oggsrc_01.dbf'
size 100m autoextend on extent management local segment space management auto;
sql> create user oggsrc identified by welcome1 default tablespace oggsrc_ts
quota unlimited on oggsrc_ts;
sql> grant create session, alter session, resource, connect to oggsrc;
sql> grant select any dictionary, flashback any table, select any table to oggsrc;
sql> grant execute on dbms_flashback to oggsrc;
6.2. Oracle Datenbank in den Archivelog Modus versetzen (optional)

Archive Logging ist keine Voraussetzung für die Nutzung von Oracle GoldenGate, sondern vielmehr eine empfohlene Sicherheitsmaßnahme. Wenn die Oracle Datenbank im Archivelog Modus betrieben wird, kann Oracle GoldenGate die Archived Redo Logs verwenden, sollten die benötigten Online Redo Logs nicht mehr vorhanden sein. Ansonsten kann es zu Unterbrechungen im Oracle GoldenGate Betrieb kommen.

Wir prüfen, ob die Datenbank im Archivelog-Modus betrieben wird:

[oracle@source ~]$ sqlplus sys/welcome1 as sysdba
sql> select log_mode from v$database;

Falls noarchivelog ausgegeben wird, versetzen wir die Datenbank in den Archivelog-Modus. Bei dieser Operation wird der Datenbankbetrieb kurzzeitig unterbrochen.

sql> shutdown immediate;
sql> startup mount;
sql> alter database archivelog;
sql> alter database open;
6.3. Supplemental Logging einschalten

Oracle GoldenGate versucht die Datensätze auf dem Quellsystem den entsprechenden Datensätzen auf dem Zielsystem eindeutig zuzuordnen. Dafür müssen zwei Voraussetzungen erfüllt sein:

    1. Die Tabellen, die an der Replikation beteiligt sind, müssen über eindeutige Datensätze verfügen. Oracle GoldenGate verwendet standardmäßig den Primärschlüssel als Zeilen-ID. In Abwesenheit eines Primärschlüssels wird die erste Spalte mit einem UNIQUE KEY Attribut gewählt. Falls keine solche Spalte existiert, konstruiert GoldenGate einen Pseudoschlüssel aus allen Spalten der Tabelle. Man kann auch einen eigenen Schlüssel aus Spalten mit eindeutigen Werten definieren. In unserem Beispiel hat die Tabelle warehouse.catalog den Primärschlüssel prod_id.
    2.  Bei jeder Update-Operation muss der Schlüsselwert der Zeile in die Redo Logs protokolliert werden. Dafür muss das sog. Supplemental Logging auf Datenbank- und Tabellenebene eingeschaltet werden.

Das Supplemental Logging auf Datenbankebene wird über folgende Befehle aktiviert:

[oracle@source ~]$ sqlplus sys/welcome1 as sysdba
sql> alter database add supplemental log data;
sql> alter system switch logfile;

Wenn das Supplemental Logging erfolgreich eingeschaltet wurde, wird die nächste Abfrage YES oder IMPLICIT ausgeben:

sql> select supplemental_log_data_min from v$database;

Das Supplemental Logging für die Tabelle warehouse.catalog wird über die GoldenGate Kommandozeile eingeschaltet, von einem User, der das Recht hat, das Supplemental Logging einzuschalten. Der Befehl add trandata generiert im Hintergrund den passenden alter table ... add supplemental log data-Befehl für den Tabellenschlüssel (hier der Primärschlüssels prod_id).

[oggoracle@source OGG_ORACLE_HOME]$ ./ggsci
ggsci (source) 1> dblogin userid  sys, password welcome1 sysdba
ggsci (source) 2> add trandata warehouse.catalog

Zur Prüfung:

ggsci (source) 3> info trandata warehouse.*
7. Vorbereitung der MySQL Datenbank
7.1. Datenbankbenutzer für Oracle GoldenGate anlegen

Auf dem MySQL Server erstellen wir einen dedizierten Datenbankbenutzer für Oracle GoldenGate (oggtgt). Der User benötigt Zugriffsrechte auf die Zieltabellen, um die Datenänderungen zu übertragen (d.h. um native DML-Befehle abzusetzen).

Im weiteren Verlauf der Demo wird oggtgt auch die sog. Checkpoint Tabelle erstellen. Um die Oracle GoldenGate Daten von den Nutzerdaten zu trennen, kann man eine separate MySQL Datenbank erzeugen (hier oggdb), in der die Checkpoint Tabelle angelegt werden kann.

[mysql@target ~]$ mysql –uroot –pwelcome1
mysql> create user 'oggtgt'@'%' identified by 'welcome1';
mysql> grant insert, update, delete, select on filiale.* to 'oggtgt'@'%';
mysql> create database oggdb;
mysql> grant all privileges on oggdb.* to 'oggtgt'@'%' with grant option;
mysql> flush privileges;
8. Oracle GoldenGate Vorbereitung
8.1. Checkpoint Tabelle in der MySQL Datenbank anlegen

Oracle GoldenGate verwendet Checkpoints um die aktuelle Lese- und Schreibposition der Extract- und Replicat-Prozesse zu speichern. Checkpoints stellen sicher, dass die Prozesse nach einer Unterbrechung (z.B. aufgrund eines Netzwerkfehlers) verlustfrei wieder anlaufen und verhindern dass Transaktionen mehrfach ausgeführt werden.

Der Replicat-Prozess speichert seine Checkpoints in einer Tabelle in der Zieldatenbank. Die Checkpoint Tabelle muss in der globalen Konfigurationsdatei von Oracle GoldenGate bekannt gemacht werden. Diese Datei heißt GLOBALS (Großschreibung wichtig!) und liegt im  OGG_MYSQL_HOME Verzeichnis. Falls GLOBALS noch nicht existiert, legen wir sie über den edit params-Befehl an:

[oggmysql@target OGG_MYSQL_HOME]$ ./ggsci
ggsci (target) 1>  edit params ./GLOBALS
-- GLOBALS
-- Oracle GoldenGate configuration file

checkpointtable oggdb.oggchkpt

Die Checkpoint-Tabelle selbst wird mit dem add checkpoint-Befehl erzeugt:

ggsci (target) 2> dblogin sourcedb oggdb@target:3306, userid oggtgt, password welcome1
ggsci (target) 2> add checkpointtable oggdb.oggchkpt

Wenn man sich mit dem MySQL Server lokal verbindet, kann u.U. der folgende Fehler auftreten:

WARNING OGG-00769 MySQL Login failed: . SQL error (2002). Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2).
ERROR: Failed to connect to MySQL database engine for HOST target, DATABASE oggdb, USER oggtgt, PORT 3306.

Die Ursache des Fehlers ist, dass Oracle GoldenGate (für MySQL) die mysql.sock-Datei im Ordner /tmp erwartet. Aktuelle RPM-Installationen von MySQL speichern die mysql.sock-Datei standardmäßig in /var/lib/mysql. Ein Workaround ist es, den MySQL Server zu stoppen, einen symbolischen Link auf /var/lib/mysql/mysql.sock im Ordner /tmp anzulegen, MySQL wieder zu starten und den dblogin Befehl zu wiederholen:

[root@target ~]# /etc/init.d/mysql stop
[root@target ~]# ln -s /var/lib/mysql/mysql.sock /tmp/mysql.sock
[root@target ~]# /etc/init.d/mysql start
8.2. Datendefinitionen auf dem Quellsystem generieren und ans Zielsystem übertragen

Wenn die Replikation zwischen unterschiedlichen Datenbanksystemen stattfindet oder wenn die Quell- und die Zieltabellen unterschiedliche Strukturen haben, muss Oracle GoldenGate eine Reihe von Konvertierungen vornehmen. Dafür benötigt es eine sog. Datendefinitionsdatei mit Metadaden zum Quellsystem. Die Definitionsdatei wird mit der defgen-Utility erzeugt.

Zuerst erzeugen wir eine leere Parameterdatei mit dem Befehl edit params. Die Datei wird automatisch im Verzeichnis OGG_ORACLE_HOME/dirprm gespeichert.

oggoracle@source OGG_ORACLE_HOME]$ ./ggsci
ggsci (source) 1> edit params defgen

Darin tragen wir die Tabellen ein, für die Datendefinitionen benötigt werden, und geben den Pfad an, wo die Definitionsdatei abgelegt werden soll.

-- defgen.prm
-- parameter file for defgen utility

defsfile /u01/app/oggoracle/dirdef/ora2mysql.def
userid oggsrc, password welcome1
table warehouse.catalog;

Wir rufen die defgen-Utililty von der Kommandozeile auf (nicht ggsci!):

[oggoracle@source OGG_ORACLE_HOME]$ ./defgen paramfile /u01/app/oggoracle/dirprm/defgen.prm

Wenn man sich ora2mysql.def mit einem Texteditor anzeigen lässt, findet man darin die Beschreibung der warehouse.catalog Tabelle in einem generischen Format.

Als nächstes kopieren wir die Datei ora2mysql.def auf das Zielsystem, in den Ordner OGG_MYSQL_HOME/dirdef. Der Replicat Prozess wird ora2mysql.def lesen und die darin enthaltenen generischen Datentypen in MySQL-spezifische Datentypen konvertieren.

8.3. Manager Prozess auf Quell- und Zielsystem konfigurieren und starten

Für jede Oracle GoldenGate Instanz benötigt man einen Manager Prozess. Der Manager Prozess kontrolliert alle GoldenGate Extract- und Replicat-Prozesse. In diesem Beispiel benötigen wir 2 Manager Prozesse, einen auf dem Quellsystem und einen auf dem Zielsystem.

Zunächst konfigurieren wir den Manager Prozess auf dem Oracle Server:

[oggoracle@source OGG_ORACLE_HOME]$ ./ggsci
ggsci (source) 1>  edit params mgr

Das einzige erforderliche Parameter ist die Nummer des Ports, auf dem der Manager Prozess laufen wird. Man kann dem Manager einen beliebigen freien Port zuweisen, in diesem Beispiel 7000.

-- mgr.prm
-- Manager parameter file on source server

PORT 7000

Wir starten den Manager-Prozess:

ggsci (source) 2> start mgr

Der folgende Befehl zeigt, ob der Manager Prozess erfolgreich gestartet wurde:

ggsci (source) 3> info mgr

Anschließend konfigurieren wir den Manager Prozess auf dem Zielserver und starten ihn auf Port 8000.

[oggmysql@target OGG_MYSQL_HOME]$ ./ggsci
ggsci (target) 1>  edit params mgr
-- mgr.prm
-- Manager parameter file on target server

PORT 8000
ggsci (target) 2>  start mgr
ggsci (target) 3>  info mgr
9. Initial Load

Es gibt verschiedene Methoden, eine leere MySQL Datenbank mit Oracle Daten zu befüllen. Auch Oracle GoldenGate kann für diesen Zweck verwendet werden. Der Extract Prozess liest Datensätze direkt aus den Oracle Tabellen und übergibt sie an den Replicat Prozess. Der Replicat Prozess fügt sie über INSERT-Anweisungen in die MySQL-Tabellen ein.

Schematisch kann der Initial Load Prozess folgendermaßen dargestellt werden:

initial_load

9.1. Initial Load auf dem Oracle Quellserver konfigurieren

Wir beginnen mit der Konfiguration des Initial Load Extracts auf dem Oracle Server. Der Prozess soll ora_eini heißen, eine Abkürzung für oracle extract initial load. Zuerst erstellen wir für ora_eini eine Parameterdatei:

[oggoracle@source OGG_ORACLE_HOME]$ ./ggsci
ggsci (source) 1> edit params ora_eini

Der Inhalt der Parameterdatei ist wie folgt:

-- ora_eini.prm
-- initial load capture for source Oracle tables

extract ora_eini
userid oggsrc, password welcome1
rmthost target, mgrport 8000
rmttask replicat, group mys_rini
table warehouse.catalog;

Der Oracle GoldenGate User oggsrc meldet sich bei der Oracle Datenbank mit den Daten aus userid und password an. rmthost und mgrport geben den Zielserver und den Port an, auf dem der entfernte Manager Prozess läuft. rmttask veranlasst den Extract Prozess, einen Initial Load Replicat auf dem Zielsystem automatisch zu starten.

Der Extract Prozess muss registriert werden:

ggsci (source) 2> add extract ora_eini, sourceistable

sourceistable besagt, dass die Daten aus den Tabellen der Oracle Datenbank (und nicht aus den Redo Logs) ausgelesen werden sollen. Das ist das gewüschte Verhalten für den Initial Load Extract.

Somit ist die Konfiguration auf dem ersten Server abgeschlossen.

9.2. Initial Load auf dem MySQL Zielserver konfigurieren

Der Replicat Prozess auf dem MySQL Server soll mys_rini heißen ( myssql, replicat, initial load). Die Parameterdatei hat folgenden Inhalt:

[oggmysql@target OGG_MYSQL_HOME]$ ./ggsci
ggsci (target) 1> edit params mys_rini
-- mys_rini.prm
-- initial load delivery for target MySQL tables

replicat mys_rini
sourcedb filiale@target:3306, userid oggtgt, password welcome1
sourcedefs /u01/app/oggmysql/dirdef/ora2mysql.def
map warehouse.catalog, target filiale.artikel, colmap (USEDEFAULTS, artikel_id=PROD_ID, eur=PRICE);

Der Replicat Prozess meldet sich über den User oggtgt bei der MySQL Datenbank an. Der sourcedefs Parameter weist den Replicat Prozess an, dass eine Datenkonvertierung vorzunehmen ist. Der Parameter map zeigt, wie die Quelltabelle auf die Zieltabelle abgebildet werden soll.

Der Replicat Prozess muss nur noch beim Oracle GoldenGate Manager registriert werden:

ggsci (target) 2> add replicat mys_rini, specialrun

specialrun besagt, dass der Initial Load Replicat nur einmal ausgeführt wird: ist die MySQL Datenbank mit dem Inhalt der Oracle Datenbank einmal befüllt, soll der Prozess beendet werden.

Die GoldenGate Prozesse sind nun vorbereitet.

9.3. Initial Load durchführen

Wir starten den Initial Load Extract mit folgendem Befehl:

[oggoracle@source OGG_ORACLE_HOME]$ ./ggsci
ggsci (source) 1> start extract ora_eini

Der Replicat Prozess muss nicht explizit gestartet werden (er wird beim Initial Load automatisch ausgeführt).

9.4. Initial Load testen

Wir prüfen, ob die Tabelle filiale.artikel mit den gewünschten Datensätzen befüllt wurde:

[mysql@target ~]$ mysql -ufilialeadmin -pwelcome1 filiale
mysql> select * from filiale.artikel;

Am Ende des Initial Loads laufen die Extract und Replicat Prozesse nicht mehr. Folgender Befehl sollte den Extract Prozess im Zustand STOPPED zeigen:

[oggoracle@source OGG_ORACLE_HOME]$ ./ggsci
ggsci (source) 1> info extract ora_eini
10. Dauerhafte Synchronisation

Für die live Synchronisation der Oracle Datenbank mit MySQL müssen wir einen neuen Satz von Extract- und Replicat-Prozessen konfigurieren. Im Vergleich zu den Initial Load Prozessen, werden die neuen Prozesse dauerhaft laufen.

Folgendes Diagramm zeigt den Aufbau der Synchronisation.

synchronisation

10.1. Synchronisation auf dem Oracle Quellserver konfigurieren

Wir konfigurieren einen Extract Prozess, der Änderungen an Oracle Datensätzen erfasst. Seit Oracle GoldenGate 11.2.1 können Extract Prozesse für die Oracle Datenbank im Classic Capture Mode oder im Integrated Capture Mode konfiguriert werden. In diesem Beispiel wird der Extract Prozess im Classic Capture Mode konfiguriert. Das bedeutet, unter anderem, dass der Extract Prozess auf die Redo Logs der Oracle Datenbank zugreift, um Transaktionen zu erfassen.

[oggoracle@source OGG_ORACLE_HOME]$ ./ggsci
ggsci (source) 1> edit params ora_ext
-- ora_ext.prm
-- change synchronisation capture process

extract ora_ext
userid oggsrc, password welcome1
exttrail /u01/app/oggoracle/dirdat/lt
table warehouse.catalog;
ggsci (source) 2> add extract ora_ext, tranlog, begin now
ggsci (source) 3> add exttrail /u01/app/oggoracle/dirdat/lt, extract ora_ext

Der Parameter tranlog weist Oracle GoldenGate an, die Redo Logs der Datenbank zu lesen. Die aufgezeichneten Transaktionen werden in lokalen Dateien, den sog. Trail Files, zwischengespeichert. exttrail gibt den Pfad der Trail Files an und ein zweistelliges Präfix für den Dateinamen (hier lt für lokale Trails).  Der Dateiname wird mit weiteren 6 Ziffern automatisch ergänzt.

In einer klassischen Oracle GoldenGate Installation konfiguriert man (aus Gründen der Ausfallsicherheit) einen weiteren Extract Prozess auf dem Quellsystem, den sog. Data Pump. Er liest die lokalen Trail Files und sendet die Daten über das Netzwerk an das Zielsystem. Dort werden sie in Remote Trail Files gespeichert. In diesem Beispiel heißt der Data Pump Prozess ora_pmp und wird folgendermaßen konfiguriert:

ggsci (source) 4> edit params ora_pmp

-- ora_pmp.prm
-- change synchronisation data pump process

extract ora_pmp
rmthost target, mgrport 8000
rmttrail /u01/app/oggmysql/dirdat/rt
passthru
table warehouse.catalog;

passthru besagt, dass die Daten ohne Filterung oder sonstige Transformationen weitergeleitet werden sollen.
Als nächstes erzeugen wir den Prozess:

ggsci (source) 5> add extract ora_pmp, exttrailsource /u01/app/oggoracle/dirdat/lt
ggsci (source) 6> add rmttrail /u01/app/oggmysql/dirdat/rt, extract ora_pmp
10.2. Synchronisation auf dem MySQL Zielserver konfigurieren

Auf dem Zielsystem konfigurieren wir den Replicat Prozess mys_rep. Auch hier wird über die map-Klausel definiert, wie die Spalten des Oracle Datenbank auf die Spalten der MySQL Datenbank abgebildet werden.

[oggmysql@target OGG_MYSQL_HOME]$ ./ggsci
ggsci (target) 1> edit params mys_rep
-- mys_rep.prm
-- change synchronisation replicat process

replicat mys_rep
sourcedb filiale@target:3306, userid oggtgt, password welcome1
sourcedefs /u01/app/oggmysql/dirdef/ora2mysql.def

map warehouse.catalog, target filiale.artikel, colmap (USEDEFAULTS, artikel_id=PROD_ID, eur=PRICE);

Im letzten Schritt registrieren wir den Replicat Prozess bei dem Manager Prozess:

ggsci (target) 1> add replicat mys_rep, exttrail /u01/app/oggmysql/dirdat/rt
10.3. Synchronisation starten

Wir starten die Extract- und Data Pump-Prozesse auf dem Quellsystem:

ggsci (source) 1> start extract ora_ext
ggsci (source) 2> start extract ora_pmp

Auf der MySQL Maschine starten wir den Replicat Prozess:

ggsci (target) 1> start replicat mys_rep

Mit folgenden Befehlen kann man prüfen, ob die Prozesse korrekt laufen:

ggsci (source) 3> info extract *
ggsci (target) 2> info replicat *
10.4. Synchronisation testen

Beide Tabellen warehouse.catalog (Oracle) und filiale.artikel (MySQL) enthalten jeweils 3 Datensätze. Unter der Annahme, dass zwischenzeitlich keine Änderungen stattgefunden haben, melden wir uns bei der Oracle Datenbank an und fügen einen neuen Datensatz hinzu:

[oracle@source ~]$ sqlplus warehouse/welcome1
sql> insert into warehouse.catalog values ('444444', 'Nikon D3100', 259.99, 'EUR');
sql> commit;

Folgende MySQL Abfrage zeigt, dass GoldenGate die Daten erfolgreich repliziert hat:

[mysql@target ~]$ mysql -ufilialeadmin -pwelcome1 filiale
mysql> select * from filiale.artikel;

Herzlichen Glückwunsch! Ab jetzt wird die MySQL Datenbank zu jedem Zeitpunkt auf dem gleichen Stand wie die Oracle Datenbank sein.

11. Fazit

In diesem Artikel wurde anhand eines praktischen Beispiels die Basisfunktionalität von Oracle GoldenGate gezeigt. Zuerst wurden die Daten einer Oracle Datenbank in eine leere MySQL Datenbank geladen. Die MySQL Datenbank wurde daraufhin mit der Oracle Datenbank synchronisiert. Dieses Beispiel kann als Startpunkt verwendet werden, um weiterführende Oracle GoldenGate Funktionen auszuprobieren.

12. Quellen und weitere Informationen

Oracle GoldenGate Oracle Installation Guide
Oracle GoldenGate MySQL Installation Guide
Oracle GoldenGate Administrator’s Guide
Oracle GoldenGate Reference Guide

Oracle GoldenGate Youtube Channel

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.

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!

 

 

Welche Oracle Datenbankedition ist bei Ihnen im Einsatz?

Bei der Installation der Oracle Datenbanksoftware 11g gibt man die Edition (Enterprise Edition, Standard Edition oder Standard Edition One) an. Nachträgtlich hat man mehrere Möglichkeiten herauszufinden, welche Edition im Einsatz ist.

Eine Möglichkeit ist in die Global Inventory Logs  nachzuschauen (siehe My Oracle Support > Support Note ID 1341744.1). Den Pfad zur Global Inventory kann man je nach Plattform folgendermaßen finden:
– auf Linux und AIX in der Datei /etc/oraInst.loc (inventory_loc=<Pfad>)
– auf anderen UNIX Plattformen in der Datei /var/opt/oracle/oraInst.loc
– auf Windows als Wert des Registry Keys: HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\inst_loc
Die Installationslogs befinden sich im Unterverzeichnis logs der Global Inventory. Sie heißen auf allen Plattformen installActions<timestamp>.log. Meistens wird es mehrere Logdateien dieser Art geben; jede bezieht sich auf eine Installation oder ein Upgrade der Oracle Datenbanksoftware (eines Oracle Homes). Der Installationstyp ist im Abschnitt Global settings unter Database edition dokumentiert, z.B.:

--------------------------------------------------------------------------------
Global settings
--------------------------------------------------------------------------------
...
- Database edition : Standard Edition One (Install database software only)

Ein schneller Weg um herauszufinden ob man eine Enterprise Edition im Einsatz hat, ist sich einfach über SQL*Plus mit der Datenbank zu verbinden. Die SQL*Plus Ausgabe enthält im Regelfall einen Banner mit dem expliziten Hinweis auf die Enterprise Edition:

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

Bei Standard Edition und Standard Edition One sieht der SQL*Plus Banner gleich aus. Man kann leider auf diesem Weg zwischen den zwei Editionen nicht unterschieden:

Connected to:
Oracle Database 11g Release 11.2.0.3.0 - Production

Man kann sich die Information aus dem SQL*Plus Banner auch über folgende SQL-Abfrage ausgeben lassen:

select * from v$version;

Weitere Stellen, wo die Datenbankedition dokumentiert ist, listet die Die Support Note ID 735550.1 auf.