Tabellen für die Verarbeitung vorbereiten

Sie müssen die folgenden Aufgaben ausführen, um die Tabellen für die Verwendung in einer Oracle GoldenGate-Umgebung für Db2 LUW vorzubereiten.

Trigger deaktivieren und Constraints kaskadieren

Deaktivieren Sie Trigger, kaskadieren Sie Lösch-Constraints, und kaskadieren Sie Aktualisierungs-Constraints für Ziel-LUW-Tabellen Db2. Oracle GoldenGate repliziert DML, die sich aus einem Trigger- oder Kaskaden-Constraint ergibt. Wenn derselbe Trigger oder Constraint in der Zieltabelle aktiviert wird, wird er aufgrund der replizierten Version redundant, und die Datenbank gibt einen Fehler zurück. Betrachten Sie das folgende Beispiel, bei dem die Quelltabellen emp_src und salary_src und die Zieltabellen emp_targ und salary_targ sind.

Ein Löschvorgang wird für emp_src ausgeführt.
Ein Löschvorgang wird in salary_src kaskadiert.
Oracle GoldenGate sendet beide Löschvorgänge an das Ziel.
Der übergeordnete Löschvorgang kommt zuerst an und wird auf emp_targ angewendet.
Der übergeordnete Löschvorgang kaskadiert einen Löschvorgang in salary_targ.
Der kaskadierte Löschvorgang aus salary_src wird auf salary_targ angewendet.
Die Zeile kann nicht gefunden werden, da sie bereits in Schritt 5 gelöscht wurde.

Eindeutigkeit der Zeilen für Tabellen sicherstellen

Für Oracle GoldenGate ist eine eindeutige Zeilen-ID in den Quell- und Zieltabellen erforderlich, um die richtigen Zielzeilen für replizierte Aktualisierungen und Löschvorgänge zu finden.

Sofern keine KEYCOLS-Klausel in der TABLE- oder MAP-Anweisung verwendet wird, wählt Oracle GoldenGate eine Zeilen-ID aus, die in der folgenden Prioritätsreihenfolge verwendet werden soll:

Primärschlüssel
Erster eindeutiger Schlüssel alphanumerisch, der keinen Zeitstempel oder keine nicht materialisierte berechnete Spalte enthält.
Wenn keiner der oben genannten Schlüsseltypen vorhanden ist (auch wenn andere Schlüsseltypen in der Tabelle definiert sind), erstellt Oracle GoldenGate einen Pseuderschlüssel aller Spalten dass die Datenbank die Verwendung in einem eindeutigen Schlüssel zulässt, ausgenommen diejenigen, die von Oracle GoldenGate nicht in einem Schlüssel unterstützt werden, oder solche, die von der Oracle GoldenGate-Konfiguration ausgeschlossen sind.

Hinweis: Wenn andere, nicht verwendbare Schlüssel in einer Tabelle vorhanden sind oder keine Schlüssel in der Tabelle vorhanden sind, protokolliert Oracle GoldenGate eine entsprechende Meldung in der Berichtsdatei. Wenn Sie einen Schlüssel aus allen Spalten erstellen, wird die Performance von Oracle GoldenGate im Quellsystem beeinträchtigt. Auf dem Ziel führt dieser Schlüssel dazu, dass Replicat eine größere, weniger effiziente WHERE-Klausel verwendet.
Wenn eine Tabelle über keinen geeigneten Schlüssel verfügt oder die vorhandenen Schlüssel nicht verwendet werden sollen, können Sie einen Ersatzschlüssel definieren, wenn die Tabelle Spalten enthält, die immer eindeutige Werte enthalten. Sie definieren diesen Ersatzschlüssel, indem Sie eine KEYCOLS-Klausel in den Extract TABLE-Parameter und den Replicat MAP-Parameter aufnehmen. Der angegebene Schlüssel überschreibt alle vorhandenen Primär- oder eindeutigen Schlüssel, die Oracle GoldenGate findet. Siehe TABLE \| MAP in der Referenz zu Parametern und Funktionen für Oracle GoldenGate.

Verwenden von KEYCOLS zur Angabe eines benutzerdefinierten Schlüssels

Wenn eine Tabelle nicht über einen der oben genannten Typen von Zeilen-IDs verfügt oder wenn Sie diese IDs nicht verwenden möchten, können Sie einen Ersatzschlüssel definieren, wenn die Tabelle Spalten enthält, die immer eindeutige Werte enthalten. Sie definieren diesen Ersatzschlüssel, indem Sie eine KEYCOLS-Klausel in den Extract TABLE-Parameter und den Replicat MAP-Parameter aufnehmen. Der angegebene Schlüssel überschreibt alle vorhandenen Primär- oder eindeutigen Schlüssel, die Oracle GoldenGate findet.

