Externe Inhaltsaktualisierung durchführen

Solche Tools von anderen Anbietern können Funktionen zum Entladen von Tabellen aus der Quelle und zum Laden auf das Ziel sowie Anwendungsprogramme zum erneuten Generieren des Inhalts von Tabellen, die für Quellen- und Zieltabellen ausgeführt werden, Funktionen zur Recovery von Tabelleninhalten eines früheren Zeitpunkts auf Quelle und Ziel oder Funktionen zum Aktualisieren einer Tabelle mit einer anderen Subskription als der zur Datenspiegelung genutzten Subskription enthalten. Eine Aktualisierung oder Rekonstruktion einer Tabelle mit einem solchen Tool wird als externe Aktualisierung bezeichnet.

Um die Aktivität der externen Aktualisierung in die Spiegelungsaktivität des Abonnements zu integrieren, wird dem Produkt eine neue Befehlsfunktion hinzugefügt. Um zu verstehen, was dieser Befehl bewirkt, wie man ihm nutzbare Daten zur Verfügung stellt und wie man Missbrauch vermeidet, muss man den Mechanismus der Aktualisierung während der aktiven Verarbeitung verstehen.

Wenn für eine Tabelle in einer Subskription die Einstellungen Methode:Spiegeln und Status:Aktualisieren ausgewählt werden, dann wird diese Subskription für die Verwendung der Inhaltsaktualisierung im aktiven Zustand vorbereitet. Wenn die Subskription gestartet wird, dann wird die Tabelle vom externen Standpunkt her betrachtet aktualisiert und anschließend wird die Spiegelung der Tabellen in der Subskription gestartet. Wenn die Subskription gestartet wird, dann wird das Scraping aus dem Protokoll zwingend bei einer Position gestartet, die vor der Position liegt, bei der die Aktualisierung ausgeführt wurde. Für die Tabelle, die beim Start der Spiegelung aktualisiert wurde, werden die mit dem Scraper im Protokoll erfassten Daten solange gelöscht, bis das Scraping die Position erreicht, bei der die Aktualisierung gestartet wurde. Ab dieser Position werden die mit dem Scraper erfassten Änderungen dieser Tabelle an das Ziel weitergeleitet, um dort auf die Zieltabelle angewendet zu werden. Zwischen der Position im Protokoll, bei der die Aktualisierung gestartet wurde, und der Position, bei der sie beendet wurde, kann eine mit dem Scraper im Protokoll erfasste Änderung zu dem Zeitpunkt, zu dem dieser Teil der Tabelle aktualisiert wurde, entweder bereits in der Tabelle angewendet worden sein oder noch nicht in der Tabelle angewendet worden sein. Aus diesem Grund ist nicht sicher, ob die Änderung bereits an das Ziel weitergeleitet und während der Aktualisierung auf die Zieltabelle angewendet wurde. Mit dem Scraper im Protokoll erfasste Änderungen, die zwischen den Positionen liegen, zwischen denen die Aktualisierung ausgeführt wurde, werden deshalb auf dem Ziel mit einem Fehlerreduzierungsfilter angewendet, der Bedienungsfehler (INSERT einer bereits vorhandenen Zeile, UPDATE oder DELETE einer nicht vorhandenen Zeile) unterdrückt. Die Vorgehensweise zum Senden dieser Änderungen wird als Versenden mit dem Anzeiger 'Unbegrenzt aktualisiert' bezeichnet. Sobald das Scraping die Protokollposition passiert hat, bei der die Aktualisierung beendet wurde, wird der Anzeiger 'Unbegrenzt aktualisiert' entfernt und Bedienungsfehler werden wieder ihrem Schweregrad entsprechend regulär behandelt.

Es ist möglich, dass Änderungen, die vor der Protokollposition protokolliert wurden, bei der die Aktualisierung gestartet wurde, noch nicht festgeschrieben waren, als die Aktualisierung gestartet wurde. Solche Änderungen werden in der Tabelle nach der Eingabe des COMMIT-Befehls aufgelistet, werden jedoch gelöscht, wenn Sie mit dem Scraper im Protokoll erfasst wurden, weil sie im Protokoll vor der Startposition der Aktualisierung protokolliert wurden. Bei der Erfassung des Tabelleninhalts während der Aktualisierung werden diese Änderungen möglicherweise nicht berücksichtigt. Dies ist davon abhängig, wie viel Zeit verstreicht, bevor der Befehl COMMIT abgesetzt wird. Dies kann dazu führen, dass die Quellen- und die Zieltabelle nicht synchronisiert sind. Um dies zu vermeiden, verwendet CDC Replication Methoden, die auf dem verwendeten DBMS basieren, um einen Konsistenzpunkt für die Tabelle zu dem Zeitpunkt einzurichten, zu dem die Aktualisierung für eine Aktualisierung im aktiven Zustand gestartet wird. Auf der z/OS-Plattform wird vor dem Start der Aktualisierung z. B. eine gemeinsame Sperre angefordert, deren Geltungsbereich die Tabelle umfasst, die aktualisiert werden soll. Die aktuelle Schreibposition im Protokoll wird ermittelt und anschließend wird die Sperre freigegeben. Dadurch werden UOWs mit Recovery, die Änderungen für die gesperrte Tabelle enthalten, zwingend ausgeführt (d. h., es wird ein COMMIT durchgeführt). Wenn die gemeinsame Sperre freigegeben wird, dann wird die Aktualisierung gestartet und die Protokollschreibposition, die während der Wirksamkeit der Sperre ermittelt wurde, wird als die Position zum Starten der Aktualisierung verwendet. Die gemeinsame Sperre wird höchsten für einige Millisekunden gehalten und wirkt sich deshalb normalerweise nicht störend auf die normale Anwendungsverarbeitung für die Tabelle aus.

