Tabellen für die Verarbeitung vorbereiten

In diesem Abschnitt wird beschrieben, wie Sie die Tabellen für die Verarbeitung vorbereiten. Für die Tabellenvorbereitung sind folgende Aufgaben erforderlich.

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:

  1. Primärschlüssel

  2. Erster eindeutiger Schlüssel alphanumerisch, der keinen Zeitstempel oder keine nicht materialisierte berechnete Spalte enthält.

  3. 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.

  1. 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-Parameter TABLE und den Replicat-Parameter MAP aufnehmen. Der angegebene Schlüssel überschreibt alle vorhandenen Primär- oder eindeutigen Schlüssel, die Oracle GoldenGate findet. Siehe TABLE | MAP in Referenz für Oracle GoldenGate.

Tabellen mit einem Primärschlüssel, der aus einem eindeutigen Index abgeleitet wird

Wenn kein Primärschlüssel für eine Tabelle vorhanden ist, stuft MySQL einen eindeutigen Index in den Primärschlüssel hoch, wenn die indizierte Spalte NOT NULL lautet. Wenn mehr als einer dieser Indizes ungleich Null vorhanden ist, wird der erste, der erstellt wurde, zum Primärschlüssel. Um Replicat-Fehler zu vermeiden, erstellen Sie diese Indizes in derselben Reihenfolge für die Quell- und Zieltabellen.

Beispiel: Angenommen, Quell- und Zieltabellen mit dem Namen ggvam.emp haben jeweils Spalten mit dem Namen first, middle und last, und alle sind als NOT NULL definiert. Wenn Sie eindeutige Indizes in der folgenden Reihenfolge erstellen, wird Oracle GoldenGate das Ziel beenden, weil die Tabellendefinitionen nicht übereinstimmen.

Quelle:

CREATE UNIQUE INDEX UQL ON ggvam.emp(first);
CREATE UNIQUE INDEX UQ2 on ggvam.emp(middle);
CREATE UNIQUE INDEX UQ3 on ggvam.emp(last);

Ziel:

CREATE UNIQUE INDEX UQ1 ON ggvam.emp(last);
CREATE UNIQUE INDEX UQ2 ON ggvam.emp(first);
CREATE UNIQUE INDEX UQ3 ON ggvam.emp(middle);

Das Ergebnis dieser Sequenz ist, dass MySQL den Index in der Quellspalte "first" in den Primärschlüssel hochstuft und den Index in der Zielspalte "last" in den Primärschlüssel hochstuft. Oracle GoldenGate wählt die Primärschlüssel als IDs aus, wenn es den zugehörigen Metadatendatensatz erstellt, und die Metadaten stimmen nicht überein. Um diesen Fehler zu vermeiden, entscheiden Sie, welche Spalte Sie in den Primärschlüssel hochstufen möchten, und erstellen Sie diesen Index zuerst für Quelle und Ziel.

Eigenen Schlüssel für die Verwendung von Oracle GoldenGate angeben

Wenn eine Tabelle nicht über einen der oben genannten Typen von Zeilen-IDs verfügt oder wenn Sie die Verwendung dieser IDs bevorzugen, 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-Parameter TABLE und den Replicat MAP-Parameter aufnehmen. Der angegebene Schlüssel überschreibt alle vorhandenen Primär- oder eindeutigen Schlüssel, die Oracle GoldenGate findet.

Zeilenänderungen in Tabellen begrenzen, die keinen Schlüssel enthalten

Wenn eine Zieltabelle keinen Primärschlüssel oder eindeutigen Schlüssel aufweist, können doppelte Zeilen vorhanden sein. In diesem Fall kann Oracle GoldenGate zu viele Zielzeilen aktualisieren oder löschen, wodurch die Synchronisierung der Quell- und Zieldaten ohne Fehlermeldungen beendet wird, um Sie zu warnen. Um die Anzahl der Zeilen zu begrenzen, die aktualisiert werden, verwenden Sie den Parameter DBOPTIONS mit der Option LIMITROWS in der Replicat-Parameterdatei. LIMITROWS kann die Performance von Oracle GoldenGate im Zielsystem erhöhen, weil nur eine Zeile verarbeitet wird.

Überlegungen zu Triggern und Kaskadenregeln

Trigger

Deaktivieren Sie Trigger für die Zieltabellen, oder ändern Sie sie so, dass vom Oracle GoldenGate-Datenbankbenutzer vorgenommene Änderungen ignoriert werden. Oracle GoldenGate repliziert DML, die sich aus einem Trigger ergibt. Wenn derselbe Trigger in der Zieltabelle aktiviert wird, wird er aufgrund der replizierten Version redundant, und die Datenbank gibt einen Fehler zurück.

Überlegungen zu Constraints kaskadieren

Von Oracle GoldenGate erfasste kaskadierende Aktualisierungen und Löschvorgänge werden nicht im Binärlog protokolliert, sodass sie nicht erfasst werden. Dies gilt sowohl für MySQL als auch für MariaDB. Beispiel: Wenn Sie die Löschanweisung in der übergeordneten Tabelle mit einer übergeordneten/untergeordneten Beziehung zwischen Tabellen ausführen, werden die kaskadierenden Löschvorgänge (sofern vorhanden) für die untergeordnete Tabelle ausgeführt. Sie werden jedoch nicht im Binärlog protokolliert. Nur der Lösch- oder Aktualisierungsdatensatz für die übergeordnete Tabelle wird im Binärlog protokolliert und von Oracle GoldenGate erfasst.

Weitere Informationen finden Sie unter https://mariadb.com/kb/en/replication-and-foreign-keys/ und https://dev.mysql.com/doc/refman/8.0/en/innodb-and-mysql-replication.html.

Um die Replikation kaskadierender Vorgänge ordnungsgemäß zu verarbeiten, wird empfohlen, kaskadierende Lösch- und Aktualisierungsvorgänge in der Quelle zu deaktivieren und die Anwendung zu codieren, um die untergeordneten Datensätze vor der Änderung des übergeordneten Datensatzes explizit zu löschen oder zu aktualisieren. Alternativ müssen Sie sicherstellen, dass für die übergeordnete Zieltabelle dieselben Kaskaden-Constraints konfiguriert sind wie für die übergeordnete Quelltabelle. Dies kann jedoch zu einer nicht synchronen Bedingung zwischen Quelle und Ziel führen, insbesondere bei bidirektionaler Replikation.