Schlüsseländerungen verhindern

Fügen Sie einem Schlüssel keine Spalten hinzu, nachdem Oracle GoldenGate mit dem Extrahieren von Daten aus der Tabelle beginnt. Diese Regel gilt für einen Primärschlüssel, einen eindeutigen Schlüssel, einen KEYCOLS-Schlüssel oder einen All-Column-Schlüssel. Db2 LUW gibt kein Before Image für Spalten an, die einer Tabelle hinzugefügt werden. Wenn Spalten in einem Schlüssel in der Quelle aktualisiert werden, benötigt Oracle GoldenGate ein Before Image, um mit den aktuellen Werten in der Zieltabelle zu vergleichen, wenn das Update repliziert wird.

Materialized Query-Tabellen verwalten

Um die Parität zwischen den materialisierten Quell- und Zielabfragetabellen (MQT) beizubehalten, replizieren Sie die Basistabellen, nicht jedoch die MQTs. Die MQTs werden in der Zieldatenbank basierend auf den Änderungen verwaltet, die Replicat für die Basistabellen anwendet.

Die folgenden Regeln gelten für die Konfiguration dieser Tabellen:

Nehmen Sie die Basistabellen in die Anweisungen TABLE und MAP auf.
Nehmen Sie keine MQTs in die Anweisungen TABLE und MAP auf.
Platzhalter können in TABLE- und MAP-Anweisungen verwendet werden, auch wenn sie MQT-Namen zusammen mit regulären Tabellennamen auflösen können. Oracle GoldenGate schließt MQTs automatisch aus Listen mit Platzhaltern aus. MQT, die explizit in einer Extract TABLE-Anweisung nach Name aufgeführt wird, führt jedoch zu einem Abbruch von Extract.

Zeitliche Tabellen erstellen

Eine temporale Tabelle ist eine Tabelle, in der die Historie der Daten und der Zeitraum, in dem die Daten gültig sind, verwaltet werden. Zeitliche Tabellen werden in Oracle GoldenGate verwendet, um alle alten Zeilen zu verfolgen, die in der Tabelle gelöscht oder aktualisiert werden. Zeitliche Tabellen werden auch verwendet, um die Geschäftsgültigkeit der Zeilen und Daten zu erhalten. Beispiel: Oracle GoldenGate verfolgt den Zeitraum, in dem eine Zeile gültig ist. Es gibt drei Typen von temporalen Tabellen, Systemperiode, Anwendungszeitraum und bitemporale Tabelle.

In temporäre Tabelle konvertieren

Sie können eine bereits vorhandene Tabelle in eine temporale Tabelle konvertieren, wodurch die Struktur der Tabelle geändert wird. In diesem Abschnitt wird beschrieben, wie sich die Struktur der Tabellen ändert. Die folgende vorhandene Beispieltabelle wird in den Beispielen in diesem Abschnitt in alle drei temporalen Tabellentypen konvertiert:

Table policy_info
(
Policy_id char[4] not null primary key,
Coverage int not null
              )
And the tables contains the following initial rows
                   POLICY_ID       COVERAGE
                   -------------        -----------
                     ABC                12000
                     DEF                 13000
                     ERT                 14000

Beispiel 1: Eine vorhandene Tabelle in eine temporale Systemperiodentabelle konvertieren

Sie konvertieren die vorhandene Beispieltabelle in eine temporale Systemperiodentabelle, indem Sie SYSTEM_PERIOD, transaction id-Spalten und SYSTEM_TIME-Zeitraum wie folgt hinzufügen:

ALTER TABLE policy_info
   ADD COLUMN sys_start TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW BEGIN;
ALTER TABLE policy_info
   ADD COLUMN sys_end TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW END;
ALTER TABLE policy_info
   ADD COLUMN ts_id TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS TRANSACTION START ID;
ALTER TABLE policy_info ADD PERIOD SYSTEM_TIME(sys_start, sys_end);

Anschließend erstellen Sie eine Historientabelle für die neue temporale Tabelle mit einer der beiden folgenden Methoden:

    CREATE TABLE hist_policy_info
(
 policy_id     CHAR(4) NOT NULL,

coverage     INT NOT NULL,
sys_start    TIMESTAMP(12) NOT NULL ,

sys_end      TIMESTAMP(12) NOT NULL,

ts_id            TIMESTAMP(12) NOT NULL

           );
 ALTER TABLE hist_policy_info ADD RESTRICT ON DROP;