Wenn eine externe Aktualisierung durchgeführt wird, dann umfasst dieser Vorgang die Erfassung der Quellentabelleninhalte und das Schreiben dieser Inhalte in die Zieltabelle. Der Zeitraum, in dem der Inhalt der Quellentabelle erfasst wird, ist äquivalent zu dem Zeitraum während einer Inhaltsaktualisierung im aktiven Zustand, in dem die Quellentabelle gelesen wird. Abhängig von der Art und Weise, in der die Quellen- und die Zieltabellen außerhalb der Subskription erneut synchronisiert werden, kann dieser Zeitraum sehr lang (z. B. beim Entladen und Laden) oder so kurz sein, dass die Operation nahezu sofort ausgeführt wird (z. B. bei der punktuellen Recovery auf Quelle und Ziel).

Für CDC Replication Engine for Db2® for z/OS®muss dieser Zeitraum in einen Startbereich und einen Endbereich im Protokoll konvertiert werden, ausgedrückt in Protokollpositionen im DBMS-Protokoll. Die beiden (möglicherweise identischen) Protokollpositionen werden dann CDC Replication über die Befehlsschnittstelle zur Verfügung gestellt und CDC Replication aktualisiert die Metadaten so, als ob sie aus der Ausführung der Aktualisierung einer Aktualisierung im aktiven Zustandstammen. Wenn die Subskription mit der Spiegelung beginnt, dann beschreiben diese beiden Protokollpositionen den Scrapepunkt, d. h. den Punkt, an dem die Löschung der Tabellendaten gestoppt und die Markierung der Änderungen als 'Unbegrenzt aktualisiert' gestartet wird, und den Punkt, an dem die Markierung der Änderungen als 'Unbegrenzt aktualisiert' gestoppt wird.

Für alle anderen unterstützten Engines wird der Zeitraum für die Inhaltsaktualisierung im aktiven Zustand anhand der aktuellen Position des Protokolls ermittelt, wenn die Befehle dmmarkexternalunloadstart und dmmarkexternalunloadend abgesetzt werden.

Zusätzlich zu diesen Faktoren besteht auch das Problem der Einrichtung eines Konsistenzpunktes zu Beginn der Erfassung der Quellentabelle für die externe Aktualisierung. Wenn Sie eine Inhaltsaktualisierung im aktiven Zustand ausführen, dann wird ein Konsistenzpunkt für die zu aktualisierende Tabelle eingerichtet, indem eine gemeinsame Sperre angefordert wird, deren Geltungsbereich die Tabelle umfasst. Diese Methode steht nicht zur Verfügung, wenn eine externe Aktualisierung ausgeführt wird, sodass andere Methoden zur Einrichtung eines Konsistenzpunktes angewendet werden sollten. In bestimmten Fällen ist dies nicht möglich, z. B. bei einer punktuellen Recovery von Quelle und Ziel. Sofern möglich (z. B. bei Ausführung von Entladeoperationen und Operationen für erneutes Laden), dann sollten Sie unbedingt einen Konsistenzpunkt einrichten. Dieser Arbeitsschritt kann ausgeführt werden, indem die Aktivität für die Tabelle stillgelegt wird oder indem einfach alle Anwendungsprogramme für die Aktualisierung gestoppt werden. In bestimmten Fällen ist dieser Schritt nicht erforderlich. Dies kann der Fall wein, wenn ein Programm zum erneuten Generieren des gesamten Tabelleninhalts für Quelle und Ziel verwendet wird. (Dabei wird davon ausgegangen, dass ein solches Programm implizit die gesamte Tabelle sperrt.) Wird kein Konsistenzpunkt erstellt, dann kann es später zu Fehlern während des Systembetriebs kommen, wenn das hier beschriebene Szenario vorliegt.