Manuelle Konflikterkennung und -lösung

Erfahren Sie, wie Sie mithilfe bestimmter Parameter die Konflikterkennung und -auflösung (CDR) manuell konfigurieren. Konflikterkennung und -auflösung sind in Aktiv/Aktiv-Konfigurationen erforderlich, bei denen Oracle GoldenGate die Datensynchronisierung zwischen mehreren Datenbanken aufrechterhalten muss, die dieselben Datasets enthalten.

Überblick über die Oracle GoldenGate CDR-Funktion

Oracle GoldenGate Conflict Detection and Resolution (CDR) besteht aus zwei Teilen: Conflict Detection und Conflict Resolution. Bevor Sie mit der Konfliktlösung beginnen, ist es wichtig, die Konflikterkennung zu untersuchen und abzuschließen.

Oracle GoldenGate Conflict Detection and Resolution (CDR) bietet grundlegende Konfliktlösungsroutinen, die:

Lösen Sie einen Eindeutigkeitskonflikt für eine INSERT.
Lösen Sie einen Konflikt "Keine Daten gefunden" für eine UPDATE, wenn die Zeile vorhanden ist, aber das Before Image einer oder mehrerer Spalten vom aktuellen Wert in der Datenbank abweicht.
Lösen Sie den Konflikt "Keine Daten gefunden" für eine UPDATE, wenn die Zeile nicht vorhanden ist.
Lösen Sie einen Konflikt "Keine Daten gefunden" für eine DELETE, wenn die Zeile vorhanden ist, aber das Before Image einer oder mehrerer Spalten vom aktuellen Wert in der Datenbank abweicht.
Lösen Sie den Konflikt "Keine Daten gefunden" für eine DELETE, wenn die Zeile nicht vorhanden ist.

Um die Konflikterkennung und -auflösung (CDR) verwenden zu können, muss sich die Zieldatenbank auf einem Windows-, Linux- oder UNIX-System befinden. Sie wird für Datenbanken auf der Plattform NonStop nicht unterstützt.

CDR unterstützt skalare Datentypen wie:

NUMERIC
BOOLEAN
DATE
TIMESTAMP
CHAR/NCHAR
VARCHAR/ NVARCHAR

Dies bedeutet, dass diese Spaltentypen mit dem Parameter COMPARECOLS und als Auflösungsspalte in den Optionen USEMIN und USEMAX des Parameters RESOLVECONFLICT verwendet werden können. Nur NUMERIC-Spalten können für die Option USEDELTA von RESOLVECONFLICT verwendet werden. Für USEMAX, USEMIN werden nur TIMESTAMP und NUMBER unterstützt.

Konfliktauflösung wird nicht ausgeführt, wenn Replicat im BATCHSQL-Modus ausgeführt wird. Wenn ein Konflikt im BATCHSQL-Modus auftritt, wird Replicat in den GROUPTRANSOPS-Modus und dann in den Einzeltransaktionsmodus zurückgesetzt. Die Konflikterkennung erfolgt in allen drei Modi.

Oracle GoldenGate-Parameterdateien für die Konfliktauflösung konfigurieren

Die folgenden Parameter sind erforderlich, um die Konflikterkennung und -auflösung zu unterstützen.

Verwenden Sie die Option COMPARECOLS des Parameters MAP in der Replicat-Parameterdatei, um Spalten anzugeben, die mit vor Werten in der Replicat-Klausel WHERE verwendet werden sollen. Die Before-Werte werden mit den aktuellen Werten in der Zieldatenbank verglichen, um Aktualisierungs- und Löschkonflikte zu erkennen. (Standardmäßig verwendet Replicat nur den Primärschlüssel in der WHERE-Klausel. Dies reicht möglicherweise nicht aus, um Konflikte zu erkennen.)
Verwenden Sie die Option RESOLVECONFLICT des Parameters MAP, um Konfliktlösungsroutinen für verschiedene Vorgänge und Konflikttypen anzugeben. Sie können RESOLVECONFLICT mehrmals in einer MAP-Anweisung verwenden, um verschiedene Lösungen für verschiedene Konflikttypen anzugeben. Sie können RESOLVECONFLICT jedoch nicht mehrmals für denselben Konflikttyp verwenden. Verwenden Sie identische Prozeduren zur Konfliktauflösung in allen Datenbanken, sodass derselbe Konflikt das gleiche Endergebnis erzeugt. Eine Methode zur Konfliktauflösung funktioniert möglicherweise nicht für jeden Konflikt, der auftreten könnte. Möglicherweise müssen Sie mehrere Routinen erstellen, die in einer logischen Prioritätsreihenfolge aufgerufen werden können, damit das Ausfallrisiko minimiert wird.

Hinweis: Wenn eine Tabelle über einen Primärschlüssel und zusätzliche eindeutige Indizes oder eindeutige Schlüssel verfügt, sollten Sie zusätzliche Überlegungen anstellen. Die automatisierten Routinen, die mit den Parametern COMPARECOLS und RESOLVECONFLICT bereitgestellt werden, erfordern eine konsistente Möglichkeit, jede Zeile eindeutig zu identifizieren. Wenn Sie eine Zeile nicht konsistent identifizieren, tritt ein Fehler bei der Konfliktlösung auf. In diesen Fällen müssen die zusätzlichen eindeutigen Schlüssel deaktiviert werden, oder Sie können die Funktion SQLEXEC verwenden, um den ausgelösten Fehler zu behandeln und den Konflikt zu lösen.

Ausführliche Informationen zu diesen Parametern finden Sie unter Referenz zu Parametern und Funktionen für Oracle GoldenGate. Weitere Informationen zu diesen Parametern finden Sie in den Beispielen, die im CDR-Beispiel 1: Alle Konflikttypen mit USEMAX, OVERWRITE, DISCARD beginnen.

Erforderliche Spaltenwerte für den Export verfügbar machen

Um CDR zu verwenden, müssen die folgenden Spaltenwerte protokolliert werden, damit Extract sie in den Trail schreiben kann.

Das vollständige Bild vor jedem Datensatz. Einige Datenbanken stellen kein Before Image im Logdatensatz bereit und müssen dafür mit zusätzlichem Logging konfiguriert werden. Für die meisten unterstützten Datenbanken können Sie dazu den Befehl ADD TRANDATA verwenden.
Verwenden Sie den Parameter LOGALLSUPCOLS, um sicherzustellen, dass die vollständigen Vorher-Nachher-Images der Planungsspalten in den Trail geschrieben werden. Planungsspalten sind Primärschlüssel-, eindeutige Index- und Fremdschlüsselspalten. LOGALLSUPCOLS bewirkt, dass Extract das Before-Image für UPDATE-Vorgänge und das Before-Image aller zusätzlich protokollierten Spalten für UPDATE- und DELETE-Vorgänge in den Traildatensatz einbezieht.