CREATE TABLE hist_policy_info LIKE policy_info with RESTRICT ON DROP;

Die RESTRICT ON DROP-Klausel lässt nicht zu, dass die Historientabelle beim Löschen der temporalen Systemperiodentabelle gelöscht wird. Andernfalls wird die Historientabelle beim Löschen der zugehörigen temporalen Tabelle implizit gelöscht. Sie können eine Historientabelle ohne RESTRICT ON DROP. erstellen Eine Historientabelle kann nicht explizit gelöscht werden.

Sie sollten die GENERATED ALWAYS-Klausel beim Erstellen einer Historientabelle nicht verwenden. Der Primärschlüssel der temporalen Systemperiodentabelle wird auch hier nicht angewendet, da es viele Aktualisierungen für eine bestimmte Zeile in der Basistabelle geben könnte, die viele Einfügungen in die Historientabelle für dieselbe Gruppe von Primärschlüsseln auslöst. Abgesehen davon sollte die Struktur einer Historientabelle genau mit der zugehörigen temporalen Systemperiodentabelle identisch sein. Die Historientabelle muss dieselbe Anzahl und Reihenfolge der Spalten wie die temporale Systemperiodentabelle aufweisen. Historientabellenspalten können nicht explizit hinzugefügt, gelöscht oder geändert werden. Sie müssen eine temporale Systemperiodentabelle mit der zugehörigen Historientabelle mit der folgenden Anweisung verknüpfen:

ALTER TABLE policy_info ADD VERSIONING USE HISTORY TABLE hist_policy_info.

Die GENERATED ALWAYS-Spalten der Tabelle sind die Spalten, die immer vom Datenbankmanager aufgefüllt werden, sodass Sie keine Kontrolle über diese Spalten haben. Der Datenbankmanager lädt diese Spalten basierend auf der Systemzeit.

Die zusätzlich hinzugefügten Spalten SYSTEM_PERIOD und transaction id haben Standardwerte für bereits vorhandene Zeilen wie folgt:

POLICY_ID                                   COVERAGE    SYS_START                                         SYS_END                                                TS_ID

--------- ----------- -------------------------------- -------------------------------- -------------------------------------------------------------------------------
ABC             12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000
DEF             13000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000
ERT             14000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000

Die zugehörige Historientabelle wird mit den Vorbildern aufgefüllt, sobald Sie mit der Aktualisierung der temporalen Tabelle beginnen.

Beispiel 2: Eine vorhandene Tabelle in eine temporale Anwendungstabelle konvertieren

Sie können die vorhandene Beispieltabelle in eine temporale Tabelle für den Anwendungszeitraum konvertieren, indem Sie Zeitspalten und einen BUSINESS_TIME-Zeitraum hinzufügen, wie im Folgenden beschrieben:

ALTER TABLE policy_info ADD COLUMN bus_start DATE NOT NULL DEFAULT '10/10/2001'"
ALTER TABLE policy_info ADD COLUMN bus_end DATE NOT NULL DEFAULT '10/10/2002'
ALTER TABLE policy_info ADD PERIOD BUSINESS_TIME(bus_start, bus_end)

Beim Hinzufügen von Zeitspalten müssen Sie sicherstellen, dass bei der Eingabe von Geschäftsgültigkeitszeitwerten der vorhandenen Zeitspalten der Wert in der Spalte bus_start immer kleiner als bus_end ist, da diese Spalten die Geschäftsgültigkeit der Zeilen angeben.

Die neue temporale Tabelle für den Anwendungszeitraum sieht ungefähr wie folgt aus:

POLICY_ID   COVERAGE    BUS_START  BUS_END
--------- ----------- ---------- -------------------------------
ERT             14000              10/10/2001  10/10/2002
DEF             13000             10/10/2001   10/10/2002
ABC             12000             10/10/2001   10/10/2002

Beispiel 3: Eine vorhandene Tabelle in eine bitemporale Tabelle konvertieren

Sie können die vorhandene Beispieltabelle in eine bitemporale Tabelle konvertieren, indem Sie SYSTEM_PERIOD und Zeitspalten zusammen mit dem Zeitraum SYSTEM_TIME und BUSINESS_TIME hinzufügen. Gehen Sie dazu wie folgt vor:

ALTER TABLE policy_info
   ADD COLUMN sys_start TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW BEGIN;
ALTER TABLE policy_info
   ADD COLUMN sys_end TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW END;
ALTER TABLE policy_info
   ADD COLUMN ts_id TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS TRANSACTION START ID;
