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.
-
Ein Löschvorgang wird für
emp_srcausgeführt. -
Ein Löschvorgang wird in
salary_srckaskadiert. -
Oracle GoldenGate sendet beide Löschvorgänge an das Ziel.
-
Der übergeordnete Löschvorgang kommt zuerst an und wird auf
emp_targangewendet. -
Der übergeordnete Löschvorgang kaskadiert einen Löschvorgang in
salary_targ. -
Der kaskadierte Löschvorgang aus
salary_srcwird aufsalary_targangewendet. -
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:
-
Weisen Sie dem Replicat-Benutzer die Replikationsrolle zu.
-
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:
-
Die Tabelle, in der die verschlüsselten Spalten enthalten sind, muss einen Primärschlüssel oder einen eindeutigen Schlüssel aufweisen.
-
Spalten, die Verschlüsselung verwenden, können nicht Teil des Primärschlüssels sein.
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:
-
Möglicherweise müssen Sie den Extract so ändern, dass er ab einem späteren Zeitpunkt erfasst wird, für den Logdaten verfügbar sind (und einen möglichen Datenverlust auf dem Ziel akzeptieren). Dies kann mit dem Befehl
ALTER EXTRACTerreicht werden. -
Möglicherweise müssen Sie die Quell- und Zieltabellen neu synchronisieren und dann die Oracle GoldenGate-Umgebung erneut starten.
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.