Ausführliche Informationen zu diesen Parametern und Befehlen finden Sie in der Referenz zu Parametern und Funktionen für Oracle GoldenGate. Weitere Informationen zur Funktionsweise dieser Parameter mit CDR finden Sie in den Beispielen, die im CDR-Beispiel 1: Alle Konflikttypen mit USEMAX, OVERWRITE, DISCARD beginnen.

CDR-Statistiken anzeigen

Die CDR-Funktion bietet die folgenden Methoden, um die Ergebnisse der Konfliktlösung anzuzeigen.

Hier sind verschiedene Techniken, mit denen Sie CDR-Statistiken anzeigen können.

Berichtsdatei

Replicat schreibt CDR-Statistiken in die Berichtsdatei:

Total CDR conflicts        7
    CDR resolutions succeeded       6
    CDR resolutions failed          1
    CDR INSERTROWEXISTS conflicts   1
    CDR UPDATEROWEXISTS conflicts   4
    CDR UPDATEROWMISSING conflicts
    CDR DELETEROWEXISTS conflicts      1
    CDR DELETEROWMISSING conflicts     1

Befehlszeile

Sie können CDR-Statistiken über die Befehlszeile anzeigen, indem Sie den Befehl STATS REPLICAT mit der Option REPORTCDR verwenden:

STATS REPLICAT *group*, REPORTCDR

Spaltenkonvertierungsfunktionen

Die folgenden CDR-Statistiken können abgerufen und einer Ausnahmetabelle zugeordnet oder in anderen Oracle GoldenGate-Parametern verwendet werden, die gegebenenfalls Eingaben aus Spaltenkonvertierungsfunktionen akzeptieren.

Anzahl von Konflikten, die Replicat ermittelt hat
Anzahl der vom Replicat aufgelösten Lösungen
Anzahl der Auflösungen, die das Replicat nicht auflösen konnte

Um diese Statistiken abzurufen, verwenden Sie die Spaltenkonvertierungsfunktion @GETENV mit dem Informationstyp STATS oder DELTASTATS. Die Ergebnisse basieren auf der aktuellen Replicat-Session. Wenn Replicat stoppt und neu startet, werden die Statistiken zurückgesetzt.

Sie können folgende Statistiken für eine bestimmte Tabelle oder Gruppe von Tabellen mit Platzhaltern ausgeben:

@GETENV ('STATS','TABLE','SCHEMA.TABLNAME','CDR_CONFLICTS')
@GETENV ('STATS','TABLE','SCHEMA.TABLNAME','CDR_RESOLUTIONS_SUCCEEDED')
@GETENV ('STATS','TABLE','SCHEMA.TABLNAME','CDR_RESOLUTIONS_FAILED')

Sie können diese Statistiken für alle Tabellen in allen MAP-Anweisungen in der Replicat-Parameterdatei zurückgeben:

@GETENV ('STATS','CDR_CONFLICTS')
@GETENV ('STATS','CDR_RESOLUTIONS_SUCCEEDED')
@GETENV ('STATS','CDR_RESOLUTIONS_FAILED')

Der Informationstyp 'STATS' in den vorherigen Beispielen kann durch 'DELTASTATS' ersetzt werden, um die angeforderten Zählungen seit der letzten Ausführung von 'DELTASTATS' zurückzugeben. Weitere Informationen zu @GETENV finden Sie unter @GETENV

CDR Beispiel 1: Alle Konflikttypen mit USEMAX, OVERWRITE, DISCARD

In diesem Beispiel werden alle Konflikttypen mit den Lösungen USEMAX, OVERWRITE und DISCARD aufgelöst.

In diesem Beispiel verwendete Tabelle

Die Beispiele gehen von identischen Oracle-Datenbanken aus.

CREATE TABLE hr.emp_tgt(
    name varchar2(30) primary key,
    phone varchar2(10),
    address varchar2(100),
    salary number,
    balance number,
    comment varchar2(100),
    last_mod_time timestamp);

In der Quelldatenbank werden alle Spalten zusätzlich protokolliert:

ADD TRANDATA hr.emp_src, COLS (name, phone, address, salary, balance, comment, last_mod_time);

MAP-Erklärung mit Konfliktlösungsspezifikationen