ALTER TABLE policy_info ADD PERIOD SYSTEM_TIME(sys_start, sys_end);

ALTER TABLE policy_info ADD COLUMN bus_start DATE NOT NULL DEFAULT '10/10/2001'"
ALTER TABLE policy_info ADD COLUMN bus_end DATE NOT NULL DEFAULT '10/10/2002'
ALTER TABLE policy_info ADD PERIOD BUSINESS_TIME(bus_start, bus_end)

Beim Hinzufügen der Zeitspalten müssen Sie sicherstellen, dass bei der Eingabe von Geschäftsgültigkeitszeitwerten bereits vorhandener Zeitspalten der Wert in der Spalte bus_start immer kleiner als bus_end ist, da diese Spalten die Geschäftsgültigkeit der Zeilen angeben.

Anschließend erstellen Sie eine Historientabelle für die neue temporale Tabelle mit einer der beiden folgenden Methoden:

    CREATE TABLE hist_policy_info
(
 policy_id     CHAR(4) NOT NULL,

coverage     INT NOT NULL,
sys_start    TIMESTAMP(12) NOT NULL ,

sys_end      TIMESTAMP(12) NOT NULL,

ts_id            TIMESTAMP(12) NOT NULL

           );
 ALTER TABLE hist_policy_info ADD RESTRICT ON DROP;
CREATE TABLE hist_policy_info LIKE policy_info with RESTRICT ON DROP;

Die RESTRICT ON DROP-Klausel lässt nicht zu, dass die Historientabelle beim Löschen der temporalen Systemperiodentabelle gelöscht wird. Andernfalls wird die Historientabelle beim Löschen der zugehörigen temporalen Tabelle implizit gelöscht. Sie können eine Historientabelle ohne RESTRICT ON DROP. erstellen Eine Historientabelle kann nicht explizit gelöscht werden.

Sie sollten die GENERATED ALWAYS-Klausel beim Erstellen einer Historientabelle nicht verwenden. Der Primärschlüssel der temporalen Systemperiodentabelle wird auch hier nicht angewendet, da es viele Aktualisierungen für eine bestimmte Zeile in der Basistabelle geben kann, die viele Einfügungen in die Historientabelle für dieselbe Gruppe von Primärschlüsseln auslöst. Abgesehen davon sollte die Struktur einer Historientabelle genau mit der zugehörigen temporalen Systemperiodentabelle identisch sein. Die Historientabelle muss dieselbe Anzahl und Reihenfolge der Spalten wie die temporale Systemperiodentabelle aufweisen. Historientabellenspalten können nicht explizit hinzugefügt, gelöscht oder geändert werden. Sie müssen eine temporale Systemperiodentabelle mit der zugehörigen Historientabelle mit der folgenden Anweisung verknüpfen:

ALTER TABLE policy_info ADD VERSIONING USE HISTORY TABLE hist_policy_info.

Die zusätzlich hinzugefügten Spalten SYSTEM_PERIOD und transaction id haben Standardwerte für bereits vorhandene Zeilen wie folgt:

POLICY_ID                                   COVERAGE    SYS_START                                         SYS_END                                                TS_ID

--------- ----------- -------------------------------- -------------------------------- -------------------------------------------------------------------------------
ABC             12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000
DEF             13000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000
ERT             14000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000

Die zugehörige Historientabelle wird mit den Vorbildern aufgefüllt, sobald Sie mit der Aktualisierung der temporalen Tabelle beginnen.

Die zusätzlich hinzugefügten Perioden-, Transaktions-ID- und Zeitspalten SYSTEM_TIME haben Standardwerte für bereits vorhandene Zeilen wie folgt:

POLICY_ID COVERAGE    SYS_START                        SYS_END                          TS_ID                            BUS_START         BUS_END
--------- ----------- -------------------------------- -------------------------------- -------------------------------- ---------- -------------------------------------
ABC   12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000 10/10/2001 10/10/2002
DEF             13000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000 10/10/2001 10/10/2002
ERT             14000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000 10/10/2001 10/10/2002

Die Historientabelle wird mit den Before Images aufgefüllt, sobald der Benutzer mit der Aktualisierung der temporalen Tabelle beginnt.

Beispiel 4: Replikation in heterogener Umgebung.

