Einstellungen und Anforderungen für Transaktionslogs

Oracle GoldenGate nutzt die Redo-Logs, um die Daten zu erfassen, die zum Replizieren von Quelltransaktionen benötigt werden. Die Oracle-Redo-Logs im Quellsystem müssen korrekt konfiguriert sein, bevor Sie die Oracle GoldenGate-Verarbeitung starten.

Dieser Abschnitt behandelt die folgenden Logging-Ebenen, die für Oracle GoldenGate gelten. Die von Ihnen verwendete Logebene hängt von den von Ihnen verwendeten Oracle GoldenGate-Features ab.

Hinweis: Das Redo-Volume wird durch dieses erforderliche Logging erhöht. Sie können warten, bis Sie die Oracle GoldenGate-Verarbeitung starten können, um das Logging zu aktivieren.

In dieser Tabelle werden die Oracle GoldenGate-Anwendungsfälle für die verschiedenen Logging-Eigenschaften angezeigt.

Option Logging Befehlsname Funktion Anwendungsfall
Erzwungener Logging-Modus ALTER DATABASE FORCE LOGGING; Erzwingt das Logging aller Transaktionen und Ladevorgänge. Sehr empfehlenswert für alle Oracle GoldenGate-Anwendungsfälle. FORCE LOGGING setzt alle NOLOGGING-Einstellungen auf Tabellenebene außer Kraft.

Zusätzliches Logging auf Datenbankebene

Siehe Subset-Datenbankreplikationsprotokoll aktivieren.

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; Ermöglicht minimales zusätzliches Logging, um Zeilenverkettungsinformationen zum Redo Log hinzuzufügen. Für alle Oracle GoldenGate-Anwendungsfälle erforderlich
Zusätzliches Logging auf Schemaebene [ADD SCHEMATRANDATA](/pls/topic/lookup?ctx=en/database/goldengate/core/26/coredoc&id=GCLIR-GUID-5DA7C3DC-5D87-4A8B-AD23-6EF587A5CF41)

Aktiviert das bedingungslose zusätzliche Logging des Primärschlüssels und das bedingte zusätzliche Logging eindeutiger Schlüssel und Fremdschlüssel aller Tabellen in einem Schema. Alle diese Schlüssel zusammen werden als Planungsspalten bezeichnet.

Mit dieser Einstellung wird auch sichergestellt, dass jedes neue Objekt, das in diesem Schema erstellt wird, über das entsprechende zusätzliche Logging verfügt.

Aktiviert das Logging für alle aktuellen und zukünftigen Tabellen im Schema. Wenn der Primärschlüssel, der eindeutige Schlüssel und die Fremdschlüsselspalten in Quelle und Ziel nicht identisch sind, verwenden Sie ALLCOLS.
Zusätzliches Logging auf Schemaebene mit bedingungslosem Logging für alle unterstützten Spalten. (Informationen zu nicht unterstützten Spaltentypen finden Sie unter Ergänzendes Logging auf Schemaebene aktivieren.) ADD SCHEMATRANDATA mit Option ALLCOLS

Aktiviert das bedingungslose zusätzliche Logging aller Spalten in einer Tabelle für alle Tabellen in einem Schema.

Mit dieser Einstellung wird auch sichergestellt, dass jedes neue Objekt, das in diesem Schema erstellt wird, über das entsprechende zusätzliche Logging verfügt.

Wird für bidirektionale und aktiv-aktive Konfigurationen verwendet, bei denen alle Spaltenwerte geprüft werden, nicht nur die geänderten Spalten, wenn versucht wird, eine Aktualisierung oder einen Löschvorgang durchzuführen. Dies erfordert mehr Ressourcen, ermöglicht jedoch die höchste Ebene der Echtzeit-Datenvalidierung und somit der Konflikterkennung.

Diese Methode sollte auch verwendet werden, wenn sie den Parameter HANDLECOLLISIONS für anfängliche Ladevorgänge verwenden.

Zusätzliches Logging auf Schemaebene, minimale Einstellung ADD SCHEMATRANDATA mit Option NOSCHEDULINGCOLS

Aktiviert das bedingungslose zusätzliche Logging des Primärschlüssels und aller gültigen eindeutigen Indizes aller Tabellen in einem Schema.

Mit dieser Einstellung wird auch sichergestellt, dass jedes neue Objekt, das in diesem Schema erstellt wird, über das entsprechende zusätzliche Logging verfügt.

Nur für nicht integriertes Replicat verwenden. Dies ist das minimal erforderliche Logging auf Schemaebene.

