Tabellen für die Verarbeitung vorbereiten

Die folgenden Tabellenattribute müssen in einer Oracle GoldenGate-Umgebung adressiert werden.

Trigger deaktivieren und Constraints kaskadieren

Deaktivieren Sie Trigger, kaskadieren Sie Lösch-Constraints, und kaskadieren Sie Aktualisierungs-Constraints für Sybase-Zieltabellen, oder ändern Sie sie so, dass vom Oracle GoldenGate-Datenbankbenutzer vorgenommene Änderungen ignoriert werden. 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.

  1. Ein Löschvorgang wird für emp_src ausgeführt.

  2. Ein Löschvorgang wird in salary_src kaskadiert.

  3. Oracle GoldenGate sendet beide Löschvorgänge an das Ziel.

  4. Der übergeordnete Löschvorgang kommt zuerst an und wird auf emp_targ angewendet.

  5. Der übergeordnete Löschvorgang kaskadiert einen Löschvorgang in salary_targ.

  6. Der kaskadierte Löschvorgang aus salary_src wird auf salary_targ angewendet.

  7. Die Zeile kann nicht gefunden werden, da sie bereits in Schritt 5 gelöscht wurde.

Um Replicat so zu konfigurieren, dass Ziel-Trigger zu Beginn der Datenbanksession deaktiviert werden, gehen Sie wie folgt vor:

  1. Weisen Sie dem Replicat-Benutzer die Replikationsrolle zu.

  2. Fügen Sie die folgende Parameteranweisung zur Root-Ebene der Replicat-Parameterdatei hinzu.

SQLEXEC "set triggers off"

Zeilen-IDs zuweisen

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

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. Oracle GoldenGate kann zu viele Zeilen in der Zieltabelle aktualisieren oder löschen, sodass die Quell- und Zieldaten ohne Fehlermeldungen aus der Synchronisierung ausfallen und Sie benachrichtigt werden. 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.

Verschlüsselte Daten replizieren

Oracle GoldenGate unterstützt Spalten, die mit einem systemverschlüsselten Kennwort verschlüsselt sind, nicht jedoch Spalten, die mit einem benutzerdefinierten Kennwort verschlüsselt sind. Prüfen Sie die Tabellen, aus denen Sie Daten erfassen möchten, anhand der folgenden Oracle GoldenGate-Einschränkungen:

Verschlüsselte Spalten werden in den Datendateien und im Log verschlüsselt. Daher muss Extract so konfiguriert werden, dass die Klartextwerte aus der Datenbank abgerufen werden. Um diesen Fetch auszulösen, verwenden Sie die Optionen FETCHCOLS und FETCHMODCOLS[EXCEPT] des Extract-Parameters TABLE. FETCHCOLS erzwingt einen Abruf von Werten, die nicht im Log enthalten sind. FETCHMODCOLS oder FETCHMODCOLS[EXCEPT] erzwingt einen Abruf von Werten in den Logs. Diese Parameter stellen zusammen sicher, dass die verschlüsselten Spalten immer aus der Datenbank abgerufen werden.

Im Folgenden finden Sie ein Beispiel für die Konfiguration von Extract zur Unterstützung der Verschlüsselung. In diesem Beispiel lautet die verschlüsselte Spalte cardnum.

TABLE ab.payments, FETCHCOLS (cardnum), FETCHMODCOLS (cardnum);

Transaktionslogs vorbereiten

Um DML-Vorgänge zu erfassen, liest Oracle GoldenGate die Onlinelogs. Um die Kontinuität und Integrität der Oracle GoldenGate-Verarbeitung sicherzustellen, müssen die Logs wie in den folgenden Abschnitten beschrieben konfiguriert werden:

Sekundären Abschneidungspunkt initialisieren

Richten Sie vor der Ausführung des Oracle GoldenGate Extract-Prozesses einen Truncation Point für das sekundäre Log im Quellsystem ein. Extract verwendet den sekundären Abschneidepunkt, um Daten zu identifizieren, die noch verarbeitet werden müssen.

Um den sekundären Abschneidepunkt zu initialisieren, melden Sie sich als Benutzer mit sa_role-Berechtigungen bei der Datenbank an, und geben Sie dann den folgenden Befehl aus:

dbcc settrunc( 'ltm', valid )

Standardmäßig verwaltet Extract den sekundären Abschneidepunkt, sobald er eingerichtet ist. Lassen Sie nicht zu, dass Extract länger als nötig gestoppt wird. Andernfalls könnte das Log später gefüllt werden, und die Datenbank wird angehalten. Die einzige Möglichkeit, dieses Problem zu beheben, besteht darin, den sekundären Truncation Point zu deaktivieren und außerhalb von Oracle GoldenGate zu verwalten und dann das Transaktionslog zu löschen. Daten, die noch nicht von Extract verarbeitet wurden, gehen verloren, und Sie müssen die Quell- und Zieldaten erneut synchronisieren.

Um zu steuern, wie der sekundäre Abschneidepunkt verwaltet wird, verwenden Sie den Parameter TRANLOGOPTIONS. Weitere Informationen finden Sie unter Referenz für Oracle GoldenGate für Windows und UNIX.

Größe der Logs festlegen und beibehalten

Behalten Sie genügend Logdaten im Quellsystem bei, damit Extract von seinen Checkpoints aus neu gestartet werden kann, nachdem Sie sie gestoppt haben oder ein ungeplanter Ausfall auftritt. Extract muss Zugriff auf das Log haben, das den Start der ältesten nicht festgeschriebenen Arbeitseinheit und danach alle Logs enthält. Um zu bestimmen, wo sich die Extract-Checkpoints befinden, verwenden Sie den Befehl INFO EXTRACT. Weitere Informationen zu INFO EXTRACT finden Sie unter Referenz für Oracle GoldenGate für Windows und UNIX.

Wenn Daten, die Extract während der Verarbeitung benötigt werden, weder in Online- noch in Backuplogs aufbewahrt werden, kann eine der folgenden Korrekturmaßnahmen erforderlich sein:

Stellen Sie sicher, dass Sie keine Backup- oder Archivierungsoptionen verwenden, die dazu führen, dass alte Archivdateien durch neue Backups im Quellsystem überschrieben werden. Neue Backups sollten separate Dateien mit anderen Namen als ältere sein. Dadurch wird sichergestellt, dass Extract, wenn ein bestimmtes Log gesucht wird, weiterhin vorhanden ist. Außerdem wird sichergestellt, dass die Daten verfügbar sind, falls sie für einen Supportfall benötigt werden.

Transaktions-Logging aktivieren

Verwenden Sie den Befehl ADD TRANDATA, um jede Quelltabelle für die Replikation zu markieren. Dieser Befehl verwendet die Sybase-Systemprozeduren sp_setreptable und sp_setrepcol. ADD TRANDATA ist die empfohlene Möglichkeit, die Tabellen zu markieren, anstatt diese Prozeduren über die Datenbankschnittstelle zu verwenden. Der Eigentümer oder der Systemadministrator können sie jedoch bei Bedarf verwenden. Weitere Informationen finden Sie in der Dokumentation zu Sybase.

So markieren Sie Tabellen für die Replikation mit ADD TRANDATA:

Führen Sie den Befehl ADD TRANDATA für jede Tabelle aus, die markiert werden soll. Die Syntax des ADD TRANDATA-Befehls lautet:

ADD TRANDATA SCHEMA.TABLE LOBSNEVER | LOBSALWAYS | LOBSALWAYSNOINDEX | LOBSIFCHANGED

LOBSNEVER | LOBSALWAYS | LOBSALWAYSNOINDEX | LOBSIFCHANGED steuert, ob LOB-Daten nie propagiert, nur propagiert werden, wenn sie geändert (Standard) oder immer propagiert werden. LOBSIFCHANGED ist der Standardwert, wenn keine LOB-Option angegeben ist. Der Befehl ADD TRANDATA überschreibt die LOB-Replikationseinstellung, die derzeit für die Tabelle festgelegt ist.

Hinweis: Einige ADD TRANDATA-Optionen aktivieren die Option ALWAYS_REPLICATE von sp_setrepcol. Wenn eine LOB-Spalte einen NULL-Wert enthält und dann eine andere Spalte in der Tabelle aktualisiert wird (jedoch nicht LOB), wird LOB nicht erfasst, obwohl ALWAYS_REPLICATE aktiviert ist.