In einer heterogenen Konfiguration, in der keine temporalen Tabellen auf der Apply-Seite vorhanden sind, können Sie nur die systemperiodischen und bitemporalen Tabellen replizieren, obwohl nicht die zugehörigen Historientabellen vorhanden sind. Bei der Replikation in dieser Situation müssen Sie den Wert der Spalten SYSTEM_PERIOD und Transaktions-ID berücksichtigen. Diese Spalten enthalten einige Werte, die von der Zieldatenbank möglicherweise nicht unterstützt werden. Verwenden Sie zuerst die Kartenkonvertierungsfunktionen, um diese Werte in das Format zu konvertieren, das die Zieldatenbank unterstützt, und ordnen Sie dann die Spalten entsprechend zu.

Beispiel: MySQL hat einen DATETIME-Bereich von 1000-01-01 00:00:00.000000 bis 9999-12-31 23:59:59.999999. Sie können den Zeitstempelwert 0001-01-01-00.00.00.000000000000 nicht in MySQL replizieren. Um solche Werte zu replizieren, müssen Sie diesen Wert in den MySQL DATETIME-Wert 1000-01-01 00:00:00.000000 konvertieren und dann die Spalten zuordnen. Wenn die folgende Zeile in der Systemperiodentabelle policy_info enthalten ist:

POLICY_ID                                   COVERAGE    SYS_START                                         SYS_END                                                TS_ID
--------- ----------- -------------------------------- -------------------------------- -------------------------------------------------------------------------------
ABC             12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000

Um die Zeile in MySQL zu replizieren, verwenden Sie die Funktion colmap():

map *source_schema*.policy_info, target *target_schema*.policy_info colmap
(policy_id=policy_id, coverage=coverage, sys_start= @IF( ( @NUMSTR( @STREXT(sys_
start,1,4))) > 1000, sys_start, '1000-01-01 00.00.00.000000'), sys_end=sys_end,
 ts_id= @IF( ( @NUMSTR( @STREXT(ts_id,1,4))) > 1000, ts_id, '1000-01-01
 00.00.00.000000'));

Mit temporären Tabellen replizieren

Sie können eine der folgenden Methoden wählen, um eine Systemperiode oder eine bitemporale temporale Tabelle wie folgt zu replizieren:

Sie können eine temporale Tabelle nur in eine andere temporale Tabelle replizieren. Dies ist das Standardverhalten. Oracle GoldenGate repliziert die Perioden- und Transaktions-ID-Spalten SYSTEM_TIME nicht, da es sich um automatisch generierte Spalten auf der Apply-Seite handelt. Der Datenbankmanager füllt die Spalten in der temporalen Zieltabelle mit der Systemuhrzeit und den Standardwerten auf. Sie können die ursprünglichen Werte dieser Spalten beibehalten und dann einen der folgenden Werte verwenden:
- Fügen Sie zusätzliche Zeitstempelspalten in der temporalen Zieltabelle hinzu, und ordnen Sie die Spalten entsprechend zu. Die zusätzlichen Spalten werden der zugehörigen Historientabelle automatisch hinzugefügt.
- Verwenden Sie auf der Apply-Seite eine nicht-zeitliche Tabelle, und ordnen Sie die Spalten entsprechend zu. In diesem Szenario können Sie die Historientabelle nicht verwalten.
- In einer heterogenen Konfiguration, bei der die Quelle Db2 LUW ist und das Ziel eine andere Datenbank ist, können Sie entweder die automatisch generierten Spalten ignorieren oder eine entsprechende Spaltenkonvertierungsfunktion verwenden, um den Spaltenwert in dem Format zu konvertieren, das die Zieldatenbank unterstützt, und sie den Zielspalten entsprechend zuzuordnen.
Oder
Sie können eine temporale Tabelle mit der zugehörigen Historientabelle in eine temporale Tabelle bzw. eine Historientabelle replizieren. Dann müssen Sie den Replikationsparameter DBOPTIONS SUPPRESSTEMPORALUPDATES angeben. Sie müssen sowohl die temporale Tabelle als auch die Historientabelle angeben, die in der Extract-Parameterdatei erfasst werden sollen. Oracle GoldenGate repliziert den Wert der Perioden- und Transaktions-ID-Spalten von SYSTEM_TIME. Sie müssen sicherstellen, dass die Datenbankinstanz über die Ausführungsberechtigung zum Ausführen der gespeicherten Prozedur auf der Apply-Seite verfügt.

Oracle GoldenGate kann keine Konflikte erkennen und lösen, während die Standardreplikation als SYSTEM_TIME-Periode verwendet wird und die Spalten transactionstart id weiterhin automatisch generiert werden. Diese Spalten können nicht in der Klausel set und where angegeben werden. Wenn Sie den Parameter SUPPRESSTEMPORALUPDATES verwenden, unterstützt Oracle GoldenGate CDR.