Zusätzliches Logging auf Tabellenebene mit integrierter Unterstützung für integriertes Replicat

Siehe Ergänzendes Logging auf Tabellenebene aktivieren

 ADD TRANDATA Aktiviert das bedingungslose zusätzliche Logging des Primärschlüssels und das bedingte zusätzliche Logging eindeutiger Schlüssel und Fremdschlüssel einer Tabelle. Alle diese Schlüssel zusammen werden als Planungsspalten bezeichnet. Für alle Oracle GoldenGate-Anwendungsfälle erforderlich, es sei denn, das zusätzliche Logging auf Schemaebene wird verwendet. Wenn der Primärschlüssel, der eindeutige Schlüssel und die Fremdschlüsselspalten in Quelle und Ziel nicht identisch sind, verwenden Sie ALLCOLS.
Zusätzliches Logging auf Tabellenebene mit bedingungslosem Logging für alle unterstützten Spalten. (Informationen zu nicht unterstützten Spaltentypen finden Sie unter Ergänzendes Logging auf Tabellenebene aktivieren.) ADD TRANDATA mit Option ALLCOLS Aktiviert das bedingungslose zusätzliche Logging aller Tabellenspalten.

Wird für bidirektionale und aktiv-aktive Konfigurationen verwendet, bei denen alle Spaltenwerte geprüft werden, nicht nur die geänderten Spalten, wenn versucht wird, eine Aktualisierung oder einen Löschvorgang durchzuführen. Dies erfordert mehr Ressourcen, ermöglicht jedoch die höchste Ebene der Echtzeit-Datenvalidierung und somit der Konflikterkennung.

Sie kann auch verwendet werden, wenn die Primär-, Unique- und Fremdschlüssel der Quelle und des Ziels nicht identisch sind oder sich zwischen Quelle und Ziel ständig ändern.
Zusätzliches Logging auf Tabellenebene, minimale Einstellung ADD TRANDATA mit Option NOSCHEDULINGCOLS Aktiviert das bedingungslose zusätzliche Logging des Primärschlüssels und aller gültigen eindeutigen Indizes einer Tabelle. Verwendung für nicht integriertes Replicat und nicht paralleles Replicat. Dies ist das minimal erforderliche Logging auf Tabellenebene.
Zusätzliches Logging auf Tabellenebene für JSON Relational Duality Views und JSON Collection Tables. ADD TRANDATA mit Duality View name und Collection Table name Aktiviert zusätzliches Logging für die angegebenen Dualitätsansichten und Collection-Tabellen. Richtlinien finden Sie unter Ergänzendes Logging für JSON Relational Duality Views und JSON-Collection-Tabellen aktivieren. Weitere Informationen finden Sie unter Details zur Unterstützung von JSON-Relational Duality Views und JSON-Collection-Tabellen.

Subset-Datenbankreplikationsprotokoll aktivieren

Oracle empfiehlt dringend, die Oracle-Quelldatenbank in den erzwungenen Logging-Modus zu versetzen. Im Force Logging-Modus wird das Logging aller Transaktionen und Ladevorgänge erzwungen, und alle gegenteiligen Benutzer- oder Speichereinstellungen werden außer Kraft gesetzt. Dadurch wird sichergestellt, dass keine Quelldaten in der Extract-Konfiguration fehlen.

In LogMiner ist ein detaillierter zusätzlicher Loggingmodus für Datenbanken mit dem Namen "Subset-Datenbankreplikation" verfügbar. Dies ist der grundlegende empfohlene Modus für alle Oracle GoldenGate- und XStream-Clients. Es ersetzt den zuvor verwendeten Modus für das zusätzliche Mindestlogging.

Das Logging der Teilmengendatenbankreplikation wird derzeit unter CDB$ROOT aktiviert (und von allen Benutzer-PDBs erbt).

Hinweis: Primärschlüssel (PK) und eindeutiges Index-Logging (UI) auf Datenbankebene werden nur dann nicht empfohlen, wenn Sie eine Teilmenge von Tabellen replizieren. Sie können sie mit Live Standby verwenden, oder wenn Oracle GoldenGate alle Tabellen replizieren wird, um die Ausfallzeit für eine Migration oder ein Upgrade zu reduzieren.