MAP fin.src, TARGET fin.tgt,
    COMPARECOLS (ON UPDATE ALL, ON DELETE ALL),
    RESOLVECONFLICT (UPDATEROWEXISTS, (DEFAULT, USEMAX (last_mod_time)),
    RESOLVECONFLICT (INSERTROWEXISTS, (DEFAULT, USEMAX (last_mod_time)),
    RESOLVECONFLICT (DELETEROWEXISTS, (DEFAULT, OVERWRITE)),
    RESOLVECONFLICT (UPDATEROWMISSING, (DEFAULT, OVERWRITE)),
    RESOLVECONFLICT (DELETEROWMISSING, (DEFAULT, DISCARD)),
    );

Beschreibung der MAP-Anweisung

Im Folgenden wird die MAP-Anweisung beschrieben:

Verwenden Sie pro COMPARECOLS das Before-Image aller Spalten im Traildatensatz in der Replicat WHERE-Klausel für Aktualisierungen und Löschungen.
Verwenden Sie für DEFAULT alle Spalten als Spaltengruppe für alle Konflikttypen. Daher gilt die Auflösung für alle Spalten.
Verwenden Sie für einen INSERTROWEXISTS-Konflikt die USEMAX-Auflösung: Wenn die Zeile beim Einfügen vorhanden ist, verwenden Sie die Spalte last_mod_time als Auflösungsspalte, um zu entscheiden, welcher Wert größer ist: der Wert im Trail oder der Wert in der Datenbank. Wenn der Wert im Trail größer ist, wenden Sie den Datensatz an, ändern Sie den Einfügevorgang jedoch in eine Aktualisierung. Wenn der Datenbankwert höher ist, ignorieren Sie den Datensatz.
Verwenden Sie bei einem UPDATEROWEXISTS-Konflikt die USEMAX-Auflösung: Wenn die Zeile während einer Aktualisierung vorhanden ist, verwenden Sie die Spalte last_mod_time als Auflösungsspalte: Wenn der Wert im Trail größer ist, wenden Sie die Aktualisierung an.
Wenn Sie USEMIN oder USEMAX verwenden und die Werte identisch sind, wird RESOLVECONFLICT nicht ausgelöst, und die eingehende Zeile wird ignoriert. Wenn Sie USEMINEQ oder USEMAXEQ verwenden und die Werte identisch sind, wird die Auflösung ausgelöst.
Verwenden Sie bei einem DELETEROWEXISTS-Konflikt die OVERWRITE-Auflösung: Wenn die Zeile während eines Löschvorgangs vorhanden ist, wenden Sie den Löschvorgang an.
Bei einem UPDATEROWMISSING-Konflikt verwenden Sie die OVERWRITE-Auflösung: Wenn die Zeile während einer Aktualisierung nicht vorhanden ist, ändern Sie die Aktualisierung in eine Einfügung, und wenden Sie sie an.
Bei einem DELETROWMISSING-Konflikt verwenden Sie die Auflösung von DISCARD: Wenn die Zeile während eines Löschvorgangs nicht vorhanden ist, verwerfen Sie den Traildatensatz.

Hinweis: Alternativ zu USEMAX können Sie die Auflösung USEMAXEQ verwenden, um eine >=-Bedingung anzuwenden. Weitere Informationen finden Sie in der Referenz zu Parametern und Funktionen für Oracle GoldenGate.

INSERTROWEXISTS mit der USEMAX-Lösung

In diesem Beispiel wird die Auflösung von USEMAX mit den anwendbaren Vor- und Nach-Images für den Datensatz im Trail und in der Datenbank dargestellt. Es zeigt, wie eine Einfügung aufgelöst wird, wenn der Datensatz in der Quelle und im Ziel vorhanden ist, aber einige oder alle Zeilenwerte unterschiedlich sind.

Tabelle 10 INSERTROWEXISTS Konflikt mit USEMAX Resolution

Bild	SQL	Kommentare
Vor Bild im Trail	None (row was inserted on the source).	N/V
Nach Bild im Trail	name='Mary' phone='1234567890' address='Oracle Pkwy' salary=100 balance=100 comment=NULL last_mod_time='9/1/10 3:00'	`last_mod_time='9/1/10 3:00` ist das Nachbild der Auflösungsspalte. Da es ein Nachbild gibt, wird dies verwendet, um die Auflösung zu bestimmen.
Zieldatenbankimage	name='Mary' phone='111111' address='Ralston' salary=200 balance=500 comment='aaa' last_mod_time='9/1/10 1:00'	`last_mod_time='9/1/10 1:00` ist das aktuelle Bild der Auflösungsspalte im Ziel, mit dem der Auflösungsspaltenwert im Trail verglichen wird.
Anfänglich von Replicat angewendetes `INSERT`, das den Konflikt erkennt	SQL-Bind-Variablen 1)'Mary' 2)'1234567890' 3)'Oracle Pkwy' 4)100 5)100 6)NULL 7)'9/1/10 3:00'	Diese SQL gibt einen Eindeutigkeitskonflikt für "Mary" zurück.
`UPDATE` von Replicat angewendet, um den Konflikt zu lösen	SQL-Bind-Variablen 1)'1234567890' 2)'Oracle Pkwy' 3)100 4)100 5)NULL 6)'9/1/10 3:00' 7)'Mary' 8)'9/1/10 3:00'	Da `USEMAX` für `INSERTROWEXISTS` angegeben ist, konvertiert Replicat die Einfügung in eine Aktualisierung und vergleicht den Wert von `last_mod_time` im Traildatensatz mit dem Wert in der Datenbank. Der Wert im Datensatz ist größer, sodass die Nachbilder für Spalten in der Traildatei auf das Ziel angewendet werden.

UPDATEROWEXISTES mit der USEMAX-Lösung

In diesem Beispiel wird die Auflösung von USEMAX mit den anwendbaren Vor- und Nach-Images für den Datensatz im Trail und in der Datenbank dargestellt. Es zeigt, wie eine Aktualisierung aufgelöst wird, wenn die Zeile in Quelle und Ziel vorhanden ist, aber einige oder alle Zeilenwerte unterschiedlich sind.

Tabelle 11 UPDATEROWEXISTS Konflikt mit USEMAX-Lösung

Bild	SQL	Kommentare
Vor Bild im Trail	name='Mary' phone='1234567890' address='Oracle Pkwy' salary=100 balance=100 comment=NULL last_mod_time='9/1/10 3:00'	`last_mod_time='9/1/10 3:00` ist das Before Image der Auflösungsspalte.
Nach Bild im Trail	phone='222222' address='Holly' last_mod_time='9/1/10 5:00'	`last_mod_time='9/1/10 5:00` ist das Nachbild der Auflösungsspalte. Da es ein Nachbild gibt, wird dies verwendet, um die Auflösung zu bestimmen.
Zieldatenbankimage	name='Mary' phone='1234567890' address='Oracle Pkwy' salary=100 balance=600 comment='com' last_mod_time='9/1/10 6:00'	`last_mod_time='9/1/10 6:00` ist das aktuelle Bild der Auflösungsspalte im Ziel, mit dem der Auflösungsspaltenwert im Trail verglichen wird.
Anfänglich von Replicat angewendetes `UPDATE`, das den Konflikt erkennt	SQL-Bind-Variablen 1)'222222' 2)'Holly' 3)'9/1/10 5:00' 4)'Mary' 5)'1234567890' 6)'Oracle Pkwy' 7)100 8)100 9)NULL 10)'9/1/10 3:00'	Diese SQL gibt einen Fehler zurück, bei dem keine Daten gefunden wurden, da die Werte für `balance`, `comment` und `last_mod_time` im Ziel unterschiedlich sind. Alle Spalten werden in der `WHERE`-Klausel verwendet, da die `COMPARECOLS`-Anweisung auf `ALL` gesetzt ist.
`UPDATE` wurde von Replicat angewendet, um den Konflikt zu lösen	SQL-Bind-Variablen 1)'Mary' 2)'222222' 3)'Holly' 4)100 5)100 6)NULL 7)'9/1/10 5:00' 8)'Mary' 9)'9/1/10 5:00'	Da der After-Wert von `last_mod_time` im Traildatensatz kleiner als der aktuelle Wert in der Datenbank ist, wird der Datenbankwert beibehalten. Replicat wendet den Vorgang mit einer `WHERE`-Klausel an, die den Primärschlüssel plus einen `last_mod_time`-Wert enthält, der auf kleiner als `9/1/10 5:00` gesetzt ist. Da keine Zeilen mit diesen Kriterien übereinstimmen, schlägt die Anweisung mit dem Fehler "Daten nicht gefunden" fehl. Replicat ignoriert den Fehler jedoch, da eine `USEMAX`-Auflösung voraussichtlich fehlschlägt, wenn die Bedingung nicht erfüllt wird.

UPDATEROWMISSING mit OVERWRITE Resolution

In diesem Beispiel wird die Auflösung von OVERWRITE mit den anwendbaren Vor- und Nach-Images für den Datensatz im Trail und in der Datenbank dargestellt. Es zeigt, wie der Fall aufgelöst wird, in dem die Zielzeile fehlt. Die logische Auflösung und die verwendete Lösung besteht darin, die Zeile im Ziel zu überschreiben, sodass beide Datenbanken wieder synchron sind.

