Information Sharing mit Oracle Streams

Das neue Verfahren des Information Sharing beruht auf Advanced Queuing und ermöglicht die Weitergabe von Informationen, Transaktionsdaten und Events innerhalb eines einzigen Datenstroms. Mit der Version Oracle 10g wurden die Funktionalitäten von Oracle Streams erweitert und damit vereinfacht.

Datenbanksysteme sind darauf ausgelegt, Informationen für andere Datenbanken und Anwendungen zugänglich zu machen. Oracle bietet ab Oracle9i Version 2 ein neues Verfahren des Information Sharing an: Oracle Streams.

Datenweitergabe innerhalb eines Datenstroms

Oracle Streams ermöglicht die Weitergabe von Informationen, Transaktionsdaten und Events innerhalb eines einzigen Datenstroms. Dieser Datenstrom kann in der gleichen Datenbank genutzt werden oder von einer Datenbank an andere Datenbanken weitergeleitet werden.

Streams werden beispielsweise zur Replikation von Daten, zum Message Queuing und Message Management, zum Laden von aufbereiteten Daten in ein Data Warehouse, zum Versenden von datenbankinternen Informationen an Datenbankadministratoren und zur Datensicherung im Bereich von Hochverfügbarkeitslösungen eingesetzt.

Das Konzept von Oracle Streams beruht auf Advanced Queuing (AQ). In der Version 10g wurden die Funktionalitäten von Oracle Streams erweitert und damit vereinfacht.

Mit der Version 10g und dem damit beabsichtigten Grid Computing bekommt Oracle eine noch größere Bedeutung. Streams sind in der Enterprise Edition enthalten.

Abbildung 1 zeigt das Beispiel einer Architektur zur Nutzung von Oracle Streams.

Abb. 1: Beispiel einer Architektur zur Nutzung von Oracle Streams.

Komponenten von Oracle Streams

Die drei grundlegenden Komponenten für Oracle Streams sind Capture, Staging und Consumption (Apply), siehe Abbildung 2.

Abb. 2: Die Prozesse von Oracle Streams.

Die Anwendungen stellen mittels dieser Elemente Informationen in einen Stream. Es kann sich dabei um beliebige Informationen handeln, die durch den Aufruf mitgelieferter Prozeduren lediglich in ein vorgegebenes Format gebracht werden.

Automatisierung über den LogMiner-Mechanismus

Handelt es sich um Informationen, die durch DML-Befehle (Änderung des Datenbestands) oder DDL-Befehle (Änderung der Datenstruktur) entstehen, ist dieser Vorgang sogar nahezu vollständig automatisiert. Er erfolgt per Zugriff auf die Redo Log Dateien (Protokolldateien der Datenbank) durch den LogMiner-Mechanismus, ohne die Datenbank dabei zu belasten.

Der Fluss sämtlicher Daten von Anwendung zu Anwendung und von Knoten zu Knoten ist dann vollständig zu steuern. Selbstverständlich können die Daten des Informationsflusses an jeder Stelle bearbeitet oder transformiert werden.

Ebenfalls ist jederzeit kontrollierbar, wer Zugriff auf die Informationen hat und wann die Daten des Datenstroms schließlich gelöscht werden.

Der Capture-Prozess (siehe Abbildung 3) kann eine ganze Datenbank, ein Schema sowie eine oder mehrere Tabellen betreffen. Die erfassten Events werden in die Queue/Staging Area geschrieben.

Abb. 3: Capture-Prozess.

Das log-basierte Change Capture erzeugt nur geringen Overhead. Zwischengespeichert werden die Daten in der System Global Area (SGA). Seit Version 10 gibt es einen Bereich der SGA für Streams. Dieser wird durch den init.ora Parameter streams_pool_size konfiguriert.

Staging Area

Die Staging Area ist als Queue implementiert. Staging basiert auf einem Datenbank-Job. Die Daten werden in Logical Change Records (LCR) in den Datentyp SYS.Anydata gepackt.

Verarbeitet werden alle gültigen LCRs, falls sie nicht durch ein Ruleset (siehe "Transformation und Regeln") ausgefiltert werden und sie nicht schon verarbeitet wurden.

Erkennbar ist dies durch ein Tag im LCR. Dabei werden alle SQL-Befehle in der richtigen Reihenfolge verarbeitet.

DML-Handler können die eigentliche Verarbeitung übernehmen. LCRs können vor der Verarbeitung oder Weiterleitung verändert werden (Transformation). Eventuell werden LCRs auch nur weitergeleitet.