Führen Sie die folgenden Schritte aus, um das Logging der Teilmengen-Datenbankreplikation und das erzwungene Logging zu prüfen und zu aktivieren.

  1. Melden Sie sich bei SQL*Plus als Benutzer mit der Berechtigung ALTER SYSTEM an.

  2. Setzen Sie den folgenden Befehl ab, um zu bestimmen, ob sich die Datenbank im zusätzlichen Loggingmodus und im erzwungenen Loggingmodus befindet. Wenn das Ergebnis für beide Abfragen YES lautet, erfüllt die Datenbank die Oracle GoldenGate-Anforderung.

    SELECT SUPPLEMENTAL_LOG_DATA_MIN, FORCE_LOGGING FROM V$DATABASE;

  3. Wenn das Ergebnis NO für eine oder beide Eigenschaften ist, fahren Sie mit den folgenden Schritten fort, um sie nach Bedarf zu aktivieren:

    ALTER PLUGGABLE DATABASE *pdbname* ADD SUPPLEMENTAL LOG DATA SUBSET DATABASE REPLICATION;
ALTER DATABASE FORCE LOGGING;

  4. Setzen Sie den folgenden Befehl ab, um zu prüfen, ob diese Eigenschaften jetzt aktiviert sind.

    SELECT SUPPLEMENTAL_LOG_DATA_MIN, FORCE_LOGGING FROM V$DATABASE;

    Die Ausgabe der Abfrage muss für beide Eigenschaften YES lauten.

  5. Wechseln Sie zu den Protokolldateien.

    ALTER SYSTEM SWITCH LOGFILE;

Zusätzliches Logging auf Schemaebene aktivieren

Oracle GoldenGate unterstützt zusätzliches Logging auf Schemaebene. Logging auf Schemaebene ist für eine Oracle-Quell- und Zieldatenbank erforderlich, wenn das Oracle GoldenGate-DDL-Replikationsfeature verwendet wird, oder für die Quelldatenbank, wenn DDL für die zu replizierenden Tabellen ausgeführt (oder ausgeführt) werden kann. In allen anderen Anwendungsfällen ist dies optional, Sie müssen jedoch stattdessen Logging auf Tabellenebene verwenden (siehe Ergänzendes Logging auf Tabellenebene aktivieren).

Standardmäßig ermöglicht das Logging auf Schemaebene automatisch das bedingungslose zusätzliche Logging des Primärschlüssels und das bedingte zusätzliche Logging eindeutiger Schlüssel und Fremdschlüssel aller Tabellen in einem Schema. Mit den Optionen können Sie das Logging nach Bedarf ändern.

Hinweis: Oracle empfiehlt dringend, Logging auf Schemaebene anstelle von Logging auf Tabellenebene zu verwenden, da dadurch sichergestellt wird, dass alle neuen Tabellen, die einem Schema hinzugefügt werden, erfasst werden, wenn sie die Platzhalterangaben erfüllen. Diese Methode wird auch empfohlen, da Änderungen an Schlüsselspalten automatisch auch in den zusätzlichen Logdaten widergespiegelt werden. Beispiel: Wenn sich ein Schlüssel ändert, muss ADD TRANDATA nicht ausgegeben werden.