Tabelle 12 UPDATEROWMISSING Konflikt mit OVERWRITE Resolution

Bild	SQL	Kommentare
Vor Bild im Trail	name='Jane' phone='333' address='Oracle Pkwy' salary=200 balance=200 comment=NULL last_mod_time='9/1/10 7:00'	N/V
Nach Bild im Trail	phone='4444' address='Holly' last_mod_time='9/1/10 8:00'
Zieldatenbankimage	None (row for Jane is missing)
Anfänglich von Replicat angewendetes `UPDATE`, das den Konflikt erkennt	SQL-Bind-Variablen 1)'4444' 2)'Holly' 3)'9/1/10 8:00' 4)'Jane' 5)'333' 6)'Oracle Pkwy' 7)200 8)200 9)NULL 10)'9/1/10 7:00'	Diese SQL gibt einen nicht gefundenen Fehler zurück. Alle Spalten werden in der `WHERE`-Klausel verwendet, da die `COMPARECOLS`-Anweisung auf `ALL` gesetzt ist.
`INSERT` von Replicat angewendet, um den Konflikt zu lösen	SQL-Bind-Variablen 1)'Jane' 2)'4444' 3)'Holly' 4)200 5)200 6)NULL 7)'9/1/10 8:00'	Die Aktualisierung wird in eine Einfügung konvertiert, da `OVERWRITE` die Auflösung ist. Das Nachbild einer Spalte wird verwendet, falls verfügbar; andernfalls wird das Vorbild verwendet.

DELETEROWEXISTEN mit OVERWRITE Auflösung

In diesem Beispiel wird die Auflösung von OVERWRITE mit den anwendbaren Vor- und Nach-Images für den Datensatz im Trail und in der Datenbank dargestellt. Es zeigt, wie der Fall gelöst wird, in dem die Quellzeile gelöscht wurde, aber die Zielzeile vorhanden ist. In diesem Fall wendet die Auflösung von OVERWRITE den Löschvorgang auf das Ziel an.

Tabelle 13 DELETEROWEXISTS Konflikt mit OVERWRITE Resolution

Bild	SQL	Kommentare
Vor Bild im Trail	name='Mary' phone='222222' address='Holly' salary=100 balance=100 comment=NULL last_mod_time='9/1/10 5:00'	N/V
Nach Bild im Trail	None	N/V
Zieldatenbankimage	name='Mary' phone='1234567890' address='Oracle Pkwy' salary=100 balance=600 comment=com last_mod_time='9/1/10 7:00'	Die Zeile ist im Ziel vorhanden, aber die Spalten `phone`, `address`, `balance`, `comment` und `last_mod_time` unterscheiden sich vom Before-Image im Trail.
Anfänglich von Replicat angewendetes `DELETE`, das den Konflikt erkennt	SQL-Bind-Variablen 1)'Mary' 2)'222222' 3)'Holly' 4)100 5)100d 6)NULL 7)'9/1/10 5:00'	Alle Spalten werden in der `WHERE`-Klausel verwendet, da die `COMPARECOLS`-Anweisung auf `ALL` gesetzt ist. Ein nicht gefundener Fehler tritt aufgrund der Differenz zwischen dem vorhergehenden und dem aktuellen Wert auf.
`DELETE` von Replicat angewendet, um den Konflikt zu lösen	SQL-Bind-Variablen 1)'Mary'	Da `OVERWRITE` die Auflösung ist. `DELETE` wird nur mit dem Primärschlüssel angewendet (um einen Integritätsfehler zu vermeiden).

DELETEROWMISSING mit DISCARD Resolution

In diesem Beispiel wird die DISCARD-Auflösung mit den anwendbaren Vor- und Nach-Images für den Datensatz im Trail und in der Datenbank dargestellt. Es zeigt, wie der Fall aufgelöst wird, in dem die Zielzeile fehlt. Bei einem Löschvorgang in der Quelle ist es akzeptabel, dass die Zielzeile nicht vorhanden ist (sie muss trotzdem gelöscht werden), sodass der DELETE-Vorgang im Trail verworfen wird.

Tabelle 14 DELETEROWMSING Konflikt mit DISCARD Resolution

Bild	SQL	Kommentare
Vor Bild im Trail	name='Jane' phone='4444' address='Holly' salary=200 balance=200 comment=NULL last_mod_time='9/1/10 8:00'	N/V
Nach Bild im Trail	None	N/V
Zieldatenbankimage	None (row missing)	N/V
Anfänglich von Replicat angewendetes `DELETE`, das den Konflikt erkennt	SQL-Bind-Variablen 1)'Jane' 2)'4444' 3)'Holly' 4)200 5)200 6)NULL 7)'9/1/10 8:00'	Diese SQL gibt einen nicht gefundenen Fehler zurück. Alle Spalten werden in der `WHERE`-Klausel verwendet, da die `COMPARECOLS`-Anweisung auf `ALL` gesetzt ist.
Von Replicat angewendetes SQL zur Behebung des Konflikts	None	Da `DISCARD` als Auflösung für `DELETEROWMISSING` angegeben ist, wechselt das Löschen aus dem Trail zur Discard-Datei.

CDR Beispiel 2: UPDATEROWEXISTS mit USEDELTA und USEMAX

In diesem Beispiel wird die Bedingung aufgelöst, bei der eine Zielzeile in UPDATE vorhanden ist, die Nicht-Schlüsselspalten jedoch unterschiedlich sind. Außerdem werden zwei verschiedene Auflösungstypen verwendet, um diese Bedingung basierend auf der betroffenen Spalte zu verarbeiten.

In diesem Beispiel verwendete Tabelle

Die Beispiele gehen von identischen Oracle-Datenbanken aus.

CREATE TABLE tgt(
    name varchar2(30) primary key,
    phone varchar2(10),
    address varchar2(100),
    salary number,
    balance number,
    comment varchar2(100),
    last_mod_time timestamp);

In der Quelldatenbank werden alle Spalten zusätzlich protokolliert:

ADD TRANDATA scott.src, COLS (name, phone, address, salary, balance, comment, last_mod_time);

MAP-Auszug

MAP fin.src, TARGET fin.tgt,
    COMPARECOLS
    (ON UPDATE KEYINCLUDING (address, phone, salary, last_mod_time),
    ON DELETE KEYINCLUDING (address, phone, salary, last_mod_time)),
    RESOLVECONFLICT (
    UPDATEROWEXISTS,
    (delta_res_method, USEDELTA, COLS (salary)),
    (DEFAULT, USEMAX (last_mod_time)));

Beschreibung der MAP-Anweisung

