Unter Replikation ist das Verwalten eines definierten Datenbestands an mehr als einem Standort zu verstehen. Dabei werden die Änderungen, die an einem Standort (Quelle) vorgenommen wurden, an einen anderen (Ziel) kopiert und die Daten an beiden Standorten synchronisiert. Quelle und Ziel können sich auf logischen Servern (zum Beispiel eine DB2-Datenbank, ein DB2 für OS/390-Subsystem oder eine Gruppe mit gemeinsamer Datenbenutzung) auf derselben Maschine oder auf mehreren Maschinen in einem verteilten Netzwerk befinden.
Eine Reihe von IBM Produkten ermöglichen die Datenreplikation. In diesem Handbuch wird schwerpunktmäßig DB2 DataPropagator beschrieben, ein Programm zur Replikation relationaler Daten. Es ermöglicht das Replizieren von Änderungen zwischen beliebigen relationalen DB2-Datenbanken. Außerdem können Sie DB2 DataPropagator zusammen mit anderen IBM Produkten (zum Beispiel mit DB2 DataJoiner und IMS DataPropagator) oder auch mit Produkten anderer Hersteller (zum Beispiel Microsoft SQL Server und Sybase SQL Server) einsetzen, um Daten zwischen einer Vielzahl von Datenbankprodukten (sowohl relationale als auch nichtrelationale) zu replizieren.
Die Gestaltung Ihrer Replikationsumgebung hängt davon ab, wann Daten aktualisiert und wie Transaktionen verarbeitet werden sollen. Außerdem können Sie die Standorte für die Replikationskomponenten flexibel wählen, um die Effizienz Ihrer Replikationsumgebung zu optimieren.
Bevor Sie in Kapitel 2 mit dem Entwerfen Ihrer Replikationsumgebung beginnen, sollten Sie sich in Kapitel 1 zunächst mit den Komponenten der DB2-Datenreplikation und den zu Grunde liegenden Konzepten vertraut machen.
DB2 DataPropagator besteht aus den drei folgenden Hauptkomponenten: den Verwaltungsschnittstellen, den Mechanismen zur Erfassung von Änderungen und dem Apply-Programm.
In diesem Abschnitt werden die Steuertabellen zum Verwalten von Replikationsanforderungen, die logischen Server für die Replikationskomponenten sowie die Hauptkomponenten (Verwaltungsschnittstellen, Mechanismen zur Änderungserfassung und das Apply-Programm) und die Kommunikation zwischen diesen Komponenten behandelt.
Die Replikationskomponenten verwenden Steuertabellen, um miteinander zu kommunizieren und Replikationsaufgaben zu verwalten (z. B. Verwalten von Replikationsquellen und -zielen, Erfassen von Änderungen, das Replizieren von Änderungen und das Ermitteln, wie viele Änderungen bereits repliziert sind bzw. noch zur Verarbeitung anstehen).
Die Mechanismen zur Änderungserfassung verwenden folgende Steuertabellen: Registriertabelle, UOW-Tabelle, Löschsteuertabelle, Löschsperrtabelle, Tabelle für kritische Abschnitte, Warmstarttabelle, Tabelle mit Anpassungsparametern und CD-Tabellen. Weitere Informationen zu plattformspezifischen Steuertabellen enthält Kapitel 14, Tabellenstrukturen.
Das Apply-Programm verwendet folgende Steuertabellen: Apply-Prüfprotokolltabelle, Tabelle für kritische Abschnitte, Löschsteuertabelle, Löschsperrtabelle, Registriertabelle, Tabelle für Subskriptionsgruppen, Tabelle für Subskriptionsanweisungen, Tabelle für Subskriptionsereignisse, Tabelle für Subskriptionszuordnung, Tabelle für Subskriptionsspalten, UOW-Tabelle und CD-Tabellen.
Alle Replikationskomponenten befinden sich auf einem logischen Server. In diesem Handbuch bezeichnet 'logischer Server' eine Datenbank und nicht einen Server in einem Client/Server-System. Im Betriebssystem OS/390 sind logische Server gleichbedeutend mit Subsystemen oder Gruppen mit gemeinsamer Datenbenutzung (also mit der Domäne eines einzelnen Datenbankkatalogs). Es gibt die folgenden drei Arten von logischen Servern:
Das Apply-Programm befindet sich auf einem beliebigen logischen Server im Netzwerk. Es verwendet die dezentral arbeitende DB2-Technologie, um Verbindungen zu den Steuerungs-, Quellen- und Ziel-Servern herzustellen.
Jedes Apply-Programm ist einem Steuerungs-Server zugeordnet, den Sie angeben, wenn Sie das Apply-Programm starten. Mehrere Apply-Programme können einen Steuerungs-Server gemeinsam benutzen.
Mit den Verwaltungsschnittstellen können Sie Steuertabellen erstellen, in denen Ihre Replikationskriterien gespeichert werden. Dabei stehen zwei Benutzerschnittstellen zur Verfügung: die DB2-Steuerzentrale und das Verwaltungs-Tool DataJoiner Replication Administration (DJRA).
Die DB2-Steuerzentrale ist ein Tool zur Datenbankverwaltung, mit dem Sie die Datenreplikation zwischen DB2-Servern verwalten können. Sie automatisiert bei der Eingabe der Zielinformationen viele Initialisierungsfunktionen wie z. B. das Erstellen von Ziel- und Steuertabellen.
Mit der Steuerzentrale können die folgenden Verwaltungsaufgaben für die Datenreplikation ausgeführt werden:
DJRA (DataJoiner Replication Administration) ist ein Tool zur Datenbankverwaltung, mit dem Sie verschiedene Verwaltungsaufgaben bei der Datenreplikation zwischen DB2-Datenbanken ausführen können. Wenn Ihre Replikationsumgebung auch Datenbanken anderer Hersteller enthält, müssen Sie dieses Tool in jedem Fall einsetzen.
Mit DJRA können folgende Verwaltungsaufgaben ausgeführt werden:
Die DB2-Lösung für Datenreplikation stellt folgende Mechanismen zur Datenerfassung zur Verfügung:
In den folgenden Abschnitten werden das Capture-Programm und die Capture-Auslöser behandelt. Weitere Informationen zum Replizieren von Änderungsdaten in Microsoft Access- und Microsoft Jet-Datenbanken finden Sie im Abschnitt Verwendung von DB2 DataPropagator für Microsoft Jet.
Wenn die Quelle eine DB2-Tabelle ist, erfasst das Capture-Programm Änderungen, die an der Quelle ausgeführt wurden. Das Capture-Programm erfasst mit Hilfe des Datenbankprotokolls 8 die an der Quellendatenbank vorgenommenen Änderungen und speichert sie vorübergehend in Tabellen.
Das Capture-Programm wird auf dem Quellen-Server ausgeführt. Die Programmausführung erfolgt normalerweise fortlaufend. Sie kann jedoch gestoppt werden, während Sie Dienstprogramme ausführen oder Replikationsquellen ändern.
Anweisungen zur Verwendung des Capture-Programms enthält Teil 3, Betrieb.
Wenn die Quellentabelle eine Datenbank eines anderen Herstellers (ausgenommen Teradata, Microsoft Access und Microsoft Jet) ist, werden Änderungen in der Quelle mit Hilfe von Capture-Auslösern erfasst. Capture-Auslöser werden aktiviert, wenn ein bestimmtes Datenbankereignis (UPDATE, INSERT, DELETE) eintritt.
DJRA generiert die Capture-Auslöser automatisch. Diese Auslöser erfassen die Änderungen an Tabellen, die als Replikationsquellen definiert sind, und speichern die Änderungen temporär in Tabellen.
Das Apply-Programm liest Daten direkt aus Quellentabellen oder -sichten und füllt damit zunächst die Zieltabelle. Wenn sich die Quellentabellen in einer Datenbank eines anderen Herstellers befinden, liest das Apply-Programm die Daten über einen Kurznamen. Beim Kopieren von Änderungen liest das Apply-Programm die vorübergehend in Tabellen gespeicherten Änderungsdaten und wendet sie auf die Zieltabellen an.
Das Apply-Programm wird in der Regel auf dem Ziel-Server ausgeführt, doch ist dies auch auf jedem anderen Server im Netzwerk möglich, der eine Verbindung zu Quellen-, Steuerungs- und Ziel-Servern herstellen kann. Auch können mehrere Exemplare des Apply-Programms auf demselben oder auf unterschiedlichen Servern ausgeführt werden. Alle Apply-Programme können mit derselben oder mit unterschiedlichen Berechtigungen ausgeführt werden - oder als Teil einer Gruppe von Apply-Programmen, wobei alle Apply-Programme in der Gruppe dieselbe Berechtigung (Benutzer-ID) verwenden.
Jedes Apply-Programm ist einem Steuerungs-Server zugeordnet, der die Steuertabellen enthält, die die Definitionen für die Subskriptionsgruppen enthalten. Die Steuertabellen werden von mehreren Exemplaren des Apply-Programms gemeinsam benutzt. Wenn Sie beispielsweise mit einem Quellen-Server und zwei Ziel-Servern arbeiten, können Sie auf jedem Ziel-Server ein eigenes Apply-Programm ausführen. Die beiden Apply-Exemplare können gemeinsam auf die Steuertabellen zugreifen, die spezifische Informationen für jedes der Apply-Exemplare enthalten.
Anweisungen zur Verwendung des Apply-Programms enthält Teil 2, Verwaltung.
Die Replikationskomponenten sind unabhängig voneinander, d. h. sie kommunizieren miteinander auf der Grundlage von Daten, die in Steuertabellen gespeichert sind. Die Programme Capture und Apply und die Capture-Auslöser überwachen den Fortschritt der Datenreplikation und koordinieren die Verarbeitung der Änderungen durch das Aktualisieren der Steuertabellen.
Die Replikationskomponenten kommunizieren auf verschiedene Arten miteinander, je nachdem, ob der Quellen-Server ein DB2-Server oder ein Server eines anderen Herstellers ist. Bei der Replikation zwischen DB2-Servern erfasst das Capture-Programm Änderungen, die an Daten in den Quellentabellen vorgenommen wurden, indem es das Protokoll oder das Journal des Servers liest. Anschließend kopiert das Capture-Programm die Änderungen in so genannte CD-Tabellen (Change Data Tables). Für Replikationsquellen anderer Hersteller werden die Änderungen durch Capture-Auslöser erfasst und in CCD-Tabellen (Consistent-Change-Data Tables) gespeichert.
Jedes Mal, wenn das Apply-Programm Daten in die Zieldatenbank kopiert hat, gibt der Inhalt der Zieldatenbank die zuvor an der Quellendatenbank vorgenommenen Änderungen wieder. Dabei überträgt das Apply-Programm jeweils die seit seiner letzten Ausführung aufgelaufenen Transaktionen in die Zieldatenbank. Das Apply-Programm zeichnet auf, welche Aktualisierung in den einzelnen Zieldateien zuletzt ausgeführt wurden.
Das Capture-Programm gibt anhand bestimmter Steuertabellen an, welche Änderungen an der Quellendatenbank vorgenommen wurden, und das Apply-Programm erkennt mit Hilfe dieser Steuertabellenwerte, welche Daten in die Zieldatenbank kopiert werden müssen.
Wichtig: Das Capture-Programm beginnt mit der Erfassung von Änderungsdaten erst, wenn es vom Apply-Programm dazu angewiesen wird, und das Apply-Programm gibt diese Anweisung erst, wenn Sie eine Replikationsquelle und dazugehörige Subskriptionsgruppen definiert haben. Weitere Informationen zu den Maßnahmen, die erforderlich sind, damit die Komponenten miteinander kommunizieren und Änderungen replizieren können, finden Sie im Abschnitt Ausführen der ersten Replikation.
Der folgende Prozess beschreibt, wie die Programme Capture und Apply in einem typischen Replikationsszenario miteinander kommunizieren, um die Datenintegrität zu gewährleisten:
Erfassen von Daten aus einer Quellendatenbank
Anwenden von Daten auf eine Zieldatenbank
Bereinigen der Tabellen
Als Komponente von DB2 DataJoiner erstellt DJRA Capture-Auslöser für Quellentabellen anderer Hersteller, wenn Sie die Quellentabellen als Replikationsquellen definieren. Für die Quellentabelle werden drei Arten von Auslösern erstellt: DELETE, UPDATE und INSERT. Außerdem werden UPDATE-Auslöser in der Löschsteuertabelle und in der Synchronisationstabelle für Registrierinformationen erstellt. Das Apply-Programm erkennt mit Hilfe dieser Steuertabellen, welche Daten in die Zieldatenbank kopiert werden müssen.
Im folgenden Prozess wird dargestellt, wie die Capture-Auslöser und das Apply-Programm in einem typischen Replikationsszenario miteinander kommunizieren, um die Datenintegrität zu gewährleisten:
Erfassen von Daten aus einer Quelle
Anwenden von Daten auf ein Ziel
Bereinigen der Tabellen
Dieser Abschnitt behandelt einige grundlegende Konzepte der DB2-Datenreplikation. Der Abschnitt vermittelt einen umfassenden Überblick und sollte deshalb vollständig gelesen werden.
Eine Replikationsquelle ist eine Benutzertabelle oder Sicht, aus der Daten kopiert werden sollen. Vor dem Replizieren von Daten müssen Sie eine Replikationsquelle definieren, um anzugeben, welche Daten von den Mechanismen zur Änderungserfassung verwendet werden sollen. Beim Definieren einer Replikationsquelle müssen Sie angeben, welche Spalten repliziert werden sollen, und Sie müssen entscheiden, ob Aktualisierungen als UPDATE-Operationen oder als Kombination aus DELETE- und INSERT-Operationen verarbeitet werden sollen. Der Abschnitt Aktivieren der Unterstützung logischer Partitionierungsschlüssel bei der Replikation enthält weitere Informationen zum Vorgehen bei Aktualisierungen. Darüber hinaus müssen Sie Folgendes festlegen:
Eine Nachabbildspalte enthält den Wert, den eine Datenspalte in einer Quellentabelle nach erfolgter Aktualisierung hat. Eine Vorabbildspalte enthält den Wert, den eine Datenspalte in einer Quellentabelle vor dem Aktualisieren hat. Beim Definieren einer Replikationsquelle können Sie auswählen, ob nur das Nachabbild oder das Nachabbild und das Vorabbild erfasst werden sollen. Dabei hängt Ihre Entscheidung davon ab, wie Sie die Daten einsetzen wollen und welche Tabellenarten Sie verwenden.
Vorabbildspalten sind nützlich, wenn Ihre Anwendungen eine Protokollierung zu Prüfzwecken (Auditing) oder die Möglichkeit zum Rückgängigmachen von Arbeitseinheiten (ROLLBACK-Funktionalität) benötigen. Für die Verwendung dieser Spalten gelten bestimmte Einschränkungen, die in diesem Handbuch an anderer Stelle beschrieben werden (vgl. Abschnitt Replizieren von Vorabbildern und Nachabbildern).
Das Apply-Programm führt beim Kopieren von Daten aus der Quellentabelle in die Zieltabelle entweder eine vollständige Aktualisierung oder eine Teilaktualisierung durch.
Bei der vollständigen Aktualisierung führt das Apply-Programm folgende Schritte aus:
Bei der Teilaktualisierung kopiert das Apply-Programm nur die geänderten Daten in die Zieltabelle.
Eine Konflikterkennung ist nur in Replikationskonfigurationen für die beliebige Tabellenreplikation erforderlich. Dabei wird überprüft, ob eine Zeile im Verlauf eines Replikationszyklus sowohl in den Quellen- als auch in den Zieltabellen aktualisiert wurde. Bei der Standardkonflikterkennung sucht das Apply-Programm in Zeilen, die bereits in den CD-Tabellen erfasst sind, nach Konflikten. Bei der erweiterten Konflikterkennung sperrt das Apply-Programm alle Zieltabellen und gewährleistet damit, dass alle Änderungen berücksichtigt werden, wenn eine Prüfung auf Konflikte erfolgt. Die Konflikterkennung für Zeilenreplikate ist nur für Tabellen relevant, die mit DataPropagator für Microsoft Jet verwaltet werden. Dabei erfolgt die Konflikterkennung auf Zeilenbasis und nicht auf Transaktionsbasis.
Vor dem Replizieren von Daten aus der Replikationsquelle müssen Sie der Replikationsquelle ein Ziel zuordnen, in das die Änderungen kopiert werden sollen. Diese Festlegung können Sie durch Definieren von Subskriptionsgruppen und Subskriptionsgruppeneinträgen treffen. Die von Ihnen definierten Vorgaben werden in verschiedenen Replikationssteuertabellen gespeichert.
Eine Subskriptionsgruppe enthält die Attribute für eine Replikationssubskription. Beim Erstellen einer Subskriptionsgruppe wird Folgendes festgelegt:
Jede Subskriptionsgruppe muss über einen Subskriptionsgruppeneintrag für jede Zieltabelle oder -sicht verfügen. Beim Erstellen eines Subskriptionsgruppeneintrags wird Folgendes festgelegt:
Subskriptionsgruppen sorgen dafür, dass alle Subskriptionsgruppeneinträge während der Replikation gleich behandelt werden, d. h., Änderungen werden entweder auf alle Ziele übertragen oder gar nicht. Die geänderten Daten für alle Subskriptionsgruppeneinträge einer Subskriptionsgruppe werden mit einer einzigen Transaktion in die angegebenen Zieltabellen repliziert. Subskriptionsgruppen optimieren die Verarbeitungsleistung, weil die Zieltabellen einer Subskriptionsgruppe jeweils in einer einzigen Transaktion auf dem Ziel-Server verarbeitet werden. Subskriptionsgruppen gewährleisten außerdem die referenzielle Integrität.
Jede Subskriptionsgruppe wird von einem Apply-Programm verarbeitet, aber jedes Apply-Programm kann mehrere Subskriptionsgruppen verarbeiten. Die Beziehung zwischen einer Subskriptionsgruppe und Subskriptionsgruppeneinträgen wird in Abbildung 1 gezeigt.
Abbildung 1. Subskriptionsgruppen und Subskriptionsgruppeneinträge. Beispiel der Beziehung zwischen einer Subskriptionsgruppe und Subskriptionsgruppeneinträgen.
Das Apply-Qualifikationsmerkmal ordnet einem Apply-Programm eine oder mehrere Subskriptionsgruppen zu. Das Apply-Qualifikationsmerkmal wird beim Definieren einer Subskriptionsgruppe angegeben. Bei der Eingabe der Zeichenfolge ist die Groß-/Kleinschreibung zu beachten. 10
Durch die Verwendung mehrerer Apply-Qualifikationsmerkmale wird es möglich, mehrere Exemplare des Apply-Programms über eine einzige Benutzer-ID auszuführen. Anhand des Apply-Qualifikationsmerkmals werden Sätze auf dem Steuerungs-Server identifiziert, die den Auslastungsgrad eines Exemplars des Apply-Programms definieren. Die Benutzer-ID hingegen dient nur zu Berechtigungszwecken. Angenommen, Sie wollen Daten aus zwei Quellendatenbanken in die Zieltabellen auf Ihrem Computer replizieren. Die Daten aus Quellentabelle A sollen durch eine vollständige Aktualisierung in Zieltabelle A repliziert werden, und die Daten aus Quellentabelle B sollen durch eine Teilaktualisierung in Zieltabelle B repliziert werden. Durch die Definition von zwei Subskriptionsgruppen (eine für Tabelle A und eine für Tabelle B) und durch die Verwendung separater Apply-Qualifikationsmerkmale erreichen Sie, dass zwei Exemplare des Apply-Programms die Daten zu unterschiedlichen Zeiten kopieren können. Sie können auch beide Subskriptionsgruppen mit einem Apply-Qualifikationsmerkmal definieren.
Möglicherweise wollen Sie nur eine Untermenge Ihrer Quellentabelle replizieren, die Quellendaten in der Zieltabelle unter Zuhilfenahme einer einfachen Sicht neu strukturieren oder komplexere JOIN- oder UNION-Verknüpfungen verwenden.
Sie können anstelle der gesamten Quellentabelle auch bestimmte Spalten oder Zeilen der Quellentabelle replizieren. Bei dieser Tabellenpartitionierung wird im vorliegenden Handbuch zwischen dem Bilden von Spaltenuntermengen (vertikale Unterteilung) und dem Bilden von Zeilenuntermengen (horizontale Unterteilung) unterschieden.
Bei der vertikalen Unterteilung wird eine bestimmte Untermenge der Spalten einer Replikationsquelle repliziert. Diese Art der Untermengenbildung ist zum Beispiel hilfreich, wenn einige der Spalten in der Quellentabelle sehr lang sind (z. B. LOBs) oder wenn die Spaltendatentypen von der vorgesehenen Zieltabelle nicht unterstützt werden.
Bei der horizontalen Unterteilung werden nur bestimmte Zeilen der Quellentabelle repliziert. Beispielsweise kann es bei der Datenreplikation für mehrere regionale Geschäftsstellen wünschenswert sein, nur diejenigen Datensätze zu replizieren, die für die jeweilige Geschäftsstelle von Interesse sind. Beim Definieren der Subskriptionsgruppeneinträge können Sie über die WHERE-Klausel Zeilenuntermengen bilden.
Mit einfachen Sichten können Kopien in Data Warehousing-Szenarios umstrukturiert werden, um die Datenabfrage aus Zieltabellen zu vereinfachen.
Beispiel: Angenommen, in einer Datenbank ist eine Tabelle mit Lebensläufen und eine andere Tabelle mit Fotos der Mitarbeiter enthalten. Die Personalabteilung benötigt eine Tabelle, die den Lebenslauf und das Foto jedes Mitarbeiters enthält. Sie haben hier die Möglichkeit, eine Sicht zu erstellen, die die beiden Tabellen umfasst, Sie können eine Sicht als Replikationsquelle definieren und eine Subskriptionsgruppe erstellen, um die Daten aus der Sicht in eine Zieltabelle in der Personaldatenbank replizieren.
Sichten können auch verwendet werden, um zugehörige Spalten in andere Tabellen aufzunehmen. Sie können auf Spalten in anderen Tabellen in den Prädikaten der Subskriptionsgruppeneinträge verweisen, was das Weiterleiten von Aktualisierungen an die entsprechenden Zielstandorte vereinfacht.
Sie können Zieltabellen erstellen und verwalten, deren Inhalt durch JOIN- oder UNION-Verknüpfungen vorhandener Quellentabellen entstanden ist.
Sie können folgende Arten von JOIN-Verknüpfungen verwenden:
Mit JOIN- und UNION-Verknüpfungen können Sie Daten in folgender Weise bearbeiten:
Beim Definieren eines Subskriptionsgruppeneintrags müssen Sie angeben, welche Tabellenart als Zieltabelle verwendet werden soll. Folgende Tabellenarten stehen zur Verfügung:
In den folgenden Abschnitten werden die Merkmale der einzelnen Tabellenarten beschrieben.
Diese Tabellen, auf die nur Lesezugriff besteht, sind Kopien der Replikationsquelle ohne hinzugefügte Spalten für die Replikationssteuerung. Sie sind wie normale Quellentabellen aufgebaut und bilden eine solide Ausgangsbasis für die Replikation. Diese Tabellenart wird am häufigsten für Zieltabellen verwendet.
Diese Tabellen, auf die nur Lesezugriff besteht, sind Kopien der Replikationsquelle mit hinzugefügter Zeitmarkenspalte. Die Zeitmarkenspalte ist zunächst auf Null gesetzt. Beim Replizieren von Änderungen werden Werte hinzugefügt, die angeben, wann die Aktualisierungen stattgefunden haben. Mit dieser Tabellenart können Sie aufzeichnen, wann Änderungen vorgenommen wurden.
Diese Tabellen, auf die nur Lesezugriff besteht, verwenden SQL-Spaltenfunktionen (zum Beispiel SUM und AVG) zum Berechnen von Zusammenfassungen des gesamten Inhalts der Quellentabellen oder der zuletzt an den Daten der Quellentabellen vorgenommenen Änderungen. Die Zeilen mit den berechneten Werten werden jeweils an die Ergebnistabellen angehängt. Es sind zwei Arten von Ergebnistabellen zu unterscheiden: Basisergebnistabellen und CA-Tabellen (Change Aggregate Tables).
Basisergebnistabellen fassen den Inhalt einer Quellentabelle zusammen. Mit der Basisergebnistabelle können Sie den Status einer Quellentabelle regelmäßig überwachen. Angenommen, Sie möchten die durchschnittliche Kundenzahl pro Monat ermitteln. Wenn Ihre Quellentabelle für jeden Kunden eine Zeile enthält, können Sie für diese Zeilen einen Durchschnittswert auf monatlicher Basis bilden und das Ergebnis in einer Basisergebnistabelle speichern.
Mit Basisergebnistabellen können keine Änderungsdaten protokolliert werden. Angenommen, die Berechnung des Durchschnittswerts ergibt, dass Sie im Januar und im Februar jeweils 500 Kunden hatten. Im Februar haben Sie zwei bisherige Kunden verloren, dafür aber auch zwei neue hinzugewonnen. Die Basisergebnistabelle zeigt aber nur, dass Sie in beiden Monaten die gleiche durchschnittliche Kundenzahl hatten, die Veränderung im Februar geht nicht aus ihr hervor. Zum Protokollieren von Änderungsinformationen muss eine CA-Tabelle (Change Aggregate Table) verwendet werden.
CA-Tabellen arbeiten mit den Änderungsdaten in den Steuertabellen und nicht mit dem Inhalt der Quellentabelle. CA-Tabellen dienen zum kontinuierlichen Protokollieren von Änderungen (UPDATE-, INSERT- und DELETE-Operationen). Angenommen, Sie möchten ermitteln, wie viele neue Kunden Sie monatlich hinzugewonnen (INSERT-Operationen) und wie viele Sie verloren haben (DELETE-Operationen). In diesem Fall würden Sie die Änderungen zahlenmäßig erfassen, die monatlich an den Zeilen in der Quellentabelle vorgenommen werden, und die ermittelte Anzahl in einer CA-Tabelle speichern.
Diese Tabellen enthalten Daten aus festgeschriebenen Transaktionen. Sie enthalten zudem eine Information (Indikator) darüber, ob die Zieltabelle mit einer INSERT-, DELETE- oder UPDATE-Operation geändert wurde. Sie können darüber hinaus den alten und neuen Wert der Daten enthalten. Die unterschiedlichen Arten von CCD-Tabellen (lokal oder auf einem fernen System, vollständig oder unvollständig, komprimiert oder nicht komprimiert, intern oder extern) dienen verschiedenen Zwecken. Der Abschnitt Attribute von CCD-Tabellen enthält Informationen über die verschiedenen Arten von CCD-Tabellen und beschreibt, wann diese Tabellen verwendet und wie sie definiert werden können. Mit den verschiedenen Arten von CCD-Tabellen können Daten auf unterschiedliche Art und Weise gesammelt und verändert werden:
Dies sind die einzigen Zieltabellen, die von Ihren Anwendungen direkt aktualisiert werden können. An Replikaten und Zeilenreplikaten vorgenommene Änderungen werden in die zugeordnete Quellentabelle repliziert. Die Quellentabelle gibt diese Änderungen dann an andere Replikattabellen weiter. Replikate werden nur in DB2-Datenbanken unterstützt. Eine Zeilenreplikattabelle ist eine spezielle Replikattabelle für DB2 DataPropagator für Microsoft Jet. Verwenden Sie die Replikattabellen bei der beliebigen Tabellenreplikation (Update-Anywhere Replication).
Eine Benutzertabelle wird zwar nicht direkt als Replikationsziel angegeben, bei der beliebigen Tabellenreplikation ist eine Benutzertabelle jedoch automatisch das Ziel für die dazugehörigen Replikate und Zeilenreplikate. Dabei ist die Benutzertabelle das die dem Replikat übergeordnete Tabelle (Parent of the Replica), und die Kopien dieser Tabelle sind untergeordnete Replikate (Dependent Replica). Die dem Replikat übergeordnete Tabelle erhält Aktualisierungen von einem untergeordneten Replikat und repliziert diese (sofern keine Konflikte festgestellt werden) in die anderen untergeordneten Replikate. Die dem Replikat übergeordnete Tabelle ist die primäre Datenquelle. Wenn Konflikte auftreten, bleibt der Inhalt der Tabelle, die dem Replikat übergeordnet ist, erhalten. Normalerweise verwenden Ihre Anwendungen die untergeordneten Replikattabellen. Wenn diese Replikate jedoch nicht verfügbar sind, greifen Ihre Anwendungen auf den Server mit der Benutzertabelle zu.
Bei der synchronen Replikation werden die Aktualisierungen kontinuierlich verarbeitet. Eine an den Quellendaten vorgenommene Änderung wird vorübergehend gespeichert und später in das Replikationsziel übertragen. In der Quellendatenbank wird eine Änderung erst festgeschrieben, nachdem sie in die Zieldatenbank repliziert wurde. Wenn eine Änderung nicht in die Zieldatenbank repliziert werden kann, wird die Änderung auch nicht in der Quellendatenbank vorgenommen. Diese Art der Replikation wird auch als Echtzeitreplikation bezeichnet. Wenn Ihre Anwendung synchrone Aktualisierungen benötigt, richten Sie Ihre Anwendungen so ein, dass Tabellenaktualisierungen nicht mit den in diesem Handbuch beschriebenen Produkten, sondern in einer einzigen verteilten Transaktion ausgeführt werden.
Bei der asynchronen Replikation werden die Aktualisierungen schrittweise verarbeitet. Eine an den Quellendaten vorgenommene Änderung wird für einen definierten Zeitraum zwischengespeichert und später in das Replikationsziel übertragen. Dieses Intervall kann durch Zeiteinheiten (Sekunden, Minuten, Stunden) oder durch Zeitpunkte (Mitternacht oder eine andere Uhrzeit) gesteuert werden. Wenn Änderungen nicht in die Zieldatenbank übertragen werden können (z. B. wenn die Zieldatenbank nicht betriebsbereit oder das Netzwerk ausgefallen ist), werden sie gespeichert und später in der Reihenfolge angewendet, in der sie in der Replikationsquelle vorgenommen wurden. Diese Art der Datenreplikation bietet zahlreiche Vorteile gegenüber der synchronen Replikation: bessere Nutzung der Netzwerkressourcen, weniger Konkurrenzsituationen in der Datenbank sowie die Möglichkeit, die Daten vor dem Replizieren in die Zieldatenbank zu modifizieren.
DB2 DataPropagator arbeitet mit der asynchronen Replikation, d. h., die in der Replikationsquelle vorgenommenen Änderungen werden nicht sofort in die Replikationsziele kopiert. Sie können durch Festlegen von Zeitintervallen und/oder Ereignissen angeben, wie häufig die Änderungen in das Replikationsziel übernommen werden sollen. In Umgebungen mit zeitweise verbundenen Systemen können die Daten auch bedarfsgesteuert repliziert werden.
Dies ist die einfachste Methode zum Steuern des Replikationsablaufs. Bei der Intervallsteuerung geben Sie einfach durch das Datum und die Uhrzeit an, wann das Apply-Programm mit der Replikation beginnen soll, und legen durch ein Zeitintervall fest, wie häufig die Datenreplikation erfolgen soll. Wenn das Apply-Programm beendet ist, wird es erst nach Ablauf des definierten Zeitintervalls erneut gestartet. Für das Replikationsintervall kann ein Zeitraum (von einer Minute bis zu einem Jahr) oder "Fortlaufend" angegeben werden. Die Angabe Fortlaufend bewirkt, dass das Apply-Programm in kurzen Zeitabständen von wenigen Sekunden immer wieder Replikationszyklen startet. (Diese Zeitabstände können Sie über den Startparameter steuern.) Bei diesen Angaben für das Replikationsintervall handelt es sich jedoch nur um Näherungswerte. Das vom Apply-Programm tatsächlich verwendete Zeitintervall hängt davon ab, wie viele Aktualisierungen verarbeitet werden müssen und welche Ressourcen (Datenbanktabelle, Tabellenbereich) verfügbar sind.
Dies ist die genaueste Methode zum Steuern des Replikationsablaufs. Für die Ereignissteuerung geben Sie beim Definieren der Subskriptionsgruppe den Namen eines Ereignisses sowie den Zeitpunkt für die Verarbeitung dieses Ereignisses an. Sie können auch (wahlfrei) einen Endzeitpunkt angeben, d. h., das Apply-Programm repliziert nach diesem Zeitpunkt keine weiteren Transaktionen, sondern verschiebt diese auf einen späteren Zeitpunkt.
Die Informationen zur Ereignissteuerung müssen von Ihnen oder von einer Anwendung bereitgestellt werden. Diese Informationen werden in der Tabelle für Subskriptionsereignisse gespeichert. Das Apply-Programm durchsucht die Tabelle für Subskriptionsereignisse nach dem Ereignisnamen und den dazugehörigen Zeitangaben.
Mit dem Befehl ASNSAT können Daten jederzeit nach Bedarf repliziert werden. Der Befehl startet das Apply-Programm und - falls erforderlich - auch das Capture-Programm. Jedes Programm wird automatisch wieder beendet, wenn es seine Aufgabe innerhalb des betreffenden Replikationszyklus erfüllt hat. Der Befehl wird von Windows 32-Bit-Betriebssystemen unterstützt, die zugehörigen Aufrufparameter sind im Abschnitt Bedarfsgesteuerte Replikation (nur 32-Bit-Windows-Betriebssysteme) beschrieben.
Der Befehl ASNSAT kann auch in Replikationskonfigurationen mit zeitweise verbundenen Systemen verwendet werden. Weitere Informationen enthält die Veröffentlichung DB2 Universal Database Administering Satellites Guide and Reference.