Führen Sie die folgenden Schritte auf dem Quellsystem aus, um zusätzliches Logging auf Schemaebene zu aktivieren.

  1. Starten Sie die Befehlszeile im Quellsystem.

  2. Setzen Sie den Befehl DBLOGIN mit dem Alias eines Benutzers im Zugangsdatenspeicher ab, der über die Berechtigung verfügt, zusätzliches Logging auf Schemaebene zu aktivieren.

    DBLOGIN USERIDALIAS *alias*

    Weitere Informationen zu USERIDALIAS und zusätzlichen Optionen finden Sie unter USERIDALIAS in der Referenz zu Parametern und Funktionen für Oracle GoldenGate.

  3. Wenn Sie ADD SCHEMATRANDATA oder ADD TRANDATA in einer mehrmandantenfähigen Datenbank verwenden, können Sie sich entweder direkt bei der PDB anmelden und den Befehl ausführen. Wenn Sie sich alternativ auf Root-Ebene anmelden (mit einem C##-Benutzer), müssen Sie die PDB einschließen. Setzen Sie den Befehl ADD SCHEMATRANDATA für jedes Schema ab, für das Sie Datenänderungen mit Oracle GoldenGate erfassen möchten.

    ADD SCHEMATRANDATA pdb.schema [ALLCOLS | NOSCHEDULINGCOLS]

    Wo:

    • Ohne Optionen aktiviert das Schema ADD SCHEMATRANDATA das bedingungslose zusätzliche Logging im Quellsystem des Primärschlüssels und das bedingte zusätzliche Logging aller eindeutigen Schlüssel und Fremdschlüssel aller aktuellen und zukünftigen Tabellen im angegebenen Schema. Beim nicht bedingten Logging wird das Schreiben des Primärschlüssels in das Log erzwungen, unabhängig davon, ob der Schlüssel im aktuellen Vorgang geändert wurde. Beim bedingten Logging werden alle Spaltenwerte eines Fremdschlüssels oder eindeutigen Schlüssels protokolliert, wenn mindestens einer davon im aktuellen Vorgang geändert wurde. Der Standardwert ist optional, um nicht integriertes Replicat zu unterstützen, ist jedoch erforderlich, um integriertes Replicat zu unterstützen, da Primärschlüssel, eindeutige Schlüssel und Fremdschlüssel für den eingehenden Server zur Berechnung von Abhängigkeiten verfügbar sein müssen.

    • ALLCOLS kann verwendet werden, um das bedingungslose zusätzliche Logging aller Spalten einer Tabelle zu aktivieren und gilt für alle aktuellen und zukünftigen Tabellen im angegebenen Schema. Wird verwendet, um integriertes Replicat zu unterstützen, wenn Quell- und Zieltabellen unterschiedliche Planungsspalten aufweisen. (Planungsspalten sind der Primärschlüssel, der eindeutige Schlüssel und der Fremdschlüssel.)

    • NOSCHEDULINGCOLS protokolliert nur die Werte des Primärschlüssels und alle gültigen eindeutigen Indizes für vorhandene Tabellen im Schema und neue Tabellen, die später hinzugefügt werden. Dies ist die minimal erforderliche Logging-Ebene auf Schemaebene und gilt nur für Replicat im nicht integrierten Modus.

    Im folgenden Beispiel aktiviert der Befehl das zusätzliche Standardlogging für das Schema hr.

    ADD SCHEMATRANDATA pdbeast.hr ALLCOLS

    Im folgenden Beispiel aktiviert der Befehl das zusätzliche Logging nur für den Primärschlüssel und gültige eindeutige Indizes für das Schema HR.

    ADD SCHEMATRANDATA pdbeast.hr NOSCHEDULINGCOLS

Zusätzliches Logging auf Tabellenebene aktivieren

Aktivieren Sie das zusätzliche Logging auf Tabellenebene im Quellsystem in den folgenden Fällen:

Führen Sie die folgenden Schritte im Quellsystem aus, um zusätzliches Logging auf Tabellenebene zu aktivieren, oder verwenden Sie die optionalen Funktionen des Befehls.

  1. Führen Sie die Befehlszeile im Quellsystem aus.

  2. Geben Sie den Befehl DBLOGIN mit dem Alias eines Benutzers im Zugangsdatenspeicher aus, der berechtigt ist, zusätzliches Logging auf Tabellenebene zu aktivieren.

    DBLOGIN USERIDALIAS *alias*

    Weitere Informationen zu DBLOGIN und zusätzlichen Optionen finden Sie unter USERIDALIAS in der Referenz zu Parametern und Funktionen für Oracle GoldenGate.

  3. Setzen Sie den Befehl ADD TRANDATA ab.

    ADD TRANDATA [*PDB*.]*schema.**table* [, COLS (*columns)*] [, NOKEY] [, ALLCOLS | NOSCHEDULINGCOLS]

    Wo:

    • PDB ist der Name des Root-Containers oder der integrierbaren Datenbank, wenn sich die Tabelle in einer mehrmandantenfähigen Containerdatenbank befindet.

    • Schema ist das Quellschema, das die Tabelle enthält.

    • Tabelle ist der Name der Tabelle. Anweisungen zur Angabe von Objektnamen finden Sie unter Objektnamen in Oracle GoldenGate-Eingabe angeben.

    • ADD TRANDATA ohne andere Optionen aktiviert automatisch das bedingungslose zusätzliche Logging des Primärschlüssels und das bedingte zusätzliche Logging eindeutiger Schlüssel und Fremdschlüssel der Tabelle. Beim nicht bedingten Logging wird das Schreiben des Primärschlüssels in das Log erzwungen, unabhängig davon, ob der Schlüssel im aktuellen Vorgang geändert wurde. Beim bedingten Logging werden alle Spaltenwerte eines Fremdschlüssels oder eindeutigen Schlüssels protokolliert, wenn mindestens einer davon im aktuellen Vorgang geändert wurde. Der Standardwert ist optional, um nicht integriertes Replicat zu unterstützen (siehe auch NOSCHEDULINGCOLS), ist jedoch erforderlich, um integriertes Replicat zu unterstützen, da Primärschlüssel, eindeutige Schlüssel und Fremdschlüssel für den eingehenden Server zur Berechnung von Abhängigkeiten verfügbar sein müssen.

    • ALLCOLS aktiviert das bedingungslose zusätzliche Logging aller Spalten der Tabelle. Wird verwendet, um integriertes Replicat zu unterstützen, wenn Quell- und Zieltabellen unterschiedliche Planungsspalten aufweisen. (Planungsspalten sind der Primärschlüssel, der eindeutige Schlüssel und der Fremdschlüssel.)

    • NOSCHEDULINGCOLS ist nur für Replicat im nicht integrierten Modus gültig. Er gibt einen ALTER TABLE-Befehl mit einer ADD SUPPLEMENTAL LOG DATA ALWAYS-Klausel aus, die für den Typ des eindeutigen Constraints geeignet ist, der für die Tabelle definiert ist, oder mit allen Spalten, die kein eindeutiges Constraint aufweisen. Dieser Befehl erfüllt die grundlegenden Logginganforderungen auf Tabellenebene von Oracle GoldenGate, wenn das Logging auf Schemaebene nicht verwendet wird. Informationen dazu, wie Oracle GoldenGate einen Schlüssel oder Index auswählt, finden Sie unter Eindeutigkeit von Zeilen in Quell- und Zieltabelle sicherstellen.

    • COLS columns protokolliert Nicht-Schlüsselspalten, die für eine KEYCOLS-Klausel oder zum Filtern und Bearbeiten erforderlich sind. Die Klammern sind erforderlich. Diese Spalten werden zusätzlich zum Primärschlüssel protokolliert, es sei denn, die Option NOKEY ist ebenfalls vorhanden.

    • NOKEY verhindert das Logging des Primärschlüssels oder eindeutigen Schlüssels. Erfordert eine KEYCOLS-Klausel in den Parametern TABLE und MAP und eine COLS-Klausel im Befehl ADD TRANDATA, um die alternativen KEYCOLS-Spalten zu protokollieren.

  4. Wenn Sie ADD TRANDATA mit der Option COLS verwenden, erstellen Sie einen eindeutigen Index für diese Spalten im Ziel, um den Zeilenabruf zu optimieren. Wenn Sie diese Spalten als Ersatzschlüssel für eine KEYCOLS-Klausel protokollieren, notieren Sie sich, dass Sie die KEYCOLS-Klausel bei der Konfiguration der Oracle GoldenGate-Prozesse zu den Anweisungen TABLE und MAP hinzufügen.

Zusätzliches Logging für relationale JSON-Dualitätsansichten und JSON-Collection-Tabellen aktivieren

Bevor Sie JSON Relational Duality Views und JSON Collection Tables replizieren, müssen Sie zusätzliches Logging in Oracle GoldenGate einrichten. Standardmäßig ist das zusätzliche Logging für JSON Relational Duality Views und JSON-Collection-Tabellen nicht aktiviert. Sie können die folgenden Richtlinien verwenden, wenn Sie zusätzliches Logging für Dualitätsansichten und Collection-Tabellen aktivieren:

Die Schritte zum Einrichten von zusätzlichem Logging auf Tabellenebene finden Sie unter Ergänzendes Logging auf Tabellenebene aktivieren.

Zusätzliches Logging auf Tabellenebene entfernen

Wenn eine Tabelle nicht mehr von Oracle GoldenGate erfasst werden muss und der Parameter TABLE für die Tabelle aus der Extract-Parameterdatei entfernt wurde oder TABLEEXCLUDE zum Ausschließen der Tabelle aus einer Platzhalteranweisung verwendet wird, kann zusätzliches Logging aus der Tabelle entfernt werden.

Hinweis: Wenn der Extract eine Tabelle auflöst, für die kein zusätzliches Logging aktiviert ist, wird er je nach DML-Vorgangstyp abgebrochen.

Wenn Sie DELETE TRANDATA verwenden, um zusätzliches Logging zu entfernen, wird die Replicat Identity-Ebene der Tabelle auf NOTHING gesetzt. Das zusätzliche Logging kann über die Microservices Architecture-Weboberfläche auf der Seite "Administrationsservice, Konfiguration" unter den für eine Quelldatenbank erstellten Zugangsdaten deaktiviert oder mit dem Befehl DELETE TRANDATA abgesetzt werden.

Die folgende Syntax lautet für die Ausgabe von DELETE TRANDATA.

DBLOGIN USERIDALIAS alias_name
DELETE TRANDATA schema.tablename

So prüfen Sie die Ebene der zusätzlichen Protokollierung:

INFO TRANDATA schema.tablename