Bei einem UPDATEROWEXISTS-Konflikt, bei dem eine Zielzeile in UPDATE vorhanden ist, die Nicht-Schlüsselspalten jedoch unterschiedlich sind, verwenden Sie je nach Spalte zwei unterschiedliche Auflösungen:

Verwenden Sie gemäß der Auflösung von delta_res_method die Auflösungslogik USEDELTA für die Spalte salary, damit die Wertänderung dem aktuellen Wert der Spalte hinzugefügt wird.
Verwenden Sie pro DEFAULT die Auflösungslogik USEMAX für alle anderen Spalten in der Tabelle (die Standardspaltengruppe), wobei die Spalte last_mod_time als Auflösungsspalte verwendet wird. Diese Spalte wird mit der aktuellen Zeit aktualisiert, wenn die Zeile geändert wird. Der Wert dieser Spalte im Trail wird mit dem Wert im Ziel verglichen. Wenn der Wert von last_mod_time im Traildatensatz größer als der aktuelle Wert von last_mod_time in der Zieldatenbank ist, werden die Änderungen in name, phone, address, balance, comment und last_mod_time auf das Ziel angewendet.

Verwenden Sie pro COMPARECOLS den Primärschlüssel (name Spalte) plus die Spalten address, phone, salary und last_mod_time als Vergleichsspalten für die Konflikterkennung für UPDATE- und DELETE-Vorgänge. (Die Spalten balance und comment werden nicht verglichen.)

Hinweis: Alternativ zu USEMAX können Sie die Auflösung USEMAXEQ verwenden, um eine >=-Bedingung anzuwenden. Weitere Informationen finden Sie in der Referenz zu Parametern und Funktionen für Oracle GoldenGate.

Fehlerhandling

Ein Beispiel für die Fehlerbehandlung bei einer Ausnahmetabelle finden Sie unter Oracle GoldenGate-Parameterdateien für die Fehlerbehandlung konfigurieren.

Tabelle 15 UPDATEROWEXISTS mit USEDELTA und USEMAX

Bild	SQL	Kommentare
Vor Bild im Trail	`name='Mary' phone='1234567890' address='Oracle Pkwy' salary=100 balance=100 comment=NULL last_mod_time='9/1/10 3:00'`	`last_mod_time='9/1/10 3:00` ist das Vorbild der Auflösungsspalte für die `USEMAX`-Auflösung. `salary=100` ist das Before Image für die `USEDELTA`-Auflösung.
Nach Bild im Trail	`phone='222222' address='Holly' salary=200 comment='new' last_mod_time='9/1/10 5:00'`	`last_mod_time='9/1/10 5:00` ist das Nachbild der Auflösungsspalte für `USEMAX`. Da es ein Nachbild gibt, wird dies verwendet, um die Auflösung zu bestimmen.
Zieldatenbankimage	`name='Mary' phone='1234567890' address='Oracle Pkwy' salary=600 balance=600 comment='com' last_mod_time='9/1/10 4:00'`	`last_mod_time='9/1/10 4:00` ist das aktuelle Bild der Auflösungsspalte im Ziel, mit dem der Auflösungsspaltenwert im Trail verglichen wird. `salary=600` ist das aktuelle Bild der Zielspalte für die `USEDELTA`-Auflösung.
Anfänglich von Replicat angewendetes `UPDATE`, das den Konflikt erkennt	SQL-Bind-Variablen `1)'222222' 2)'Holly' 3)200 4)'new' 5)'9/1/10 5:00' 6)'Mary' 7)'1234567890' 8)'Oracle Pkwy' 9)100 10)'9/1/10 3:00'`	Diese SQL gibt einen nicht gefundenen Fehler zurück, da die Werte für `salary` und `last_mod_time` unterschiedlich sind. (Die Werte für `comment` und `balance` sind ebenfalls unterschiedlich. Diese Spalten werden jedoch nicht verglichen.)
`UPDATE` wurde von Replicat angewendet, um den Konflikt für `salary` mit `USEDELTA` zu lösen.	SQL-Bind-Variablen `1)200 2)100 3)'Mary'`	Pro `USEDELTA` wird die Differenz zwischen dem After-Image von `salary` (200) im Trail und dem Before-Image von `salary` (100) im Trail zum aktuellen Wert von `salary` im Ziel (600) hinzugefügt. Das Ergebnis ist 700. `600 + (200 - 100) = 700`
`UPDATE` wurde von Replicat angewendet, um den Konflikt für die Standardspalten mit `USEMAX` zu lösen.	SQL-Bind-Variablen `1)'222222' 2)'Holly' 3)'new' 4)'9/1/10 5:00' 5)'Mary' 6)'9/1/10 5:00'`	Pro `USEMAX` wird die Zeile mit den Nachwerten aus dem Traildatensatz aktualisiert, da der Nachwert von `last_mod_time` im Traildatensatz größer als der aktuelle Wert in der Datenbank ist. Beachten Sie, dass die Spalte `salary` hier nicht festgelegt ist, da sie mit dem `UPDATE` aus der Auflösung von `USEDELTA` aufgelöst wird.

CDR Beispiel 3: UPDATEROWEXISTS mit USEDELTA, USEMAX und IGNORE

In diesem Beispiel wird der Konflikt gelöst, bei dem eine Zielzeile in UPDATE vorhanden ist, aber Nicht-Schlüsselspalten unterschiedlich sind. Außerdem werden drei verschiedene Auflösungstypen verwendet, um diese Bedingung basierend auf der betroffenen Spalte zu verarbeiten.

In diesem Beispiel verwendete Tabelle

Die Beispiele gehen von identischen Oracle-Datenbanken aus.

CREATE TABLE tgt(
    name varchar2(30) primary key,
    phone varchar2(10),
    address varchar2(100),
    salary number,
    balance number,
    comment varchar2(100),
    last_mod_time timestamp);

In der Quelldatenbank werden alle Spalten zusätzlich protokolliert:

ADD TRANDATA scott.src, COLS (name, phone, address, salary, balance, comment, last_mod_time);

MAP-Auszug

MAP fin.src, TARGET fin.tgt,
    COMPARECOLS
    (ON UPDATE ALLEXCLUDING (comment)),
    RESOLVECONFLICT (
    UPDATEROWEXISTS,
    (delta_res_method, USEDELTA, COLS (salary, balance)),
    (max_res_method, USEMAX (last_mod_time), COLS (address, last_mod_time)),
    (DEFAULT, IGNORE));

Beschreibung der MAP-Anweisung