Ein Propagate-Prozess verarbeitet die vom Capture-Prozess eingestellten Events und die über AQ/Streams eingestellten Meldungen.

Mit DB-Jobs wird der Inhalt der Queue der Quelldatenbank in die Queue der Zieldatenbank übertragen (siehe Abbildung 4).

Abb. 4: Propagation.

Die Steuerung der Daten erfolgt über ein Regelwerk oder PL/SQL-Handler. Andere Staging Areas können Events anfordern. Events können über mehrere Staging Areas geroutet werden:

• Alle Events, LCRs und benutzerdefinierte Messages können in eine Queue übertragen werden.
• Events bleiben so lange in der Staging Queue, bis sie durch alle interessierten Prozesse und Applikationen konsumiert sind.
• Queues können angelegt, verändert, gestartet, gestoppt und gelöscht werden.
• Falls ein Event einen Konflikt erzeugt, so kommt es zu einer Konfliktlösung oder der Event wird alternativ in eine Exception Queue gestellt.
• Die Staging Area benötigt Speicherplatz in der SGA im Streams Pool.
• Queues werden in DB-Tabellen gespeichert.

Ein Apply Prozess verarbeitet alles, was die Propagate-Prozesse in seine Queue einstellen. Z. B. ein Ausführen der Aktion (DDL oder DML) in oder an einer lokalen Oracle Tabelle oder das Ausführen der Aktion über einen DB-Link. Apply-Prozesse können parallel arbeiten. Dazu dienen die verschiedenen Handler (siehe Abbildung 5). Konflikte können erkannt werden und werden in speziellen (Exception-)Queues gehalten.

Abb. 5: Apply.

Transformation und Regeln

Mit Oracle Streams können Transformationen (siehe Abbildung 6) und Evaluierungen von Regeln vorgenommen werden. Das gilt für Einträge,

• die in die Queue gemacht werden
• die aus der Queue ausgelesen werden
• die von Queue zu Queue propagiert werden

Abb. 6: Transformation beim Apply.

Dazu gehören ebenfalls Änderungen des Spaltentyps, der Formatierung oder der Tabellen- oder Spaltennamen.

Als Regel wird ein Datenbank-Objekt bezeichnet, das für einen Client entscheidet, ob ein Event eine Aktion auslöst. Diese Regel muss formal stets in einem Regelset enthalten sein und besteht aus einer Bedingung, die wiederum über eine Rule Engine ausgewertet wird.

Eine Bedingung kombiniert einen oder mehrere Ausdrücke und Operatoren. Sie gibt als Bool'schen Wert True, False oder Null zurück. Der Client ruft das Package dbms_rule auf. Die Administration der Regeln erfolgt über das Package dbms_rule_adm.

Automatische Konflikterkennung

Es erfolgt eine automatische Konflikterkennung mit wählbaren Routinen zur Konfliktlösung. Dazu kann der niedrigste oder der höchste Wert, der älteste oder der jüngste Wert oder auch ein neuer Wert als endgültiger Wert festgelegt werden.

Zur Konfliktlösung wird der aktuelle Wert am Bestimmungsort mit dem alten Wert der veränderten Zeile am Quellort verglichen. Sind beide Werte identisch, so werden die neuen Werte übernommen. Sind sie es nicht, dann wird die Konfliktlösungsroutine aufgerufen. Ist der Konflikt nicht lösbar, kommt der LCR in die Exception Queue.

Vorteile von Streams

Durch den Einsatz von Streams kann eine Replikation einfach in beide Richtungen definiert werden. Es gibt vordefinierte Konfliktlösungsroutinen für Updates (Minimum, Maximum, Overwrite, Discard).

Mit Streams kann auch in Nicht-Oracle-Datenbanken repliziert werden (siehe Abbildung 7). Der umgekehrte und viel wichtigere Weg, aus Nicht-Oracle-Datenbanken in Oracle-Datenbanken zu replizieren, funktioniert auch.

Abb. 7: Heterogene Systeme.

Verwaltung von Streams

Streams können über den Oracle Enterprise Manager überwacht und administriert werden. Man kann allerdings auch mit SQL die in Abbildung 8 erläuterten Views aus dem Data Dictionary abfragen.

dba_propagation	Informationen über Propagation (Quell- und Ziel-Queues, Regelsets, DB-Link, ...)
dba_apply	Informationen zu Apply (Queue, Regelsets, Handler, Status, ...)
dba_capture	Informationen zu Capture (Queue, Regelsets, SCN, Source-DB, ...)
V$streams_capture	Statistische Informationen über Capture
V$streams_apply_reader	Statistische Informationen über Apply