Bei einem UPDATEROWEXISTS-Konflikt, bei dem eine Zielzeile in UPDATE vorhanden ist, die Nicht-Schlüsselspalten jedoch unterschiedlich sind, verwenden Sie je nach Spalte zwei unterschiedliche Auflösungen:
- Verwenden Sie gemäß der Auflösung von delta_res_method die Auflösungslogik USEDELTA für die Spalten salary und balance, damit die Änderung in jedem Wert zum aktuellen Wert jeder Spalte hinzugefügt wird.
- Verwenden Sie gemäß der Auflösung von max_res_method die Auflösungslogik USEMAX für die Spalten address und last_mod_time. Die Spalte last_mod_time ist die Auflösungsspalte. Diese Spalte wird mit der aktuellen Zeit aktualisiert, wenn die Zeile geändert wird. Der Wert dieser Spalte im Trail wird mit dem Wert im Ziel verglichen. Wenn der Wert von last_mod_time im Traildatensatz größer als der aktuelle Wert von last_mod_time in der Zieldatenbank ist, werden die Änderungen in address und last_mod_time auf das Ziel angewendet. Andernfalls werden sie zugunsten der Zielwerte ignoriert.
- Verwenden Sie pro DEFAULT die Auflösungslogik IGNORE für die restlichen Spalten (phone und comment) in der Tabelle (die Standardspaltengruppe). Änderungen an diesen Spalten werden von Replicat immer ignoriert.
Verwenden Sie pro COMPARECOLS alle Spalten mit Ausnahme der Spalte comment als Vergleichsspalten für die Konflikterkennung für UPDATE-Vorgänge. Kommentar wird nicht in der WHERE-Klausel für Aktualisierungen verwendet, aber alle anderen Spalten, die ein Vorher-Bild im Traildatensatz enthalten, werden verwendet. Hinweis: Alternativ zu USEMAX können Sie die Auflösung USEMAXEQ verwenden, um eine >=-Bedingung anzuwenden. Weitere Informationen finden Sie in der Referenz zu Parametern und Funktionen für Oracle GoldenGate.

Fehlerhandling

Ein Beispiel für die Fehlerbehandlung bei einer Ausnahmetabelle finden Sie unter Oracle GoldenGate-Parameterdateien für die Fehlerbehandlung konfigurieren.

Tabelle 16 UPDATEROWEXISTS mit USEDELTA, USEMAX und IGNORE

Bild	SQL	Kommentare
Vor Bild im Trail	`name='Mary' phone='1234567890' address='Oracle Pkwy' salary=100 balance=100 comment=NULL last_mod_time='9/1/10 3:00`	`last_mod_time='9/1/10 3:00` ist das Vorbild der Auflösungsspalte für die `USEMAX`-Auflösung. `salary=100` und `balance=100` sind die Before Images für die `USEDELTA`-Auflösung.
Nach Bild im Trail	`phone='222222' address='Holly' salary=200 comment='new' last_mod_time='9/1/10 5:00'`	`last_mod_time='9/1/10 5:00` ist das Nachbild der Auflösungsspalte für `USEMAX`. Da es ein Nachbild gibt, wird dies verwendet, um die Auflösung zu bestimmen. `salary=200` ist das einzige After-Image, das für die `USEDELTA`-Auflösung verfügbar ist. Für `balance` wird das Before-Bild in der Berechnung verwendet.
Zieldatenbankimage	`name='Mary' phone='1234567890' address='Ralston' salary=600 balance=600 comment='com' last_mod_time='9/1/10 4:00'`	`last_mod_time='9/1/10 4:00` ist das aktuelle Bild der Auflösungsspalte im Ziel, mit dem der Auflösungsspaltenwert im Trail für `USEMAX` verglichen wird. `salary=600` und `balance=600` sind die aktuellen Images der Zielspalten für `USEDELTA`.
Anfänglich von Replicat angewendetes `UPDATE`, das den Konflikt erkennt	SQL-Bind-Variablen `1)'222222' 2)'Holly' 3)200 4)'new' 5)'9/1/10 5:00' 6)'Mary' 7)'1234567890' 8)'Oracle Pkwy' 9)100 10)100 11)'9/1/10 3:00'`	Diese SQL gibt einen nicht datengefundenen Fehler zurück, da die Werte für die Spalten `address`, `salary`, `balance` und `last_mod_time` unterschiedlich sind.
`UPDATE` wurde von Replicat angewendet, um den Konflikt für `salary` mit `USEDELTA` zu lösen.	SQL-Bind-Variablen `1)200 2)100 3)'Mary'`	Für `salary` gibt es einen Unterschied von 100. Der Wert für `balance` wurde jedoch nicht geändert, sodass er in der Update-SQL nicht benötigt wird. Pro `USEDELTA` wird die Differenz (Delta) zwischen dem After-Image (200) und dem Before-Image (100) von `salary` im Trail zum aktuellen Wert von `salary` im Ziel (600) hinzugefügt. Das Ergebnis ist 700.
`UPDATE` wurde von Replicat angewendet, um den Konflikt für `USEMAX` zu lösen.	SQL-Bind-Variablen `1)'Holly' 2)'9/1/10 5:00' 3)'Mary' 4)'9/1/10 5:00'`	Da der After-Wert von `last_mod_time` im Traildatensatz größer als der aktuelle Wert in der Datenbank ist, werden diese Spalte plus die Spalte `address` mit den After-Werten aus dem Traildatensatz aktualisiert. Beachten Sie, dass die Spalte `salary` hier nicht festgelegt ist, da sie mit dem `UPDATE` aus der Auflösung von `USEDELTA` aufgelöst wird.
`UPDATE` von Replicat für `IGNORE` angewendet.	SQL-Bind-Variablen `1)'222222' 2)'new' 3)'Mary'`	`IGNORE` wird für die Spaltengruppe `DEFAULT` (`phone` und `comment`) angegeben, sodass kein Auflösungs-SQL angewendet wird.

Oracle GoldenGate-Parameterdateien für die Fehlerbehandlung konfigurieren

Manuelle CDR sollte in Verbindung mit der Fehlerbehandlung verwendet werden, um Fehler zu erfassen, die behoben wurden und Fehler, die CDR nicht beheben konnte.

Die Konfliktlösung wird vor diesen anderen Fehlerbehandlungsparametern ausgeführt: HANDLECOLLSIONS, INSERTMISSINGUPDATES und REPERROR. Verwenden Sie den Parameter REPERROR, um Regeln für die Behandlung von Fehlern zuzuweisen, die nicht durch CDR behoben werden können, oder für Fehler, die Sie nicht durch CDR behandeln möchten. Möglicherweise sollte REPERROR einige Fehler behandeln und CDR andere behandeln. Wenn REPERROR und CDR jedoch so konfiguriert sind, dass derselbe Konflikt behandelt wird, hat CDR Vorrang. Die Parameter INSERTMISSINGUPDATES und HANDLECOLLISIONS können auch verwendet werden, um Fehler zu behandeln, die nicht von CDR behandelt werden. Weitere Informationen zu diesen Parametern finden Sie in der Referenz zu Parametern und Funktionen für Oracle GoldenGate.
(Optional) Erstellen Sie eine Ausnahmetabelle. Wenn eine Ausnahmetabelle mit einem Exceptions-Statment MAP verwendet wird, sendet Replicat jeden Vorgang, der einen Konflikt generiert (gelöst oder nicht), an die Exceptions-Anweisung MAP, die der Ausnahmetabelle zugeordnet werden soll. Lassen Sie einen Primärschlüssel in dieser Tabelle weg, wenn Replicat Konflikte zwischen UPDATE und DELETE verarbeiten soll. Andernfalls können Integritäts-Constraint-Fehler auftreten.

Eine Ausnahmetabelle sollte mindestens dieselben Spalten wie die Zieltabelle enthalten. Diese Zeilen enthalten jedes Zeilenimage, das Replicat auf das Ziel angewendet hat (oder versucht hat, es anzuwenden).

Darüber hinaus können Sie zusätzliche Spalten definieren, um weitere Informationen zu erfassen, mit denen die Daten in den Transaktionskontext verschoben werden können. Oracle GoldenGate stellt Tools bereit, mit denen diese Informationen über die Exception-Anweisung MAP erfasst werden können. Solche Spalten können Folgendes sein, sind jedoch nicht darauf beschränkt:
- Das Vorher-Bild des Traildatensatzes. Dies ist ein Duplikatset der Zielspalten mit Namen wie col1_before, col2_before usw.
- Die aktuellen Werte der Zielspalten. Dies ist auch ein Duplikatset der Zielspalten mit Namen wie col1_current, col2_current usw.
- Der Name der Zieltabelle
- Der Zeitstempel des Konflikts
- Der Vorgangstyp
- Die Datenbankfehlernummer
- (Optional) Die Datenbankfehlermeldung
- Ob der Konflikt gelöst wurde oder nicht
Erstellen Sie eine Exceptions-Anweisung MAP, um die Exceptions-Daten der Exception-Tabelle zuzuordnen. Eine Exceptions-Anweisung MAP enthält:
- (Erforderlich) Die Option INSERTALLRECORDS. Dieser Parameter konvertiert alle zugeordneten Vorgänge in INSERTs, sodass alle Spaltenwerte der Ausnahmetabelle zugeordnet werden.
- (Erforderlich) Die Option EXCEPTIONSONLY. Dieser Parameter veranlasst Replicat, Vorgänge zuzuordnen, die einen Fehler generieren, jedoch nicht diejenigen, die erfolgreich waren.
- (Optional) Eine COLMAP-Klausel. Wenn die Namen und Definitionen der Spalten in der Ausnahmetabelle mit denen der Quelltabelle identisch sind und die Ausnahmetabelle nur diese Spalten enthält, ist kein COLMAP erforderlich. Wenn sich jedoch Namen oder Definitionen unterscheiden oder zusätzliche Spalten in der Ausnahmetabelle vorhanden sind, die Sie mit zusätzlichen Daten füllen möchten, ordnen Sie alle Spalten mit einer COLMAP-Klausel zu.

Tools für die Zuordnung zusätzlicher Daten zur Ausnahmentabelle

Im Folgenden finden Sie einige Tools, die Sie in der COLMAP-Klausel zum Auffüllen zusätzlicher Spalten verwenden können:

Wenn die Namen und Definitionen der Quellspalten mit denen der Zielspalten in der Ausnahmetabelle identisch sind, können Sie das Schlüsselwort USEDEFAULTS verwenden, anstatt explizit Namen zuzuordnen. Andernfalls müssen Sie diese Spalten in der COLMAP-Klausel zuordnen. Beispiel:
```
COLMAP (exceptions_col1 = col1, [...])
```
Um das Before-Bild der Quellzeile Spalten in der Ausnahmetabelle zuzuordnen, verwenden Sie die Konvertierungsfunktion @BEFORE, mit der das Before-Bild einer Spalte aus dem Traildatensatz erfasst wird. Dieses Beispiel zeigt die Verwendung von @BEFORE.
```
COLMAP (USEDEFAULTS, exceptions_col1 = @BEFORE (source_col1), &
exceptions_col2 = @BEFORE (source_col2), [...])
```
Um das aktuelle Bild der Zielzeile Spalten in der Ausnahmetabelle zuzuordnen, verwenden Sie eine SQLEXEC-Abfrage, um das Bild zu erfassen, und ordnen Sie dann die Ergebnisse der Abfrage den Spalten in der Ausnahmetabelle mit der Syntax "queryID.column" in der COLMAP-Klausel zu, wie im folgenden Beispiel:
```
COLMAP (USEDEFAULTS, name_current = *queryID*.*name*, phone_current = *queryID*.*phone*, [...])
```
Um Zeitstempel, Datenbankfehler und andere Umgebungsinformationen zuzuordnen, verwenden Sie die entsprechenden Spaltenkonvertierungsfunktionen von Oracle GoldenGate. Beispiel: Im Folgenden wird der aktuelle Zeitstempel zum Ausführungszeitpunkt zugeordnet.
```
res_date = @DATENOW ()
```

Unter Beispielausnahmenzuordnung mit zusätzlichen Spalten in der Ausnahmentabelle wird beschrieben, wie diese Funktionen in einer COLMAP-Klausel in der Exceptions-Anweisung MAP kombiniert werden, um eine detaillierte Ausnahmetabelle aufzufüllen.

Informationen zur Verwendung und Syntax der in diesen Beispielen gezeigten Parameter und Spaltenkonvertierungsfunktionen finden Sie in der Referenz zu Parametern und Funktionen für Oracle GoldenGate.

Beispielausnahmenzuordnung nur mit Quell- und Zielspalten

Im Folgenden finden Sie eine Beispielparameterdatei mit der Fehlerbehandlung und einfachen Ausnahmenzuordnungen für die Quell- und Zieltabellen, die in den beginnenden CDR-Beispielen verwendet werden. In diesem Beispiel werden Quell- und Zielspalten zugeordnet, jedoch keine zusätzlichen Spalten. Aus den folgenden Gründen ist keine COLMAP-Klausel in der Exceptions-Anweisung MAP in diesem Beispiel erforderlich:

Die Spalten für Quell- und Ziel-Exceptions sind in Name und Definition identisch.
Die Ausnahmentabelle enthält keine weiteren Spalten. Hinweis: In diesem Beispiel werden absichtlich andere Parameter ausgelassen, die in einer Replicat-Parameterdatei erforderlich sind, wie Prozessname und Anmeldedaten, sowie optionale Parameter, die für einen bestimmten Datenbanktyp erforderlich sein können. Wenn Sie Zeilenumbrüche verwenden, um eine Parameteranweisung in mehrere Positionen aufzuteilen, verwenden Sie am Ende jeder Position ein Et-Zeichen (&).

    -- REPERROR error handling: DEFAULT represents all error types. DISCARD

    -- writes operations that could not be processed to a discard file.