Abb. 8: Views im Data Dictionary.

Des Weiteren gibt es eine Reihe von Hintergrundprozessen für die Verarbeitung der folgenden Events:

• a0xx => apply
• q0xx => Datenbank_Jobs
• p0xx => propagation
• cjqxx => capture

Voraussetzungen für Streams

Die in Abbildung 9 vorgestellten init.ora-Parameter sind für den Einsatz von Streams von Bedeutung. Weitergehende Erläuterungen können gegebenenfalls der Literatur entnommen werden.

AQ_TM_PROCESSES >= 1	Erlaubt das Monitoring von Queue Messages.
Compatible >= 9.2.0	Besser ist mindestens 10.1.0, um die 10g Funktionalitäten nutzen zu können.
Job_queue_processes >= 2	Die Staging Queues werden über Jobs gefüllt.
Logmnr_max_persistent_sessions (>= Anzahl der Capture-Prozesse)	Wird für das Auslesen der Redologs benötigt.
Open_links	Wird für die Verbindungen zwischen den Datenbanken benötigt.
Parallel_max_servers ++2	Spezifiziert die maximale Anzahl paralleler Prozesse.
Processes	Es ist zu beachten, dass für Capture, Propagation und Apply verschiedene Prozesse notwendig sind.
Shared_pool_size +10 % pro Stream	mindestens plus 10 MB
Streams_pool_size	Neu in 10g. Für den Speicherbereich in der SGA zum Zwischenspeichern der Events, mindestens mit 100 MB.
Global_names = TRUE	Ganz wichtig (!!!), da die Datenströme sich in der Regel zwischen verschiedenen Datenbanken bewegen sollen.

Abb. 9: Wichtige init.ora-Parameter für den Einsatz von Streams.

Eine weitere Voraussetzung ist die Einstellung des "Supplemental Logging" auf Datenbank- oder Tabellen-Ebene. Dies sorgt für die Übermittlung eines Identifikationsschlüssels und für weitere zusätzliche Spalteninformationen. Grundsätzlich sollten alle Tabellen über einen Primary Key verfügen.

Über den Streams Administrator werden administrative Aufgaben durchgeführt. Dieser muss auf allen betroffenen Datenbanken angelegt sein. Zur Verwaltung von Streams müssen ihm mit dem Package DBMS_STREAMS_AUTH Rechte zugewiesen werden.

Die Quelldatenbanken müssen im Archivelog-Modus arbeiten, damit der LogMiner an die komplette Redo Log-Information herankommt.

Zwischen den Datenbanken müssen Verbindungen durch Datenbank-Links hergestellt werden.

Zum Speichern der Events müssen AQ Queues erstellt werden. Dazu dienen das Package DBMS_STREAMS_ADM und die darin enthaltene Prozedur SET_UP_QUEUE.

Die Data Dictionary Information von der Quelldatenbankseite muss zur Zieldatenbank übertragen werden.

Dazu dient die Prozedur DBMS_CAPTURE_ADM.PREPARE_SCHEMA_INSTANTIATION.

Einrichtung von Streams

Die Einrichtung von Streams muss in der richtigen Reihenfolge erfolgen, da sonst ein Event-Stau entstehen könnte. Es empfiehlt sich folgende Vorgehensweise:

1. Quell- und Zieldatenbank konfigurieren. Dazu gehören init-Parameter, das Einrichten von Tablespaces, das Einrichten spezieller User DBMS_STREAM_ADM, Secure Queue User, Capture- oder Apply-User und das Einrichten von DB-Links.
2. Capture-Prozess aufsetzen (nicht starten).
3. Propagation-Prozess aufsetzen (nicht starten).
4. Apply-Prozess aufsetzen und starten.
5. Propagate-Prozess starten.
6. Capture-Prozess starten.

Das Löschen erfolgt in umgekehrter Reihenfolge.

Fazit

Für den Administrator bedeutet das Aufsetzen von Oracle Streams in einer verteilten Umgebung nach wie vor einen erheblichen Aufwand. Da verteilte Umgebungen in der Praxis jedoch zunehmend an Bedeutung gewinnen und auch die Notwendigkeit des Informationsaustauschs mehr denn je besteht, wird auch der Einsatz von Oracle Streams zunehmend bedeutender.

Beate Künneke (info@ordix.de).