REPERROR (DEFAULT, DISCARD)

    -- Specifies a discard file.
DISCARDFILE /users/ogg/discards/discards.dsc, PURGE

    -- The regular MAP statement with the CDR parameters
MAP fin.src, TARGET fin.tgt, &
COMPARECOLS (ON UPDATE ALL, ON DELETE ALL), &
RESOLVECONFLICT (UPDATEROWEXISTS, (DEFAULT, USEMAX (last_mod_time)), &
RESOLVECONFLICT (INSERTROWEXISTS, (DEFAULT, USEMAX (last_mod_time)), &
RESOLVECONFLICT (DELETEROWEXISTS, (DEFAULT, OVERWRITE)), &
RESOLVECONFLICT (UPDATEROWMISSING, (DEFAULT, OVERWRITE)), &
RESOLVECONFLICT (DELETEROWMISSING, (DEFAULT, DISCARD)), &
);

    -- Starts the exceptions MAP statement by mapping the source table to the

    -- exceptions table.
MAP fin.src, TARGET fin.exception, &

    -- directs Replicat only to map operations that caused the error specified

    -- in REPERROR.
EXCEPTIONSONLY, &

    -- directs Replicat to convert all the exceptions to inserts into the

    -- exceptions table. This is why there cannot be a primary key constraint

    -- on the exceptions table.
INSERTALLRECORDS
;

Beispielausnahmenzuordnung mit zusätzlichen Spalten in der Ausnahmentabelle

Die folgende Beispielparameterdatei zeigt die Fehlerbehandlung und die Zuordnung komplexer Ausnahmen für die Quell- und Zieltabellen, die in den beginnenden CDR-Beispielen verwendet werden. In diesem Beispiel enthält die Ausnahmetabelle dieselben Zeilen wie die Quelltabelle. Sie enthält jedoch auch zusätzliche Spalten, um Kontextdaten zu erfassen.

Hinweis: In diesem Beispiel werden absichtlich andere Parameter ausgelassen, die in einer Replicat-Parameterdatei erforderlich sind, wie Prozessname und Anmeldedaten, sowie optionale Parameter, die für einen bestimmten Datenbanktyp erforderlich sein können. Wenn Sie Zeilenumbrüche verwenden, um eine Parameteranweisung in mehrere Positionen aufzuteilen, verwenden Sie am Ende jeder Position ein Et-Zeichen (&).

    -- REPERROR error handling: DEFAULT represents all error types. DISCARD
    -- writes operations that could not be processed to a discard file.
REPERROR (DEFAULT, DISCARD)
    -- Specifies the discard file.
DISCARDFILE /users/ogg/discards/discards.dsc, PURGE
    -- The regular MAP statement with the CDR parameters
MAP fin.src, TARGET fin.tgt, &
COMPARECOLS (ON UPDATE ALL, ON DELETE ALL), &
RESOLVECONFLICT (UPDATEROWEXISTS, (DEFAULT, USEMAX (last_mod_time))), &
RESOLVECONFLICT (INSERTROWEXISTS, (DEFAULT, USEMAX (last_mod_time)), &
RESOLVECONFLICT (DELETEROWEXISTS, (DEFAULT, OVERWRITE)), &
RESOLVECONFLICT (UPDATEROWMISSING, (DEFAULT, OVERWRITE)), &
RESOLVECONFLICT (DELETEROWMISSING, (DEFAULT, DISCARD))
);
    -- Starts the exceptions MAP statement by mapping the source table to the -- exceptions table.
MAP fin.src, TARGET fin.exception, &
    -- directs Replicat only to map operations that caused the error specified
    -- in REPERROR.
EXCEPTIONSONLY, &
    -- directs Replicat to convert all the exceptions to inserts into the
    -- exceptions table. This is why there cannot be a primary key constraint
    -- on the exceptions table.
INSERTALLRECORDS &
    -- SQLEXEC query to select the values from the target record before the
    -- Replicat statement is applied. These are mapped to the *_target
    -- columns later.
SQLEXEC (id qry, query 'select name, phone, address, salary, balance, & comment, last_mod_time from fin.tgt where name = :p1', PARAMS(p1 = name )), &
    -- Start of the column mapping, specifies use default column definitions.
COLMAP ( &
    -- USEDEFAULTS maps the source columns to the target exceptions columns
    -- that receive the after image that Replicat applied or tried to apply.
    -- In this case, USEDEFAULTS can be used because the names and definitions
    -- of the source and target exceptions columns are identical; otherwise
    -- the columns must be mapped explicitly in the COLMAP clause.
USEDEFAULTS, &
    -- captures the timestamp when the resolution was performed.
res_date = @DATENOW (), &
    -- captures and maps the DML operation type.
optype = @GETENV ('LASTERR', 'OPTYPE'), &
    -- captures and maps the database error number that was returned.
dberrnum = @GETENV ('LASTERR', 'DBERRNUM'), &
    -- captures and maps the database error that was returned.
dberrmsge = @GETENV ('LASTERR', 'DBERRMSG'), &
    -- captures and maps the name of the target table
tabname = @GETENV ('GGHEADER', 'TABLENAME'), &
    -- If the names and definitions of the source columns and the target
    -- exceptions columns were not identical, the columns would need to
    -- be mapped in the COLMAP clause instead of using USEDEFAULTS, as
    -- follows:
       -- name_after = name, &
       -- phone_after = phone, &
       -- address_after = address, &
       -- salary_after = salary, &
       -- balance_after = balance, &
       -- comment_after = comment, &
       -- last_mod_time_after = last_mod_time &
    -- maps the before image of each column from the trail to a column in the
    -- exceptions table.
name_before = @BEFORE (name), &
phone_before = @BEFORE (phone), &
address_before = @BEFORE (address), &
salary_before = @BEFORE (salary), &
balance_before = @BEFORE (balance), &
comment_before = @BEFORE (comment), &
last_mod_time_before = @BEFORE (last_mod_time), &
    -- maps the results of the SQLEXEC query to rows in the exceptions table
    -- to show the current image of the row in the target.
name_current = qry.name, &
phone_current = qry.phone, &
address_current = qry.address, &
salary_current = qry.salary, &
balance_current = qry.balance, &
comment_current = qry.comment, &
last_mod_time_current = qry.last_mod_time)
;

Sobald Sie sicher sind, dass Ihre Routinen in allen Situationen wie erwartet funktionieren, können Sie die Datenmenge reduzieren, die in der Ausnahmetabelle protokolliert wird, um den Overhead der Lösungsroutinen zu reduzieren.