TABLE | MAP

Gültig für

TABLE ist für Extract gültig. Sie können TABLE nur mit Replicat und dem Parameter EVENTACTIONS verwenden. MAP ist für Extract in bestimmten Situationen und Replicat gültig. Weitere Einzelheiten finden Sie unter MAP für Extract.

Beschreibung

Die Parameter TABLE und MAP steuern die Auswahl, Zuordnung und Bearbeitung der Objekte, die von einem Oracle GoldenGate-Prozess betroffen sein sollen. Diese Parameter funktionieren wie folgt:

TABLE und MAP sind für Konfigurationen zum erstmaligen Laden und für Onlineprozesse gültig, die zur Unterstützung der Replikation von Transaktionsänderungen konfiguriert sind.

Sie können die folgenden Objekte mit TABLE und MAP verarbeiten:

Um eine Sequenz für die Erfassung nach Extract anzugeben, verwenden Sie den Parameter SEQUENCE.

Hinweis: Oracle GoldenGate unterstützt die Replikation tatsächlicher Datenwerte von Oracle Materialized Views.

Sie können eine oder mehrere TABLE- oder MAP-Anweisungen in einer Parameterdatei mit oder ohne Platzhalter verwenden, um alle Objekte anzugeben, die Sie verarbeiten möchten.

Sie können Objekte aus einer mit Platzhaltern versehenen TABLE- oder MAP-Anweisung mit den folgenden Parametern ausschließen:

Standard

Keine

Syntax für TABLE

Bei Tabellen können Sie alle TABLE-Optionen verwenden. Verwenden Sie für Nicht-Tabellenobjekte TABLE nur, um ein Objekt für Capture anzugeben.

TABLE <source_table>[, TARGET <target_table>]
[, ATTRCHARSET (<charset>)]
[, CHARSET <character_set>]
[, COLCHARSET <character_set>]
[, COLMAP (<column_mapping>)]
[, {COLS | COLSEXCEPT} (<column_list>)]
[, {DEF | TARGETDEF} <template>]
[, EVENTACTIONS <action>]
[, EXITPARAM '<parameter>']
[, {FETCHCOLS | FETCHCOLSEXCEPT} (<column_list>)]
[, {FETCHMODCOLS | FETCHMODCOLSEXCEPT} (<column_list>)]
[, FETCHBEFOREFILTER]
[, FILTER (<filter_clause>)]
[, GETBEFORECOLS (<column_specification>)]
[, KEYCOLS (<columns>)]
[, SQLEXEC (<SQL_specification>)]
[, SQLPREDICATE 'WHERE <where_clause>']
[, TOKENS (<token_definition>)]
[, TRIMSPACES | NOTRIMSPACES]
[, TRIMVARSPACES | NOTRIMVARSPACES]
[, WHERE (<clause>)]
[, <container>.]<schema.table> PARTITIONOBJID <ptn_object_ID> [, <ptn_object_ID>]
;

Syntax für MAP

MAP <source_table>, TARGET <target_table>
[, MOD_COMPARE_COLS( <tgt_col> = <source> )]
[, COLMAP (<column_mapping>)]
[, COMPARECOLS (<column_specification>)]
[, COORDINATED]
[, {DEF | TARGETDEF} <template>]
[, EXCEPTIONSONLY]
[, EXITPARAM '<parameter>']
[, EVENTACTIONS (<action>)]
[, FILTER (<filter_clause>)]
[, HANDLECOLLISIONS | NOHANDLECOLLISIONS]
[, INSERTALLRECORDS]
[, INSERTAPPEND | NOINSERTAPPEND]
[, KEYCOLS (<columns>)]
[, MAPALLCOLUMNS | NOMAPALLCOLUMNS]
[, MAPEXCEPTION (<exceptions_mapping>)]
[, MAPINVISIBLECOLUMNS | NOMAPINVISIBLECOLUMNS]
[, REPERROR (<error>, <response>)]
[, RESOLVECONFLICT (<conflict_resolution_specification>)]
[, SQLEXEC (<SQL_specification>)]
[, THREAD (<thread_ID>)]
[, THREADRANGE (<thread_range>[, <column_list>])]
[, TRIMSPACES | NOTRIMSPACES]
[, TRIMVARSPACES | NOTRIMVARSPACES]
[, WHERE (<clause>)]
[, <container>.]<schema.table> PARTITIONOBJID <ptn_object_ID> [, <ptn_object_ID>]
;

Optionen für TABLE und MAP

In der folgenden Tabelle werden die Optionen zusammengefasst, die für die Parameter TABLE und MAP verfügbar sind. Beachten Sie, dass nicht alle Optionen für beide Parameter gültig sind.

Tabelle 11: Zusammenfassung der Syntaxkomponenten TABLE und MAP

Komponente Beschreibung Gültig für
MAP MOD_COMPARE_COL( tgt_col = source [,...] ) Dies ist ein reiner Replicat-Parameter. Weist dem Before Image der Zielspalte einen angegebenen Quellwert als Schlüsselwert zu, und der Wert wird für die WHERE-Klausel verwendet. MAP
TABLE <source_table>[, TARGET <target>] Gibt das Quellobjekt in einer TABLE-Anweisung für Extract und eine optionale Zuordnung zu einem Zielobjekt an. Wird in der Extract-Parameterdatei verwendet. TABLE
MAP source_table, TARGET target_table Gibt die Zuordnung des Quell-Zielobjekts für den Replicat-Prozess an. Wird in der Replicat-Parameterdatei verwendet. MAP
ATTRCHARSET (charset) Gibt die Quellzeichensatzinformationen auf UDT-Attributebene an. TABLE
COLCHARSET character_set Gibt einen unterstützten Zeichensatz an. TABLE
COLMAP (column_mapping) Ordnet Datensätze zwischen verschiedenen Quell- und Zielspalten zu. TABLE und MAP
{COLS \| COLSEXCEPT} (column_list) Wählt Spalten für die Verarbeitung aus oder schließt sie aus. TABLE
COMPARECOLS (column_specification) Gibt Spalten an, die für die Konflikterkennung und -auflösung verwendet werden sollen. TABLE und MAP
COORDINATED Erzwingt die Verarbeitung einer Transaktion als Sperrtransaktion. MAP
{DEF | TARGETDEF} template Gibt eine Vorlage für Quell- oder Zieldefinitionen an. TABLE und MAP
EXCEPTIONSONLY Gibt an, dass die MAP-Anweisung eine Exceptions-Anweisung MAP ist. MAP
EVENTACTIONS (action) Löst eine Aktion aus, die auf einem Datensatz basiert, der eine angegebene Filterregel erfüllt. TABLE und MAP
EXITPARAM 'parameter' Übergibt einen Parameter in Form einer Literalzeichenfolge an einen User Exit. TABLE und MAP
FETCHBEFOREFILTER Leitet die Aktion FETCHCOLS oder FETCHCOLSEXCEPT an, die ausgeführt werden soll, bevor ein Filter ausgeführt wird. TABLE
{FETCHCOLS | FETCHCOLSEXCEPT} (column_list) Ermöglicht das Abrufen von Spaltenwerten aus der Quelldatenbank, wenn die Werte nicht im Transaktionsdatensatz enthalten sind. TABLE
{FETCHMODCOLS | FETCHMODCOLSEXCEPT} (column_list) Erzwingt, dass Spaltenwerte aus der Datenbank abgerufen werden, wenn die Spalten im Transaktionslog vorhanden sind. TABLE
FILTER (filter_clause) Wählt Datensätze basierend auf einem numerischen Wert aus. FILTER bietet mehr Flexibilität als WHERE. TABLE und MAP
GETBEFORECOLS (column_specification) Erzwingt vor Bildern von Spalten, die erfasst und in den Trail geschrieben werden sollen. TABLE
HANDLECOLLISIONS \| NOHANDLECOLLISIONS Stimmt die Ergebnisse von Änderungen ab, die durch einen anfänglichen Ladeprozess an der Zieltabelle vorgenommen wurden, mit denen, die von einer Änderungssynchronisierungsgruppe angewendet wurden. MAP
INSERTALLRECORDS Wendet alle Zeilenänderungen als Einfügungen an. MAP
INSERTAPPEND \| NOINSERTAPPEND Steuert, ob Replicat einen Oracle APPEND-Hint für INSERT-Anweisungen verwendet. MAP
KEYCOLS (columns) Gibt Spalten an, die Zeilen eindeutig kennzeichnen. TABLE und MAP
MAPALLCOLUMNS | NOMAPALLCOLUMNS Steuert, ob Replicat Nicht-Schlüsselspalten abruft. NA
MAPEXCEPTION (exceptions_mapping) Gibt an, dass die MAP-Anweisung Ausnahmen für Tabellen mit Platzhaltern enthält. MAP
MAPINVISIBLECOLUMNS | NOMAPINVISIBLECOLUMNS Steuert, ob Replicat unsichtbare Spalten in Oracle-Zieltabellen für die Standardspaltenzuordnung enthält. Für unsichtbare Spalten in Oracle-Zieltabellen, die explizites Spaltenmapping verwenden, werden sie immer zugeordnet, sodass diese Option nicht erforderlich ist. MAP
REPERROR (error, response) Steuert, wie Replicat bei der Ausführung der MAP-Anweisung auf Fehler reagiert. MAP
RESOLVECONFLICT (conflict_resolution_specification) Gibt Regeln für die Konfliktlösung an. MAP
SQLEXEC (SQL_specification) Führt Stored Procedures und Abfragen aus. TABLE und MAP
SQLPREDICATE 'WHERE where_clause' Ermöglicht es einer WHERE-Klausel, Zeilen für einen anfänglichen Ladevorgang auszuwählen. TABLE
THREAD (thread_ID) Gültig für Replicat im koordinierten Modus. Gibt an, dass die MAP-Anweisung vom angegebenen Replicat-Thread verarbeitet wird. MAP
THREADRANGE (thread_range, column_list) Gültig für Replicat im koordinierten Modus. Gibt an, dass die MAP-Anweisung vom angegebenen Bereich von Replicat-Threads verarbeitet wird. MAP
TOKENS (token_definition) Definiert Benutzertoken. TABLE
TRIMSPACES \| NOTRIMSPACES Steuert, ob nachgestellte Leerzeichen abgeschnitten werden, wenn CHAR Spalten VARCHAR zugeordnet wird. TABLE und MAP
TRIMVARSPACES \| NOTRIMVARSPACES Steuert, ob nachgestellte Leerzeichen abgeschnitten werden, wenn VARCHAR den Spalten CHAR oder VARCHAR zugeordnet wird. TABLE und MAP
WHERE (clause) Wählt Datensätze basierend auf Bedingungsoperatoren aus. TABLE und MAP
; (Semikolon) Beendet die TABLE- oder MAP-Anweisung und ist erforderlich. TABLE und MAP
PARTITIONOBJID Für integrierten Extract verfügbar. Mit dieser Option werden die Objekt-IDs der Partitionen angegeben, die für partitionierte Tabellen erfasst werden sollen. TABLE und MAP

MAP MOD_COMPARE_COL( tgt_col = Quelle [,…] )

tgt_col muss ein Zieltabellenspaltenname sein und die Schlüsselspalte sein, damit sie ordnungsgemäß wirksam wird. source kann eine Quelltabellenspalte, ein konstanter Wert (Zahl oder Zeichenfolge), eine Spaltenzuordnungsfunktion oder SQLEXEC-Ergebnisse sein. Beispiel: source col1 wird target col 1. source col1 zugeordnet, bevor der Imagewert 1 ist. Dies ist ein Dummywert, da er aus Sicherheitsgründen vom DBA maskiert wird. Replicat kann den Istwert vor dem Imagewert target col1 durch SQLEXEC abfragen. Mit MOD_COMPARE_COLS() ersetzt Replicat den Dummy-Wert source col1 durch das Ergebnis SQLEXEC, sodass der Vorgang UPDATE oder DELETE ordnungsgemäß funktioniert.

TABLE <source_table>[, TARGET <target>]

TABLE ist in einer Extract-Parameterdatei gültig.

Geben Sie mit TABLE ein Quellobjekt an, für das Extract Daten erfassen soll. Geben Sie den vollqualifizierten zweiteiligen oder dreiteiligen Namen des Objekts an, z.B. <schema.table> oder <catalog.schema.table>. Mit einem Platzhalter können Sie mehrere Objekte mit einer TABLE-Anweisung angeben. Informationen zum korrekten Angeben von Objektnamen und Platzhaltern finden Sie unter Platzhalter in Datenbankobjektnamen verwenden und Platzhalter in Befehlsargumenten verwenden in der Oracle GoldenGate-Microservices-Dokumentation.

Verwenden Sie die Option TARGET nur, wenn Extract eine Zieldefinitionsdatei (mit dem Parameter TARGETDEFS angegeben) referenzieren muss, um Konvertierungen auszuführen, oder wenn die Option COLMAP zum Zuordnen von Spalten verwendet wird. Andernfalls kann er von einem TABLE-Parameter ausgelassen werden. Spaltenmapping mit COLMAP und Konvertierungsarbeiten werden normalerweise im Zielsystem ausgeführt, um die Auswirkungen von Replikationsaktivitäten auf das Quellsystem zu minimieren. Sie können jedoch bei Bedarf im Quellsystem ausgeführt werden. Beispiel: Spaltenzuordnung und -konvertierung können auf dem Quellsystem in einer Konfiguration ausgeführt werden, in der mehrere Quellen und ein Ziel vorhanden sind. In diesem Szenario kann es einfacher sein, eine Zieldefinitionsdatei zu verwalten, anstatt eine Definitionsdatei für jede Quelldatenbank zu verwalten, insbesondere wenn häufige Anwendungsänderungen erforderlich sind, dass neue Definitionsdateien generiert werden.

Wenn Sie TARGET in einem TABLE-Parameter verwenden, werden die Metadaten der extrahierten Daten basierend auf der Zielstruktur und nicht auf der Quellstruktur identifiziert, um die Struktur des Datensatzes widerzuspiegeln, der in der Definitionsdatei oder der Spaltenzuordnung widergespiegelt wird. Verwenden Sie keine dreiteiligen Namen, wenn TARGET Tabellen in einer Oracle-Zielcontainerdatenbank angibt. Replicat kann nur eine Verbindung zu einem Container oder Katalog herstellen. Daher wird davon ausgegangen, dass der Container oder Katalogteil des Namens mit dem Namen identisch ist, bei dem sich Replicat anmeldet (je nach Datenbank wie mit USERIDALIAS angegeben).

Wenn keine anderen TABLE-Syntaxoptionen zur Verarbeitung der angegebenen Quelldaten erforderlich sind, können Sie eine einfache TABLE-Anweisung verwenden, um sie mit einem Semikolon zu beenden.

 TABLE sales.customers;

Im Folgenden wird die Verwendung eines Platzhalters zur Angabe mehrerer Tabellen dargestellt:

 TABLE sales.*;

Die vorherigen TABLE-Anweisungen weisen Extract an, alle unterstützten Spaltendaten für die angegebenen Objekte zu erfassen und in den Trail zu schreiben, ohne dass Filterung, Konvertierung oder andere Manipulationen ausgeführt werden.

MAP <source_table>, TARGET <target_table>

MAP ist in einer Replicat-Parameterdatei gültig. Sie können MAP auch in einer Extract-Parameterdatei verwenden, um den Namen der Transaktionen zu ändern, die Oracle GoldenGate für die Tabelle speichert. Siehe

Geben Sie mit MAP ein Quellobjekt an, und geben Sie mit TARGET das Zielobjekt an, auf das Replicat die replizierten Quelldaten anwendet. Zusammen enthalten die Klauseln MAP und TARGET eine Zuordnung.

Im Folgenden wird die Verwendung eines Platzhalters zur Angabe mehrerer Tabellen gezeigt. Beachten Sie, dass die TARGET-Klausel nicht das Präfix tab vor dem Platzhalter enthält. Diese Spezifikation wäre ungültig, da der Platzhalter als sales.tabtab1, sales.tabtab2 usw. aufgelöst würde.

 MAP sales.tab*, TARGET sales.*;

Wenn keine Filterung, Zuordnung oder andere Arbeit für die Objekte erforderlich ist, können Sie einfache MAP-Anweisungen wie die folgenden verwenden, um sicherzustellen, dass jedes Objekt mit einem Semikolon beendet wird.

MAP sales.customers, TARGET sales.customers;
MAP fin.*, TARGET fin.*;

ATTRCHARSET <(charset)>

ATTRCHARSET ist gültig für TABLE.

Verwenden Sie die ATTRCHARSET-Klausel, um die Quellzeichensatzinformationen auf UDT-Attributebene anzugeben. Er überschreibt den Zeichensatz, der in der Traildatei definiert oder durch die Parameter SOURCECHARSET, CHARSET oder COLCHARSET angegeben ist.

Gültige Werte sind Zeichensatznamen und gültige UDT-Attributnamen. Platzhalterattributnamen werden unterstützt. Beispiel:

TABLE SCHEMA.T*,
  ATTRCHARSET(WE8DEC, col*.attr1, col1.attr*.attr3);

COLCHARSET <character_set>

COLCHARSET ist gültig für TABLE.

Verwenden Sie die Klausel COLCHARSET, um einen beliebigen unterstützten Zeichensatz anzugeben. Weitere Informationen dazu finden Sie in COLCHARSET.

COLMAP <(column_mapping)>

COLMAP ist gültig für TABLE und MAP.

Verwenden Sie COLMAP, um:

COLMAP enthält Anweisungen zum Auswählen, Übersetzen und Verschieben von Spaltendaten aus einer Quellspalte in eine Zielspalte. Hinweis: Um globale Regeln für die Spaltenzuordnung über alle Tabellen in nachfolgenden MAP-Anweisungen zu erstellen, verwenden Sie den Parameter COLMATCH.

Weitere Informationen zum Konfigurieren der Spaltenzuordnung

Um COLMAP zu verwenden, müssen zugehörige Konfigurationsrichtlinien berücksichtigt werden, z.B. ob Quell- und Zielspaltenstrukturen identisch oder unterschiedlich sind und ob globale Spaltenzuordnungsparameter ausreichend sein können.

Syntax

COLMAP (
[USEDEFAULTS, ]
<target_column> = <source_expression> [BINARYINPUT]
[, ...]
)

USEDEFAULTS

Ordnet Quell- und Zielspalten automatisch zu, die denselben Namen haben, wenn sie nicht in einer expliziten Spaltenzuordnung angegeben wurden. Die Datentypen werden bei Bedarf automatisch basierend auf der lokalen Datendefinitionsdatei übersetzt. Mit USEDEFAULTS ist keine explizite Spaltenzuordnung erforderlich, wenn diese Spalten denselben Namen haben und die Daten keine Filterung oder Konvertierung erfordern.

Geben Sie USEDEFAULTS vor expliziten Spaltenzuordnungen in der COLMAP-Klausel an.

<target_column = source_expression>

Definiert eine explizite Zuordnung von Quell-Zielspalten.

<target_column>

Gibt den Namen der Zielspalte an. Unterstützte Zeichen in Spaltennamen finden Sie unter Unterstützte Zeichensätze.

<source_expression>

Mögliche Optionen sind:

BINARYINPUT

Verwenden Sie BINARYINPUT, wenn die Zielspalte als binärer Datentyp definiert ist, wie RAW oder BLOB. Die Quelleingabe enthält jedoch binäre Nullen in der Mitte der Daten. Die Quelleingabe wird als Binäreingabe behandelt, und der Ersatz von Datenwerten wird unterdrückt.

Beispiel 1

MAP ggs.tran, TARGET ggs.tran2, COLMAP (loc2 = loc, type2 = type);

Beispiel 2

TABLE ggs.tran, COLMAP (SECTION = @STRCAT('\u00a7', SECTION ));

{COLS | COLSEXCEPT} (<column_list>)

COLS und COLSEXCEPT sind für TABLE gültig.

Verwenden Sie COLS und COLSEXCEPT, um die Spalten zu steuern, für die Daten erfasst werden.

Um COLS zu verwenden, ist Folgendes erforderlich:

Ohne einen Primärschlüssel, einen eindeutigen Schlüssel oder eine KEYCOLS-Klausel in der TABLE-Anweisung verwendet Oracle GoldenGate alle Spalten in der Tabelle, sodass COLS nicht mehr benötigt wird.

Hinweis: Verwenden Sie diese Option nicht für Tabellen, die im Passthrough-Modus von einer Data Pump-Extraktgruppe verarbeitet werden.

Syntax

{COLS | COLSEXCEPT} (<column> [, ...])

<column>

Der Name einer Spalte. Um mehrere <columns> anzugeben, erstellen Sie eine durch Komma getrennte Liste. Beispiel:

COLS (name, city, state, phone)

Hinweis: Wenn die Datenbank nur Werte für Spalten protokolliert, die in einem Aktualisierungsvorgang geändert wurden, ist eine Spalte, die für den Capture-Vorgang mit COLS angegeben wurde, möglicherweise nicht verfügbar. Um diese Spalten verfügbar zu machen, verwenden Sie die Option FETCHCOLS in der Anweisung TABLE, oder aktivieren Sie zusätzliches Logging für die Spalte.

Beispiel

Die COLS <clause> in diesem Beispiel erfasst nur <columns> 1 und 3, während die COLSEXCEPT <clause> alle <columns> außer <columns> 1 und 3 erfasst.

TABLE hq.acct, COLS (col1, col3);
TABLE hq.sales, COLSEXCEPT (col1, col3);

COMPARECOLS (<column_specification>)

COMPARECOLS ist gültig für MAP.

Verwenden Sie COMPARECOLS, um die Spalten anzugeben, mit denen Replicat Aktualisierungs- oder Löschkonflikte erkennt und auflöst, wenn sie mit der Option RESOLVECONFLICT von MAP in einer Multimasterkonfiguration konfiguriert sind. Ein Konflikt ist eine Unstimmigkeit zwischen dem Before Image eines Datensatzes im Trail und den entsprechenden Daten in der Zieltabelle.

Um COMPARECOLS zu verwenden, muss das Before Image im Traildatensatz mit dem Parameter GETBEFORECOLS in der Extract TABLE-Anweisung verfügbar sein. Die angegebenen Spalten müssen in der Zieldatenbank vorhanden sein und auch Teil der Replicat-Konfiguration sein (erfüllen Sie die TARGET-Spezifikation mit oder ohne COLMAP-Klausel).

Nur skalare Datentypen werden von COMPARECOLS als Vergleichsspalten unterstützt. Ein skalarer Datentyp kann in einer WHERE-Klausel verwendet werden, hat einen einzelnen, atomaren Wert und keine internen Komponenten. Skalare Datentypen, die von Oracle GoldenGate unterstützt werden, umfassen die folgenden, jedoch keine LOBs.

Beispiele für nicht skalare Datentypen sind räumliche Daten, benutzerdefinierte Datentypen, große Objekte (LOB), XML, Referenzdatentypen und RAW. Eine Zeile, die für die CDR in Betracht gezogen wird, kann nicht skalare Daten enthalten, solange der Konflikt nicht in den nicht skalaren Daten selbst enthalten ist.

Um Konfliktlösungsroutinen anzugeben, verwenden Sie die Option RESOLVECONFLICT von MAP. COMPARECOLS und RESOLVECONFLICT können in einer beliebigen Reihenfolge in der MAP-Anweisung verwendet werden.

Weitere Informationen zum Konfigurieren der CDR-Funktion erhalten

Weitere Informationen zur Konfiguration von Konflikterkennung und -lösung finden Sie unter Automatische Konflikterkennung und -lösung oder Manuelle Konflikterkennung und -lösung.

Syntax

COMPARECOLS(
{ON UPDATE | ON DELETE}
{ALL | KEY | KEYINCLUDING (<col>[,...]) | ALLEXCLUDING (<col>[,...]) }
[,...]
)
{ON UPDATE ON DELETE}

Gibt an, ob das Before Image der angegebenen Spalten für Aktualisierungen oder Löschvorgänge verglichen werden soll. Sie können nur ON UPDATE, nur ON DELETE oder beides verwenden. Wenn Sie beide verwenden, geben Sie sie in derselben COMPARECOLS-Klausel an. Im Beispiel wird beschrieben, wie Sie beide verwenden.

{ALL | KEY | KEYINCLUDING (<col>[,...]) | ALLEXCLUDING (<col>[,...])}

Gibt die Spalten an, für die ein Before Image erfasst wird.

ALL

Vergleiche mit allen Spalten in der Zieltabelle. Ein Fehler wird generiert, wenn entsprechende Vorbilder im Trail nicht verfügbar sind. Wenn Sie ALL verwenden, wird die höchste Verarbeitungslast für Replicat vorgegeben, es können jedoch Vergleiche zur Konflikterkennung mit allen Spalten durchgeführt werden, um eine maximale Genauigkeit zu erreichen.

KEY

Vergleicht nur die Primärschlüsselspalten. Dies ist die schnellste Option, erlaubt jedoch nicht die genaueste Konflikterkennung, da die Schlüssel übereinstimmen können, aber Nicht-Schlüsselspalten unterschiedlich sein können.

KEYINCLUDING

Vergleicht die Primärschlüsselspalten und die angegebenen Spalten. Dies ist ein vernünftiger Kompromiss zwischen Geschwindigkeit und Detektionsgenauigkeit.

ALLEXCLUDING

Vergleicht alle Spalten mit Ausnahme der angegebenen Spalten. Bei Tabellen mit zahlreichen Spalten ist ALLEXCLUDING möglicherweise effizienter als KEYINCLUDING. Schließen Sie Schlüsselspalten nicht aus.

Beispiel 1

Im folgenden Beispiel werden die Schlüsselspalten plus die Spalten name, address und salary auf Konflikte verglichen.

MAP src, TARGET tgt
COMPARECOLS (
ON UPDATE KEYINCLUDING (name, address, salary),
ON DELETE KEYINCLUDING (name, address, salary));

Beispiel 2

Im folgenden Beispiel wird die Spalte comment ignoriert, und alle anderen Spalten werden bei Konflikten verglichen.

MAP src, TARGET tgt
COMPARECOLS (ON UPDATE ALLEXCLUDING (comment))

KOORDINIERT

COORDINATED ist gültig für MAP. Diese Option ist gültig, wenn sich Replicat im koordinierten Modus befindet.

Verwenden Sie die Option COORDINATED, um zu erzwingen, dass Transaktionen, die an Objekten in derselben MAP-Anweisung vorgenommen wurden, als Sperrtransaktionen verarbeitet werden. Dadurch werden alle Threads über alle MAP-Anweisungen hinweg mit demselben Trailspeicherort synchronisiert. Die synchronisierte Position ist der Beginn der Transaktion, die einen Datensatz enthält, der eine MAP mit dem Schlüsselwort COORDINATED erfüllt. Die Transaktion wird dann atomar von einem einzelnen Thread angewendet. Dies ist entweder der Thread mit dem niedrigsten Thread ID unter den aktuell ausgeführten Threads oder ein dedizierter Thread mit ID von 0, wenn USEDEDICATEDCOORDINATIONTHREAD in der Parameterdatei angegeben ist.

Die in Verbindung mit COORDINATED angegebenen Klauseln THREAD und THREADRANGE werden ignoriert, weil der Datensatz nicht von den angegebenen Threads angewendet wird. Das Schlüsselwort COORDINATED führt dazu, dass die Parallelisierung vorübergehend unterbrochen wird, sodass sich die Zieltabellen in einem konsistenten Status befinden, bevor die zwangsweise koordinierte Transaktion angewendet wird. Nach diesem Zeitpunkt beginnt die parallele Ausführung erneut.

Replicat koordiniert standardmäßig Transaktionen, in denen der Primärschlüssel aktualisiert wird, Transaktionen, die DDL ausführen, und bestimmte EVENTACTIONS-Aktionen. COORDINATED sieht eine explizite Koordinierung vor.

Weitere Informationen finden Sie unter Info zu koordiniertem Replicat.

Syntax

COORDINATED

Beispiel

Im Folgenden finden Sie ein Beispiel für die Verwendung der Option COORDINATED. In diesem Beispiel erfordern Geschäftsregeln, dass die Zieltabellen konsistent sind, bevor Replicat Transaktionen ausführt, die SQLEXEC-Vorgänge für die in der MAP-Anweisung angegebenen Objekte enthalten. Parallelität muss in diesem Fall vorübergehend in serielle SQL-Verarbeitung konvertiert werden.

Wenn bei der folgenden MAP-Anweisung ein anderer Thread einen Datensatz mit dem Wert 100 für col_val in t2 einfügt, bevor das Einfügen in t1 von Thread 1 ausgeführt wird, löscht SQLEXEC die Zeile. Wenn andere Threads den Datensatz mit dem Wert 100 noch verarbeiten, ist die SQLEXEC nicht erfolgreich. Die Ergebnisse dieser MAP-Anweisung sind daher nicht vorhersehbar.

MAP u1.t1, TARGET u2.t1 SQLEXEC (ID test2, QUERY ' delete from u2.t2 where col_val =100 ', NOPARAMS)), THREAD(1);

Wenn COORDINATED verwendet wird, werden alle Threads an einem gemeinsamen Punkt synchronisiert, einschließlich desjenigen, der den col_val=100-Datensatz verarbeitet, wodurch die Mehrdeutigkeit der Ergebnisse entfernt wird.

MAP u1.t1, TARGET u2.t1 SQLEXEC (ID test2, QUERY ' delete from u2.t2 where col_val =100 ', NOPARAMS)), THREAD(1), COORDINATED;

{DEF| TARGETDEF}<template>

DEF und TARGETDEF sind für TABLE und MAP gültig.

Geben Sie mit DEF und TARGETDEF den Namen einer Definitionsvorlage an, die vom Utility DEFGEN erstellt wurde.

Eine Vorlage basiert auf den Definitionen einer bestimmten Tabelle. Damit können neue Tabellen mit denselben Definitionen wie die ursprüngliche Tabelle der Oracle GoldenGate-Konfiguration hinzugefügt werden, ohne DEFGEN für sie auszuführen, und ohne den Oracle GoldenGate-Prozess stoppen und starten zu müssen. Die Definitionen in der Vorlage werden für Definitions-Lookups verwendet.

Syntax

{DEF | TARGETDEF} <template>

<template>

Der Name einer der folgenden Definitionsvorlagen, die vom Utility DEFGEN generiert werden:

Die Definitionen in der Vorlage müssen mit den Definitionen der Tabelle oder Tabellen identisch sein, die in derselben TABLE- oder MAP-Anweisung angegeben sind.

Die Groß-/Kleinschreibung des Vorlagennamens wird beachtet, wenn der Name genauso angegeben wird wie er in der Datenbank gespeichert ist. Stellen Sie sicher, dass der Vorlagenname in der DEF- oder TARGETDEF-Klausel in dieser TABLE- oder MAP-Anweisung und in der Parameterdatei DEFGEN, die das Template erstellt hat, auf dieselbe Weise angegeben wird.

Beispiel 1

In diesem Beispiel wird ein Vorlagenname ohne Beachtung der Groß-/Kleinschreibung gezeigt.

MAP acct.cust*, TARGET acct.cust*, DEF custdef;

Beispiel 2

Dieses Beispiel zeigt einen Vorlagennamen, bei dem die Groß-/Kleinschreibung beachtet werden muss, wenn die Datenbank Anführungszeichen benötigt, um die Groß-/Kleinschreibung zu erzwingen.

  TABLE acct.cust*, DEF "CustDef";

Beispiel 3

Dieses Beispiel zeigt einen Fall, in dem sowohl DEF als auch TARGETDEF verwendet werden.

  MAP acct.cust*, TARGET acc.cust*, DEF custdef, TARGETDEF tcustdef;

NUR AUSNAHMEN

EXCEPTIONSONLY ist gültig für MAP.

Verwenden Sie EXCEPTIONSONLY in einer MAP-Anweisung für Exceptions, die zur Fehlerbehandlung bestimmt ist. Die Exceptions-Anweisung MAP muss der MAP-Anweisung folgen, für die Fehler erwartet werden. Die Exception-Anweisung MAP wird nur ausgeführt, wenn ein Fehler für den letzten Datensatz auftritt, der in der vorherigen regulären MAP-Anweisung verarbeitet wurde.

Um EXCEPTIONSONLY zu verwenden, verwenden Sie eine REPERROR-Anweisung mit der Option EXCEPTION entweder in der regulären MAP-Anweisung oder im Root-Verzeichnis der Parameterdatei. Weitere Informationen dazu finden Sie in REPERROR. Hinweis: Wenn Sie das Oracle GoldenGate Conflict Detection and Resolution-(CDR-)Feature verwenden, ist kein REPERROR mit EXCEPTION erforderlich. CDR sendet automatisch alle Vorgänge, die Fehler verursachen, an die Exceptions-Anweisung MAP.

Die Exceptions-Anweisung MAP muss dieselbe Quelltabelle wie in der regulären MAP-Anweisung angeben. Die Zieltabelle in der Exceptions-Anweisung MAP muss jedoch eine Exception-Tabelle sein.

Hinweis: Unter "MAPEXCEPTION (exceptions_mapping)" wird beschrieben, wie Platzhalterobjektnamen unterstützt werden.

Syntax

EXCEPTIONSONLY

EVENTACTIONS (<action>)

EVENTACTIONS ist gültig für TABLE und MAP. Einige Optionen gelten nur für den einen oder anderen Parameter und werden als solche in den Beschreibungen angegeben.

Mit EVENTACTIONS kann der Prozess eine definierte Aktion basierend auf einem Datensatz im Trail ausführen, der als Ereignisdatensatz bezeichnet wird und für eine bestimmte Filterregel qualifiziert ist. Mit diesem System, das als Ereignismarker-System (oder Ereignismarker-Infrastruktur) bezeichnet wird, können Sie die Verarbeitung basierend auf Datenbankereignissen anpassen. Beispiel: Sie können einen Prozess unterbrechen, um eine Transformations- oder Berichtsstatistik auszuführen. Das Ereignismarkerfeature wird für die Replikation von Datenänderungen unterstützt, jedoch nicht für anfängliche Ladevorgänge.

Um Aktionen auszulösen, bei denen keine Daten auf Zieltabellen angewendet werden müssen, können Sie den Replicat-Parameter TABLE mit Filteroptionen verwenden, die EVENTACTIONS unterstützen. Weitere Informationen finden Sie unter "TABLE for Replicat".

Möglicherweise müssen Sie zwei oder mehr Aktionen kombinieren, um Ihre Ziele zu erreichen. Wenn mehrere Aktionen kombiniert werden, wird die gesamte EVENTACTIONS-Anweisung zuerst geparst, und dann werden die angegebenen Optionen in der Prioritätsreihenfolge ausgeführt. Die folgende Liste zeigt die Rangfolge. Die Aktionen, die vor Process the record aufgeführt werden, werden ausgeführt, bevor der Datensatz in den Trail geschrieben oder auf das Ziel angewendet wird (je nach Prozess). Nach Process the record aufgeführte Aktionen werden ausgeführt, nachdem der Datensatz verarbeitet wurde.

Um zu verhindern, dass der Ereignisdatensatz selbst normal verarbeitet wird, verwenden Sie die Option IGNORE oder DISCARD. Da IGNORE und DISCARD vor dem Datensatz selbst ausgewertet werden, verhindern sie, dass der Datensatz verarbeitet wird. Ohne diese Optionen schreibt EVENTACTIONS für Extract den Datensatz in den Trail, und EVENTACTIONS für Replicat wendet diesen Vorgang auf die Zieldatenbank an.

Sie sollten die Möglichkeit berücksichtigen, dass eine Transaktion zwei oder mehr Datensätze enthalten kann, die eine Ereignisaktion auslösen. In diesem Fall kann es mehrere Ausführungen bestimmter EVENTACTIONS-Spezifikationen geben. Beispiel: Wenn zwei qualifizierende Datensätze auftreten, die zwei aufeinanderfolgende ROLLOVER-Aktionen auslösen, führt Extract zweimal zum Rollover des Trails, sodass eine der beiden Dateien keine Transaktionsdaten enthält.

Beachten Sie auch, dass bei Inkrafttreten des Parameters GETUPDATEBEFORES zwei Datensätze für UPDATE-Vorgänge generiert werden: ein Datensatz mit dem Before Image und ein Datensatz mit dem After Image. Eine Ereignisaktion wird für jeden dieser Datensätze ausgelöst, wenn der Vorgang als Ereignisdatensatz qualifiziert ist. Sie können das Token BEFOREAFTERINDICATOR der Spaltenkonvertierungsfunktion GGHEADER als Filter in einer FILTER-Klausel verwenden, um die Datensätze so zu qualifizieren, dass die Ereignisaktion nur einmal ausgelöst wird, entweder im "Bevor"- oder im "Nach"-Datensatz, nicht jedoch beides.

Das folgende Beispiel filtert den Indikator BEFORE. Der EVENTACTION gibt den ECHO-Shellbefehl aus, um die Zeichenfolge "Triggered on BEFORE" in das Ereignislog auszugeben, wenn ein BEFORE-Datensatz gefunden wird.

TABLE qasource.test, &
FILTER(@STRFIND('BEFORE', @GETENV('GGHEADER' , 'BEFOREAFTERINDICATOR')) > 0), &
EVENTACTIONS ( shell ('echo --== Triggered on BEFORE ==-- '), LOG);

Im Folgenden wird das Ergebnis des Ereignisses <action> angezeigt:

013-03-06 17:59:31  INFO    OGG-05301  Shell command output: '--== Triggered
on AFTER ==--'

Das folgende Beispiel führt dasselbe aus, jedoch für den Indikator AFTER.

 TABLE qasource.test, &
 FILTER(@STRFIND('AFTER', @GETENV('GGHEADER' , 'BEFOREAFTERINDICATOR')) > 0), &
 EVENTACTIONS ( shell ('echo --== Triggered on AFTER ==-- '), LOG);

Syntax

EVENTACTIONS (
[STOP | SUSPEND | ABORT | FORCESTOP]
[IGNORE [RECORD | TRANSACTION [INCLUDEVENT]]
[DISCARD]
[LOG [INFO | WARNING]]
[REPORT]
[ROLLOVER]
[SHELL '<command>' | SHELL ('<command>', VAR <variable> = {<column_name> | <expression>}
  [, ...]) ]
[TRACE[2] <file> [TRANSACTION] [DDL[INCLUDE] | DDLONLY] [PURGE | APPEND]]
[CHECKPOINT [BEFORE | AFTER | BOTH]]
[, ...]
)

STOP

Gültig in TABLE für Extract und in MAP für Replicat.

Bringt den Prozess zu einem ordnungsgemäßen Stopp, wenn der angegebene Ereignisdatensatz ermittelt wird. Der Prozess wartet, bis andere Vorgänge innerhalb der Ereignistransaktion abgeschlossen sind, bevor er gestoppt wird. Wenn es sich bei der Transaktion um eine gruppierte oder im Batch gespeicherte Replicat-Transaktion handelt, wird die aktuelle Transaktionsgruppe angewendet, bevor der Prozess ordnungsgemäß gestoppt wird. Der Prozess wird beim nächsten Datensatz nach dem Ereignisdatensatz neu gestartet, solange dieser Datensatz auch das Ende einer Transaktion angibt.

Der Prozess protokolliert eine Meldung, wenn er nicht sofort gestoppt werden kann, weil eine Transaktion noch geöffnet ist. Wenn der Ereignisdatensatz jedoch in einer offenen Transaktion mit langer Ausführungszeit auftritt, gibt es keine Warnmeldung, die Sie auf den nicht festgeschriebenen Status der Transaktion hinweist. Daher kann der Prozess trotz des Ereignisses STOP möglicherweise lange ausgeführt werden.

STOP kann mit anderen EVENTACTIONS-Optionen kombiniert werden, außer ABORT und FORCESTOP.

SUSPEND

Gültig in TABLE für Extract und in MAP für Replicat.

Unterbricht den Prozess, sodass der aktive Kontext der aktuellen Ausführung beibehalten wird und weiterhin auf SEND-Befehle reagieren kann, die im Admin-Client abgesetzt werden. Wenn ein Prozess unterbrochen wird, wird er mit dem Befehl INFO als RUNNING angezeigt, und im Feld RBA wird die letzte Checkpointposition angezeigt.

Um die Verarbeitung fortzusetzen, geben Sie den Befehl SEND mit der Option RESUME aus.

Um die Option CHECKPOINT BEFORE in Verbindung mit SUSPEND zu verwenden, muss der Ereignisdatensatz der Start einer Transaktion sein, damit SUSPEND stattfinden kann. Wenn der Prozess auf diese Weise beendet wird, während er sich im unterbrochenen Status befindet, ist der Ereignisdatensatz mit der Aktion SUSPEND der erste Datensatz, der beim Neustart erneut verarbeitet wird. Wenn sowohl CHECKPOINT BERORE als auch SUSPEND angegeben sind, der Ereignisdatensatz jedoch nicht der Start einer Transaktion ist, wird der Prozess abgebrochen, bevor SUSPEND stattfinden kann.

Um die Option CHECKPOINT AFTER in Verbindung mit SUSPEND zu verwenden, muss der Befehl RESUME ausgegeben werden, bevor der Checkpoint stattfinden kann. Der Ereignisdatensatz muss ein COMMIT-Datensatz sein. Wenn der Prozess beendet wird, während er sich im Status SUSPEND befindet, verarbeitet der Prozess die Transaktion nach dem Neustart von der letzten Checkpoint-Position erneut.

SUSPEND kann nicht mit ABORT kombiniert werden, sondern kann mit allen anderen Optionen kombiniert werden.

ABORT

Gültig in TABLE für Extract und in MAP für Replicat.

Erzwingt, dass der Prozess sofort beendet wird, wenn der angegebene Ereignisdatensatz ermittelt wird, unabhängig davon, ob offene Transaktionen vorhanden sind. Der Ereignisdatensatz wird nicht verarbeitet. Ein schwerwiegender Fehler wird in das Log geschrieben, und der Ereignisdatensatz wird in die Discard-Datei geschrieben, wenn auch DISCARD angegeben wird. Der Prozess wird beim Start wiederhergestellt.

ABORT kann nur mit CHECKPOINT BEFORE, DISCARD, SHELL und REPORT kombiniert werden.

FORCESTOP

Gültig in TABLE für Extract und in MAP für Replicat.

Erzwingt, dass der Prozess ordnungsgemäß gestoppt wird, wenn der angegebene Ereignisdatensatz erkannt wird, jedoch nur, wenn der Ereignisdatensatz der letzte Vorgang in der Transaktion oder der einzige Datensatz in der Transaktion ist. Der Datensatz wird normal geschrieben.

Wenn der Ereignisdatensatz innerhalb einer offenen Transaktion mit langer Ausführungszeit ermittelt wird, schreibt der Prozess eine Warnmeldung in das Log und beendet den Vorgang sofort, wie in ABORT. In diesem Fall kann ein Recovery beim Start erforderlich sein. Wenn die Aktion FORCESTOP in der Mitte einer Transaktion mit langer Ausführungszeit ausgelöst wird, wird der Prozess ohne Warnmeldung beendet.

FORCESTOP kann mit anderen EVENTACTIONS-Optionen kombiniert werden, mit Ausnahme von ABORT, STOP, CHECKPOINT AFTER und CHECKPOINT BOTH. Bei Verwendung mit ROLLOVER erfolgt der Rollover nur, wenn der Prozess ordnungsgemäß gestoppt wird.

IGNORE [RECORD TRANSACTION [INCLUDEVENT]]

Gültig in TABLE für Extract und in MAP für Replicat.

Ignoriert je nach ausgewählter Aktion einige oder alle Transaktionen.

IGNORE kann mit allen anderen EVENTACTIONS-Optionen außer ABORT und DISCARD kombiniert werden.

Eine IGNORE-Aktion wird verarbeitet, nachdem alle Qualifizierungs-, Filter-, Zuordnungs- und User-Exit-Vorgänge verarbeitet wurden. Der Datensatz oder die Transaktion wird in der letzten Ausgabephase ignoriert und verhindert, dass der Datensatz oder die Transaktion in das Ausgabeziel geschrieben wird (der Trail im Falle von Extract oder die Datenbank im Falle von Replicat). Daher wird in bestimmten Ausdrücken, z.B. solchen, die SQLEXEC-Vorgänge enthalten, die SQLEXEC ausgeführt, bevor die IGNORE verarbeitet wird. Dies bedeutet, dass, während der Datensatz nicht in den Trail oder die Zieldatenbank geschrieben wird, alle Auswirkungen der Verarbeitung des Datensatzes durch Qualifizierung, Filterung, Zuordnung und User-Exit auftreten.

Diese Aktion ist für DDL-Datensätze nicht gültig. Da DDL-Vorgänge autonom sind, entspricht das Ignorieren eines Datensatzes dem Ignorieren der gesamten Transaktion.

DISCARD

Gültig in TABLE für Extract und in MAP für Replicat.

Führt dazu, dass der Prozess:

Der Prozess nimmt die Verarbeitung mit dem nächsten Record im Trail wieder auf.

DISCARD kann mit allen anderen EVENTACTIONS-Optionen außer IGNORE kombiniert werden.

LOG [INFO WARNING]

Gültig in TABLE für Extract und in MAP für Replicat.

Führt dazu, dass der Prozess das Ereignis protokolliert, wenn der angegebene Ereignisdatensatz ermittelt wird. Die Meldung wird in die Berichtsdatei, in das Oracle GoldenGate-Fehlerlog und in das Systemereignislog geschrieben.

Verwenden Sie die folgenden Optionen, um den Schweregrad der Meldung anzugeben:

LOG kann mit allen anderen EVENTACTIONS-Optionen außer ABORT kombiniert werden. Wenn Sie ABORT verwenden, ist LOG nicht erforderlich, da ABORT einen schwerwiegenden Fehler protokolliert, bevor der Prozess beendet wird.

REPORT

Gültig in TABLE für Extract und in MAP für Replicat.

Führt dazu, dass der Prozess eine Berichtsdatei generiert, wenn der angegebene Ereignisdatensatz gefunden wird. Dies entspricht der Verwendung des Befehls SEND mit der Option REPORT in GGSCI.

Die Meldung REPORT wird angezeigt, nachdem der Ereignisdatensatz verarbeitet wurde (es sei denn, DISCARD, IGNORE oder ABORT werden verwendet), sodass die Berichtsdaten den Ereignisdatensatz enthalten.

REPORT kann mit allen anderen EVENTACTIONS-Optionen kombiniert werden.

ROLLOVER

Gültig in TABLE für Extract.

Führt dazu, dass Extract den Trail in eine neue Datei überträgt, wenn der angegebene Ereignisdatensatz gefunden wird. Die Aktion ROLLOVER wird ausgeführt, bevor Extract den Ereignisdatensatz in die Traildatei schreibt. Dadurch wird der erste Datensatz in der neuen Datei erstellt, es sei denn, DISCARD, IGNORE oder ABORT werden ebenfalls verwendet.

ROLLOVER kann mit allen anderen EVENTACTIONS-Optionen außer ABORT kombiniert werden. ROLLOVER kann nicht mit ABORT kombiniert werden, da ROLLOVER nicht dazu führt, dass der Prozess einen Checkpoint schreibt, und ROLLOVER vor ABORT.

Ohne einen ROLLOVER-Checkpoint führt ABORT dazu, dass Extract beim Neustart zum vorherigen Checkpoint wechselt, der in der vorherigen Traildatei enthalten wäre. Dadurch wird der Rollover abgebrochen.

SHELL '<command>'

Gültig in TABLE für Extract und in MAP für Replicat.

Veranlasst, dass der Prozess den angegebenen Shellbefehl ausführt, wenn der Ereignisdatensatz ermittelt wird. SHELL '<command'> führt einen einfachen Shell-Befehl aus. Die Befehlszeichenfolge wird mit ihrem Literalwert aufgenommen und auf diese Weise an das System gesendet. Beim Befehl wird die Groß-/Kleinschreibung beachtet. Schließen Sie die Befehlszeichenfolge in einfache Anführungszeichen ein. Beispiel:

 EVENTACTIONS (SHELL 'echo hello world! > output.txt')

Wenn der Shell-Befehl erfolgreich ist, schreibt der Prozess eine Informationsmeldung in die Berichtsdatei und in das Ereignisprotokoll. Der Erfolg basiert auf dem Beendigungsstatus des Befehls in Übereinstimmung mit der UNIX-Shell-Sprache. In dieser Sprache bedeutet Null Erfolg.

Ist der Systemaufruf nicht erfolgreich, wird der Prozess mit einem schwerwiegenden Fehler abgebrochen. In der UNIX-Shell-Sprache ist ein Fehler ungleich null. Beachten Sie, dass sich die Fehlermeldung nur auf die Ausführung des Befehls SHELL selbst und nicht auf den Beendigungsstatus von untergeordneten Befehlen bezieht. Beispiel: SHELL kann ein Skript erfolgreich ausführen, aber Befehle in diesem Skript können fehlschlagen.

SHELL kann mit allen anderen EVENTACTIONS-Optionen kombiniert werden.

SHELL ('<command>', VAR <variable> = {<column_name> | <expression>} [, ...])

Gültig in TABLE für Extract und in MAP für Replicat.

Führt den Prozess zum Ausführen des angegebenen Shellbefehls aus, wenn der Ereignisdatensatz ermittelt wird, und unterstützt die Übergabe von Parametern. Der Befehl und die Parameter müssen die Groß-/Kleinschreibung beachten.

Wenn SHELL mit Argumenten verwendet wird, müssen die gesamten <command>- und Argumentzeichenfolgen in Klammern eingeschlossen sein. Beispiel:

 EVENTACTIONS (SHELL
 ('Current timestamp: $1  SQLEXEC result is $2 ',VAR $1 = @GETENV('JULIANTIMESTAMP'),
 VAR $2 = mytest.description));

Die Eingabe lautet wie folgt:

<command>

Ist der Befehl, der wörtlich an das System übergeben wird.

VAR

Ist ein erforderliches Schlüsselwort, das die Parametereingabe startet.

<variable>

Der benutzerdefinierte Name der Platzhaltervariable, in der der Wert der Laufzeitvariablen ersetzt wird. Zusätzliche Variablen, die nicht im Befehl verwendet werden, werden ignoriert. Beachten Sie, dass jedes Literal im Befehl SHELL, das mit einem Variablennamen VAR übereinstimmt, durch den ersetzten Wert VAR ersetzt wird. Dies kann unbeabsichtigte Folgen haben, also testen Sie Ihren Code, bevor Sie ihn in die Produktion bringen.

<column_name>

Kann das Vorher- oder Nachher-Bild eines Spaltenwertes sein.

<expression>

kann Folgendes sein, je nachdem, ob Spaltendaten oder DDL verarbeitet werden.

<TRACE[2]file> [TRANSACTION] [DDL[INCLUDE] | DDLONLY] [PURGE | APPEND]

Gültig in TABLE für Extract und in MAP für Replicat.

Führt dazu, dass Prozess-Traceinformationen in eine Trace-Datei geschrieben werden, wenn der angegebene Ereignisdatensatz gefunden wird. TRACE stellt Schritt-für-Schritt-Verarbeitungsinformationen bereit. TRACE2 gibt die Codesegmente an, in denen der Prozess die meiste Zeit verbringt.

Standardmäßig (ohne Optionen) wird das standardmäßige DML-Tracing ohne Richtlinien für Transaktionsgrenzen aktiviert, bis der Prozess beendet wird.

TRACE kann mit allen anderen EVENTACTIONS-Optionen außer ABORT kombiniert werden.

Um das Tracing für die angegebene Tracedatei zu deaktivieren, setzen Sie den Prozessbefehl GGSCI SEND mit der Option TRACE OFF <file_name> ab.

CHECKPOINT [BEFORE AFTER BOTH]

Gültig in TABLE für Extract und in MAP für Replicat.

Führt dazu, dass der Prozess einen Checkpoint schreibt, wenn der angegebene Ereignisdatensatz ermittelt wird. Checkpoint-Aktionen stellen einen Kontext zur Verarbeitung bereit, der in TABLE- oder MAP-Anweisungen definiert ist. Dieser Kontext hat einen Start- und einen Endpunkt. Dadurch werden Synchronisierungspunkte für die Zuordnung der Funktionen bereitgestellt, die mit SQLEXEC und User Exits ausgeführt werden.

BEFORE

BEFORE für einen Extract-Prozess schreibt einen Checkpoint, bevor Extract den Ereignisdatensatz in den Trail schreibt. BEFORE für einen Replicat-Prozess schreibt einen Checkpoint, bevor Replicat den SQL-Vorgang anwendet, der im Datensatz enthalten ist, auf das Ziel.

BEFORE erfordert, dass der Ereignisdatensatz der erste Datensatz in einer Transaktion ist. Wenn es sich nicht um den ersten Record handelt, wird der Prozess abgebrochen. Verwenden Sie BEFORE, um sicherzustellen, dass alle Transaktionen vor demjenigen, der mit dem Ereignisdatensatz beginnt, festgeschrieben werden.

Wenn Sie EVENTACTIONS für einen DDL-Datensatz verwenden, beachten Sie, dass der DDL-Datensatz garantiert der Start einer Transaktion ist, da jeder DDL-Datensatz autonom ist. Daher ist die CHECKPOINT BEFORE-Ereignisaktion für einen DDL-Datensatz impliziert.

CHECKPOINT BEFORE kann mit allen EVENTACTIONS-Optionen kombiniert werden.

AFTER

AFTER für Extract schreibt einen Checkpoint, nachdem Extract den Ereignisdatensatz in den Trail schreibt. AFTER für Replicat schreibt einen Checkpoint, nachdem Replicat den SQL-Vorgang angewendet hat, der im Datensatz enthalten ist, auf das Ziel.

AFTER kennzeichnet die Checkpoint-Anforderung als Advisory. Das bedeutet, dass der Prozess nur bei der nächsten praktischen Gelegenheit einen Checkpoint ausgibt. Beispiel: Wenn der Ereignisdatensatz eine Transaktion mit mehreren Datensätzen ist, findet der Checkpoint gemäß dem Datenintegritätsmodell von Oracle GoldenGate an der nächsten Transaktionsgrenze statt.

Wenn Sie EVENTACTIONS für einen DDL-Datensatz verwenden, beachten Sie, dass der DDL-Datensatz, da jeder DDL-Datensatz autonom ist, garantiert das Ende (Grenzwert) einer Transaktion ist. Daher ist die CHECKPOINT AFTER-Ereignisaktion für einen DDL-Datensatz impliziert.

CHECKPOINT AFTER kann mit allen EVENTACTIONS-Optionen außer ABORT. kombiniert werden

BOTH

BOTH kombiniert BEFORE und AFTER. Der Extract- oder Replicat-Prozess schreibt einen Checkpoint vor und nach der Verarbeitung des Ereignisdatensatzes.

CHECKPOINT BOTH kann mit allen EVENTACTIONS-Optionen außer ABORT. kombiniert werden

CHECKPOINT kann auf CP gekürzt werden.

Beispiel 1

Das folgende Beispiel zeigt, wie Sie einen Prozess so konfigurieren können, dass bestimmte Datensätze ignoriert werden. Wenn Extract einen Traildatensatz verarbeitet, der name = abc enthält, wird der Datensatz ignoriert.

TABLE fin.cust, &
WHERE (name = 'abc'), &
EVENTACTIONS (ignore);

Beispiel 2

Basierend auf den Kompatibilitäts- und Prioritätsregeln von EVENTACTIONS-Optionen hat DISCARD eine höhere Priorität als ABORT. In diesem Beispiel wird der Ereignisdatensatz in die Discard-Datei geschrieben, bevor der Prozess abgebrochen wird.

MAP fin.cust, TARGET fin.cust2, &
WHERE (name = 'abc'), &
EVENTACTIONS (DISCARD, ABORT);

Beispiel 3

Im folgenden Beispiel wird eine SHELL-Aktion ausgeführt. Das Ergebnis einer SQLEXEC-Abfrage wird abgerufen und mit dem aktuellen Zeitstempel gekoppelt.

TABLE src.tab &
SQLEXEC (id mytest, query 'select description from lookup &
where pop = :mycol2', params (mycol2 = col2) ), &
EVENTACTIONS (SHELL ('Current timestamp: $1  SQLEXEC result is $2 ', &
VAR $1 = @GETENV('JULIANTIMESTAMP'), VAR $2 = mytest.description));

Die Shell <command>, die sich aus diesem Beispiel ergibt, könnte wie folgt aussehen:

'Current timestamp: 212156002704718000  SQLEXEC result is test passed'

Beispiel 4

Das folgende Beispiel zeigt, wie ungültige Ergebnisse auftreten können, wenn ein Platzhaltername mit einem Literaltext in der Befehlszeichenfolge in Konflikt steht. In diesem Beispiel wird ein Platzhalter namens $1 mit einem Spaltenwert verknüpft, und der Befehl SHELL gibt eine Literalzeichenfolge zurück, die $1 enthält.

MAP src.tab1, TARGET targ.tab1 &
EVENTACTIONS (SHELL ('echo Extra charge for $1 is $1', VAR $1 = COL1));

Dies ist das unbeabsichtigte Ergebnis, vorausgesetzt, der <column>-Wert ist gift wrap:

'Extra charge for gift wrap is gift wrap'

Wenn Sie den Platzhalter <variable> in $col ändern, wird die korrekte Ausgabe angezeigt:

MAP src.tab1, TARGET targ.tab1 &
EVENTACTIONS (SHELL ('echo Extra charge for $col is $1', VAR $col = COL1));
'Extra charge for gift wrap is $1'

Im Folgenden wird ein ähnliches Potenzial für unbeabsichtigte Ergebnisse gezeigt:

MAP src.tab1, TARGET targ.tab1 &
EVENTACTIONS (SHELL ('Timestamp: $1  Price is $13 > out.txt ', &
VAR $1 = @GETENV('JULIANTIMESTAMP')));

Die umgeleitete Ausgabe <file> kann eine <string> wie folgt enthalten (beachten Sie, dass der zweite Zeitstempel den angehängten Wert 3 enthält):

'Timestamp: 212156002704718000 Price is 2121560027047180003'

Das beabsichtigte Ergebnis ist:

'Timestamp: 212156002704718000 Price is $13'

Beispiel 5

In diesen Beispielen werden verschiedene Möglichkeiten zur Konfiguration von Tracing gezeigt.

MAP tab1, TARGET tab1 EVENTACTIONS (TRACE ./dirrpt/trace
1.txt);
MAP tab2, TARGET tab2 EVENTACTIONS (TRACE ./dirrpt/trace2.txt TRANSACTION);

Beispiel 6

Im Folgenden wird gezeigt, wie EVENTACTIONS mit SUSPEND verwendet werden kann.

EXITPARAM '<parameter>'

EXITPARAM ist gültig für TABLE und MAP.

Verwenden Sie EXITPARAM, um einen Parameter an die Funktion EXIT_PARAMS einer User Exit-Routine zu übergeben, wenn ein Datensatz aus der Anweisung TABLE oder MAP ermittelt wird.

Syntax

EXITPARAM '<parameter string>'

<'parameter string'>

Ein Parameter, der eine literale Zeichenfolge ist. Setzen Sie den Parameter in einfache Anführungszeichen. Sie können bis zu 100 Zeichen für die Parameterzeichenfolge angeben.

VORFILTER ABRUFEN

FETCHBEFOREFILTER ist gültig für TABLE.

Verwenden Sie FETCHBEFOREFILTER, um Spalten abzurufen, die mit FETCHCOLS oder FETCHCOLSEXCEPT angegeben wurden, bevor ein FILTER-Vorgang ausgeführt wird. Durch das Abrufen vor dem Filter wird sichergestellt, dass die für den Filter erforderlichen Werte verfügbar sind. Ohne FETCHBEFOREFILTER werden Abrufe, die mit FETCHCOLS oder FETCHCOLSEXCEPT angegeben sind, erst ausgeführt, nachdem Filter ausgeführt wurden. Geben Sie in der Parameterdatei FETCHBEFOREFILTER vor FILTER an.

Verwenden Sie diese Option nicht für Tabellen, die im Passthrough-Modus von einer Data Pump-Extraktgruppe verarbeitet werden.

Syntax

FETCHBEFOREFILTER

Beispiel

TABLE hr.salary, FETCHCOLS (<sal_level>),
FETCHBEFOREFILTER,
FILTER (sal_level >= 8)
;

{FETCHCOLS | FETCHCOLSEXCEPT} (<column_list>)

FETCHCOLS und FETCHCOLSEXCEPT sind für TABLE gültig. Diese Optionen sind nur für den primären Extract gültig.

Verwenden Sie FETCHCOLS und FETCHCOLSEXCEPT, um Spaltenwerte aus der Datenbank abzurufen, wenn die Werte nicht im Transaktionslogdatensatz vorhanden sind. Verwenden Sie diese Option, wenn die Datenbank nur die Werte von Spalten protokolliert, die in einem Aktualisierungsvorgang geändert wurden. Sie müssen jedoch sicherstellen, dass andere Spaltenwerte verfügbar sind, die für FILTER-Vorgänge erforderlich sind.

FETCHCOLS und FETCHCOLSEXCEPT sind für alle Datenbanken gültig, die von Oracle GoldenGate unterstützt werden.

Bei einer Oracle AI Database ruft Oracle GoldenGate die Werte aus dem Undo Tablespace über den Flashback Query-Mechanismus von Oracle ab. Die Abfrage liefert ein lesekonsistentes Bild der Spalten zu einem bestimmten Zeitpunkt oder zu einer bestimmten SCN. Weitere Informationen zur Verwendung von Flashback Query in Oracle GoldenGate.

Anstatt FETCHCOLS oder FETCHCOLSEXCEPT zu verwenden, kann es effizienter sein, zusätzliches Logging für die gewünschten Spalten zu aktivieren.

Um das Abrufen zu steuern und eine Antwort zu aktivieren, wenn eine zum Abrufen angegebene Spalte nicht gefunden werden kann, verwenden Sie den Parameter FETCHOPTIONS. Um Fetch-Ergebnisse in statistische Anzeigen einzuschließen, die vom Befehl STATS EXTRACT generiert werden, verwenden Sie den Parameter STATOPTIONS.

Wenn Werte für Spalten, die mit FETCHCOLS oder FETCHCOLSEXCEPT angegeben sind, im Transaktionslog vorhanden sind, wird kein Datenbankabruf ausgeführt. Dadurch wird der Datenbank-Overhead reduziert.

Syntax

{FETCHCOLS | FETCHCOLSEXCEPT} (<column> [, ...])

<column>

Einer der folgenden Namen kann verwendet werden:

Beispiel

Die FETCHCOLS-Klausel in diesem Beispiel ruft nur die Spalten 1 und 3 ab, während die FETCHCOLSEXCEPT-Klausel alle Spalten außer den Spalten 1 und 3 abruft.

TABLE hq.acct, FETCHCOLS (col1, col3);
TABLE hq.sales, FETCHCOLSEXCEPT (col1, col3);

{FETCHMODCOLS | FETCHMODCOLSEXCEPT} (<column_list>)

FETCHMODCOLS und FETCHMODCOLSEXCEPT sind für TABLE gültig. Diese Optionen sind nur für den primären Extract gültig.

Verwenden Sie FETCHMODCOLS und FETCHMODCOLSEXCEPT, um das Abrufen von Spaltenwerten aus der Datenbank zu erzwingen, selbst wenn die Spalten im Transaktionslog vorhanden sind. Je nach Datenbanktyp kann ein Logdatensatz alle Spalten einer Tabelle oder nur die Spalten enthalten, die im angegebenen Transaktionsvorgang geändert wurden.

FETCHMODCOLS und FETCHMODCOLSEXCEPT sind für alle Datenbanken gültig, die von Oracle GoldenGate unterstützt werden.

Beachten Sie die folgenden Verwendungsrichtlinien:

Syntax

{FETCHMODCOLS | FETCHMODCOLSEXCEPT} (<column> [, ...])

(<column> [, ...])

Einer der folgenden Namen kann verwendet werden:

Beispiel

Die FETCHMODCOLS-Klausel in diesem Beispiel ruft nur die Spalten 1 und 3 ab, während die FETCHMODCOLSEXCEPT-Klausel alle Spalten außer den Spalten 1 und 3 abruft.

TABLE hq.acct, FETCHMODCOLS (col1, col3);
TABLE hq.sales, FETCHMODCOLSEXCEPT (col1, col3);

FILTER (<filter_clause>)

FILTER ist gültig für TABLE und MAP.

Verwenden Sie FILTER, um Datensätze basierend auf einem numerischen Wert auszuwählen oder auszuschließen. Ein Filterausdruck kann Bedingungsoperatoren, Oracle GoldenGate-Spaltenkonvertierungsfunktionen oder beides verwenden. Hinweis: Um nach einer Zeichenfolge zu filtern, verwenden Sie eine der Oracle GoldenGate-Zeichenfolgenfunktionen. Weitere Informationen zu diesen Funktionen finden Sie unter "Funktionen der Tabellen- und Spaltenzuordnung". Sie können auch die Option WHERE verwenden. Siehe "WHERE (clause)".

Trennen Sie alle FILTER-Komponenten durch Kommas. Eine FILTER-Klausel kann Folgendes enthalten:

Setzen Sie Literale in einfache Anführungszeichen. Geben Sie Spaltennamen an, bei denen die Groß-/Kleinschreibung beachtet wird, während sie in der Datenbank gespeichert werden, und setzen Sie sie in doppelte Anführungszeichen, wenn die Datenbank Anführungszeichen benötigt, um die Groß-/Kleinschreibung zu erzwingen (z. B. Oracle).

Oracle GoldenGate unterstützt FILTER für Spalten mit einem Multibyte-Zeichensatz.

Syntax

FILTER (
[, ON INSERT | ON UPDATE| ON DELETE]
[, IGNORE INSERT | IGNORE UPDATE | IGNORE DELETE]
, <filter_clause>
[, RAISEERROR <error_number>]
)

<filter_clause>

Wählt Datensätze basierend auf einem <expression> aus. Beispiel:

FILTER ((PRODUCT_PRICE*PRODUCT_AMOUNT) > 10000))

Sie können die Spaltenkonvertierungsfunktionen von Oracle GoldenGate in einem Filter <clause> wie folgt verwenden:

FILTER (@COMPUTE (PRODUCT_PRICE*PRODUCT_AMOUNT)>10000)

Setzen Sie Literale in einfache Anführungszeichen. Geben Sie Spaltennamen an, bei denen die Groß-/Kleinschreibung beachtet wird, während sie in der Datenbank gespeichert werden, und setzen Sie sie in doppelte Anführungszeichen, wenn die Datenbank Anführungszeichen benötigt, um die Groß-/Kleinschreibung zu erzwingen (z. B. Oracle).

Oracle GoldenGate unterstützt FILTER nicht für Spalten mit einem Mehr-Byte-Zeichensatz oder einem Zeichensatz, der mit dem Zeichensatz des lokalen Betriebssystems nicht kompatibel ist.

Die maximale Größe der Filterklausel beträgt 5.000 Byte.

ON INSERT ON UPDATE ON DELETE

Beschränkt die Datensatzfilterung auf die angegebenen Vorgänge. Trennen Sie Vorgänge durch Kommas. Beispiel:

FILTER (ON UPDATE, ON DELETE,
@COMPUTE (PRODUCT_PRICE*PRODUCT_AMOUNT)>10000)

Im vorherigen Beispiel wird der Filter für die Vorgänge UPDATE und DELETE ausgeführt, nicht jedoch für die Vorgänge INSERT.

IGNORE INSERT IGNORE UPDATE IGNORE DELETE

Der Filter wird für die angegebenen Vorgänge nicht angewendet. Trennen Sie Vorgänge durch Kommas. Beispiel:

FILTER (IGNORE INSERT, @COMPUTE (PRODUCT_PRICE*PRODUCT_AMOUNT)>10000)

Im vorherigen Beispiel wird der Filter für die Vorgänge UPDATE und DELETE ausgeführt, INSERT-Vorgänge werden jedoch ignoriert.

RAISEERROR <error>

Löst eine benutzerdefinierte Fehlernummer aus, wenn der Filter nicht erfolgreich ist. Kann als Eingabe für den Parameter REPERROR verwendet werden, um die Fehlerbehandlung aufzurufen. Stellen Sie sicher, dass der Wert für <error> außerhalb des Bereichs der Fehlernummern liegt, die von der Datenbank oder von Oracle GoldenGate verwendet werden. Beispiel: RAISEERROR 21000.

GETBEFORECOLS (<column_specification>)

GETBEFORECOLS ist gültig für TABLE.

Mit GETBEFORECOLS können Sie Spalten angeben, für die das Image erfasst und bei einem Aktualisierungs- oder Löschvorgang in den Trail geschrieben werden soll. Verwenden Sie GETBEFORECOLS, wenn Sie das Oracle GoldenGate Conflict Detection and Resolution-(CDR-)Feature in einer bidirektionalen oder Multimasterkonfiguration verwenden. Verwenden Sie es auch, wenn Sie Konvertierungsfunktionen oder andere Verarbeitungsfunktionen verwenden, die das Vorbild eines Datensatzes erfordern.

Bei Aktualisierungen wird das Before Image der angegebenen Spalten in den Trail aufgenommen, unabhängig davon, ob eine bestimmte Spalte geändert wird oder nicht. Zusätzlich zu den in der GETBEFORECOLS-Klausel angegebenen Spalten protokolliert eine Oracle AI Database auch das Before Image anderer geänderter Spalten. Bei anderen unterstützten Datenbanken können Sie den Parameter GETUPDATEBEFORES verwenden, um die Aufnahme der Vorwerte anderer geänderter Spalten zu erzwingen.

Hinweis: GETUPDATEBEFORES setzt GETBEFORECOLS außer Kraft, wenn beide in derselben Parameterdatei verwendet werden.

Um diesen Parameter verwenden zu können, muss das zusätzliche Logging für alle Datenbanken aktiviert sein, die nicht standardmäßig vor Werten protokolliert werden.

GETBEFORECOLS setzt COMPRESSUPDATES und COMPRESSDELETES außer Kraft, wenn sie in derselben Parameterdatei verwendet werden.

Dieser Parameter ist für alle Datenbanken mit Ausnahme von Db2 z/OS gültig. Verwenden Sie für Db2 z/OS auf allen Plattformen, die von Oracle GoldenGate unterstützt werden, den Parameter GETUPDATEBEFORES anstelle von GETBEFORECOLS.

Syntax

GETBEFORECOLS(
{ON UPDATE | ON DELETE}
{ALL | KEY | KEYINCLUDING (<col>[,...])  | KEYANDMOD | | ALLEXCLUDING (<col>[,...]) }
[,...]
)
{ON UPDATE ON DELETE}

Gibt an, ob das Before Image der angegebenen Spalten für Aktualisierungen oder Löschvorgänge erfasst werden soll. Sie können nur ON UPDATE, nur ON DELETE oder beides verwenden. Wenn Sie beide verwenden, geben Sie sie in derselben GETBEFORECOLS-Klausel an. Im Beispiel wird beschrieben, wie Sie beide verwenden.

{ALL | KEY | KEYINCLUDING (<col>[,...]) | KEYANDMOD | ALLEXCLUDING (<col>[,...])}

Gibt die Spalten an, für die ein Before Image erfasst wird.

ALL

Erfasst ein Before Image aller unterstützten Datentypspalten in der Zieltabelle, einschließlich des Primärschlüssels. Alle nicht unterstützten Spalten werden übersprungen und in der Extract- oder Replicat-Parameterdatei als Informationsmeldung protokolliert. Dadurch wird die höchste Verarbeitungslast für Extract vorgegeben, es können aber Vergleiche zur Konflikterkennung mit allen Spalten durchgeführt werden, um maximale Genauigkeit zu gewährleisten.

KEY

Vorher-Bild nur für den Primärschlüssel erfassen. Dies ist die schnellste Option, erlaubt jedoch nicht die genaueste Konflikterkennung, da die Schlüssel übereinstimmen können, aber Nicht-Schlüsselspalten unterschiedlich sein können. KEY ist der Standardwert.

KEYINCLUDING

Erfassen Sie vor dem Abbild des Primärschlüssels und auch der angegebenen Spalte(n). Dies ist ein vernünftiger Kompromiss zwischen Geschwindigkeit und Detektionsgenauigkeit.

KEYANDMOD

Verwenden Sie diese Option als Erweiterung der Schlüsseloption für Extract und Replicat. Bei der Aktualisierung von DMLs in der Quelle protokolliert Extract den Schlüssel und die geänderten Spalten. Replicat auf dem Ziel verwendet die Spalten KEY und MODIFIED bei der Konflikterkennung in einer WHERE-Klausel. Bei Oracle AI-Datenbanken wird die geänderte Spalte standardmäßig immer zur Konflikterkennung verwendet, und dieser Parameter macht sie explizit.

ALLEXCLUDING

Erfassen Sie vor dem Image aller Spalten mit Ausnahme der angegebenen Spalten. Bei Tabellen mit zahlreichen Spalten ist ALLEXCLUDING möglicherweise effizienter als KEYINCLUDING. Schließen Sie Schlüsselspalten nicht aus.

Beispiel

Im folgenden Beispiel werden die Before-Images für die Schlüsselspalte(n) plus name, address und salary bei Aktualisierungs- und Löschvorgängen immer in die Traildatei geschrieben.

TABLE src,
GETBEFORECOLS (
ON UPDATE KEYINCLUDING (name, address,  salary),
ON DELETE KEYINCLUDING (name, address, salary));

HANDLECOLLISIONS | NOHANDLECOLLISIONS

HANDLECOLLISIONS und NOHANDLECOLLISIONS sind für MAP gültig.

Mit HANDLECOLLISIONS und NOHANDLECOLLISIONS können Sie steuern, ob Oracle GoldenGate die Ergebnisse eines anfänglichen Ladevorgangs mit replizierten Transaktionsänderungen abstimmt, die an denselben Tabellen vorgenommen werden. Wenn Oracle GoldenGate replizierte Änderungen anwendet, nachdem der Ladevorgang abgeschlossen ist, bewirkt HANDLECOLLISIONS, dass Replicat doppelte Datensätze in den Zieltabellen überschreibt und alternative Fehlerbehandlung für fehlende Datensätze bereitstellt.

HANDLECOLLISIONS und NOHANDLECOLLISIONS können global für alle MAP-Anweisungen in der Parameterdatei oder als ON/OFF-Switch für Tabellengruppen verwendet werden, die mit MAP-Anweisungen angegeben sind. Sie können in einer MAP-Anweisung verwendet werden. Wenn sie in einer MAP-Anweisung verwendet werden, setzen sie die globalen Spezifikationen außer Kraft.

Syntax und Syntax finden Sie unter "HANDLECOLLISIONS | NOHANDLECOLLISIONS".

ALLE DATENSÄTZE EINFÜGEN

INSERTALLRECORDS ist gültig für MAP.

Verwenden Sie den Parameter INSERTALLRECORDS, um alle zugeordneten Vorgänge in INSERT-Vorgänge im Ziel zu konvertieren. INSERTALLRECORDS kann auf Root-Ebene der Parameterdatei, in einer MAP-Anweisung und in einer MAPEXCEPTION-Klausel einer MAP-Anweisung verwendet werden.

Syntax und Syntax finden Sie unter "INSERTALLRECORDS".

EINFÜGENAPPEND | NOINSERTAPPEND

INSERTAPPEND ist gültig für MAP.

Verwenden Sie die Parameter INSERTAPPEND und NOINSERTAPPEND, um zu steuern, ob Replicat einen APPEND-Hint verwendet, wenn INSERT-Vorgänge auf Oracle-Zieltabellen angewendet werden. Diese Parameter sind nur für Oracle-Datenbanken gültig.

Syntax und Syntax finden Sie unter "INSERTAPPEND | NOINSERTAPPEND".

KEYCOLS (<columns>)

KEYCOLS ist gültig für TABLE und MAP.

Mit KEYCOLS können Sie eine oder mehrere Spalten der Zieltabelle als eindeutig definieren. Die primäre Verwendung von KEYCOLS besteht darin, einen Ersatz-Primärschlüssel zu definieren, wenn ein Primärschlüssel oder ein entsprechender eindeutiger Index für die Tabelle nicht verfügbar ist. Sie können auch KEYCOLS verwenden, um zusätzliche Spalten anzugeben, die in der Zeilen-ID verwendet werden sollen, die Replicat verwendet. Ohne die Verfügbarkeit eines Schlüssels oder einer KEYCOLS-Klausel verwendet Replicat alle Spalten der Tabelle, um die WHERE-Klausel zu erstellen. Dadurch wird im Wesentlichen ein Full Table Scan ausgeführt.

Die Spalten eines Schlüssels, der von KEYCOLS wiedergegeben wird, müssen eine Zeile eindeutig identifizieren, und sie müssen mit den Spalten übereinstimmen, die als Schlüssel in der Quelltabelle verwendet werden. Die Quelltabelle muss mindestens so viele Schlüssel- oder Indexspalten enthalten wie der für die Zieltabelle angegebene KEYCOLS-Schlüssel. Andernfalls hat Replicat im Falle einer Aktualisierung des Quellschlüssels oder der Indexspalten nicht die Before Images für die zusätzlichen Zielspalten KEYCOL.

Wenn Sie einen Ersatzschlüssel mit KEYCOLS definieren, beachten Sie die folgenden Richtlinien:

Stellen Sie bei Verwendung von KEYCOLS sicher, dass die angegebenen Spalten für das Logging konfiguriert sind, damit sie für Replicat in den Traildatensätzen verfügbar sind. Bei einer Oracle AI-Datenbank können Sie das Logging mit der Option COLS des Befehls ADD TRANDATA aktivieren.

Erstellen Sie in den Zieltabellen einen eindeutigen Index für die KEYCOLS-definierten Schlüsselspalten. Ein Index verbessert die Geschwindigkeit, mit der Oracle GoldenGate die Zielzeilen lokalisiert, die es verarbeiten muss.

Verwenden Sie KEYCOLS nicht für Tabellen, die im Passthrough-Modus von einer Data Pump-Extraktgruppe verarbeitet werden.

Zusätzliche Richtlinien für KEYCOLS bei Verwendung von parallelem Replicat oder integriertem Replicat:

Syntax

KEYCOLS (<column> [, ... ])

<column>

Definiert eine Spalte, die als Ersatz-Primärschlüssel verwendet werden soll. Wenn ein Primärschlüssel oder ein eindeutiger Schlüssel vorhanden ist, müssen diese Spalten in der Spezifikation KEYCOLS enthalten sein. Um mehrere Spalten anzugeben, erstellen Sie eine durch Komma getrennte Liste wie folgt:

KEYCOLS (id, name)

Die folgenden Spaltentypen werden in KEYCOLS nicht unterstützt:

Beispiel

KEYCOLS

MAPEXCEPTION (<exceptions_mapping>)

MAPEXCEPTIONS ist gültig für MAP.

Verwenden Sie MAPEXCEPTION als Teil einer MAP-Anweisung für Exceptions, die zur Fehlerbehandlung bestimmt ist. MAPEXCEPTION ordnet nicht erfolgreiche Vorgänge zu, die vom Parameter REPERROR als Ausnahmen gekennzeichnet sind, einer Ausnahmetabelle zu. Replicat schreibt die Werte dieser Vorgänge zusammen mit anderen Informationen in die Ausnahmetabelle.

Sie können MAPEXCEPTION in derselben MAP-Anweisung verwenden, die das Mapping von Quell-Zieltabellen und andere standardmäßige MAP-Optionen enthält. Die Quell- und Zieltabellennamen können Platzhalter enthalten.

Wenn Sie MAPEXCEPTION verwenden, verwenden Sie eine REPERROR-Anweisung mit der Option EXCEPTION entweder innerhalb derselben MAP-Anweisung oder im Root-Verzeichnis der Replicat-Parameterdatei. Siehe "EXCEPTIONSONLY" und "REPERROR".

Syntax

MAPEXCEPTION (TARGET <exceptions_table>, INSERTALLRECORDS [, <exception_MAP_options>])

TARGET <exceptions_table>

Der vollqualifizierte Name der Ausnahmetabelle. Oracle GoldenGate-Standardregeln für Objektnamen gelten für den Namen der Ausnahmetabelle.

<exception_MAP_options>

Alle gültigen Optionen des Parameters MAP, die Sie auf die Exception-Behandlung anwenden möchten.

INSERTALLRECORDS

Wendet alle Ausnahmen auf die Ausnahmetabelle als INSERT-Vorgänge an. Dieser Parameter ist erforderlich, wenn Sie MAPEXCEPTION verwenden.

Beispiel

Dies ist ein Beispiel dafür, wie Sie MAPEXCEPTION für die Ausnahmenzuordnung verwenden. Die Klauseln MAP und TARGET enthalten Platzhalter-Quell- und Zieltabellennamen. Ausnahmen, die bei der Verarbeitung einer Tabelle mit einem Namen auftreten, der mit TRX beginnt, werden mit der angegebenen Zuordnung in der Tabelle fin.trxexceptions erfasst.

MAP src.trx*, TARGET trg.*,
MAPEXCEPTION (TARGET fin.trxexceptions,
INSERTALLRECORDS,
COLMAP (USEDEFAULTS,
ACCT_NO = ACCT_NO,
OPTYPE = @GETENV ('LASTERR', 'OPTYPE'),
DBERR = @GETENV ('LASTERR', 'DBERRNUM'),
DBERRMSG = @GETENV ('LASTERR', 'DBERRMSG')
)
);

KARTENSÄULEN | NOMAPALLCOLUMNS

MAPALLCOLUMNS und NOMAPALLCOLUMNS sind für MAP gültig.

Verwenden Sie MAPALLCOLUMNS, um nicht zugeordnete Spalten abzurufen (kein Schlüssel). Wenn diese Option angegeben ist, prüft Extract oder Replicat, ob alle Quellspalten ohne die Spaltenzuordnungsfunktion direkt dem Ziel zugeordnet sind. Wenn keine Quellspalten zugeordnet sind, werden Extract und/oder Replicat abgebrochen.

Siehe "MAPALLCOLUMNS| NOMAPALLCOLUMNS".

MAPINVISIBLECOLUMNS | NOMAPINVISIBLECOLUMNS

MAPINVISIBLECOLUMNS und NOMAPINVISIBLECOLUMNS sind für MAP gültig.

Mit MAPINVISIBLECOLUMNS und NOMAPINVISIBLECOLUMNS steuern Sie, ob Replicat unsichtbare Spalten in Oracle-Zieltabellen für die Standardspaltenzuordnung enthält. Für unsichtbare Spalten in Oracle-Zieltabellen, die explizites Spaltenmapping verwenden, werden sie immer zugeordnet, sodass diese Option nicht erforderlich ist.

MAPINVISIBLECOLUMNS und NOMAPINVISIBLECOLUMNS können auf zwei verschiedene Arten verwendet werden. Wenn ein Parameter auf globaler Ebene angegeben wird, bleibt er für alle nachfolgenden MAP-Anweisungen gültig, bis der andere Parameter angegeben wird. Wenn sie in einer MAP-Anweisung verwendet werden, setzen sie die globalen Spezifikationen außer Kraft

Syntax und Syntax finden Sie unter "MAPINVISIBLECOLUMNS | NOMAPINVISIBLECOLUMNS".

REPERROR (<error>,<response>)

REPERROR ist gültig für MAP.

Geben Sie mit REPERROR einen Fehler und eine Antwort an, die gemeinsam steuern, wie Replicat auf den Fehler reagiert, wenn die MAP-Anweisung ausgeführt wird. Sie können REPERROR auf der Ebene MAP verwenden, um globale Fehlerbehandlungsregeln zu überschreiben und zu ergänzen, die mit dem Parameter REPERROR auf der Root-Ebene der Parameterdatei festgelegt wurden. Mehrere REPERROR-Anweisungen können auf dieselbe MAP-Anweisung angewendet werden, um eine automatische, umfassende Fehlerverwaltung und unterbrechungsfreie Replikationsverarbeitung zu ermöglichen.

Syntax und Beschreibungen finden Sie unter "REPERROR".

RESOLVECONFLICT (<conflict_resolution_specification>)

RESOLVECONFLICT ist gültig für MAP.

Verwenden Sie RESOLVECONFLICT in einer bidirektionalen oder Multi-Master-Konfiguration, um anzugeben, wie Replicat Konflikte bei Vorgängen behandelt, die an den Tabellen in der MAP-Anweisung vorgenommen wurden.

Mehrere Auflösungen können für denselben Konflikttyp angegeben werden und werden in der Reihenfolge ausgeführt, die in RESOLVECONFLICT aufgeführt ist. Mehrfachauflösungen sind nur auf Konflikte zwischen INSERTROWEXISTS und UPDATEROWEXISTS beschränkt.

RESOLVECONFLICT kann mehrmals in einer MAP-Anweisung verwendet werden, um verschiedene Lösungen für verschiedene Konflikttypen anzugeben.

Im Folgenden werden die Datentypen und Plattformen aufgeführt, die von RESOLVECONFLICT unterstützt werden.

Syntax

RESOLVECONFLICT (
{INSERTROWEXISTS | UPDATEROWEXISTS | UPDATEROWMISSING |
   DELETEROWEXISTS | DELETEROWMISSING}
( {DEFAULT | <resolution_name>},
  {USEMAX (<resolution_column>) | USEMAXEQ (<resolution_column>) | USEMIN (<resolution_column>) | USEMINEQ (<resolution_column>) | USEDELTA |
     DISCARD | OVERWRITE | IGNORE}
 )
[, COLS (<column>[,...])]
)
INSERTROWEXISTS UPDATEROWEXISTS UPDATEROWMISSING
DELETEROWEXISTS DELETEROWMISSING  

Der Konflikttyp, der von dieser Lösung behandelt wird.

INSERTROWEXISTS

Eine eingefügte Zeile verletzt ein Eindeutigkeits-Constraint für das Ziel.

UPDATEROWEXISTS

Auf dem Ziel ist eine aktualisierte Zeile vorhanden, aber mindestens eine Spalte enthält ein Before Image im Trail, das sich vom aktuellen Wert in der Datenbank unterscheidet.

UPDATEROWMISSING

Im Ziel ist keine aktualisierte Zeile vorhanden.

DELETEROWEXISTS

Im Ziel ist eine gelöschte Zeile vorhanden, aber mindestens eine Spalte enthält ein Before-Image im Trail, das sich vom aktuellen Wert in der Datenbank unterscheidet.

DELETEROWMISSING

Im Ziel ist keine gelöschte Zeile vorhanden.

DEFAULT | <resolution_name>

DEFAULT

Die Standardspaltengruppe. Die Auflösung, die mit der Spaltengruppe DEFAULT verknüpft ist, wird für alle Spalten verwendet, die sich nicht in einer explizit benannten Spaltengruppe befinden. Sie müssen eine Spaltengruppe DEFAULT definieren.

<resolution_name>

Ein Name für eine bestimmte Spaltengruppe, die mit einem bestimmten Auflösungstyp verknüpft ist. Geben Sie einen Namen an, der den Auflösungstyp identifiziert. Gültige Werte sind alphanumerische Zeichen. Vermeiden Sie Leerzeichen und Sonderzeichen, aber Unterstriche sind zulässig. Beispiel:

delta_res_method

Verwenden Sie entweder eine benannte Auflösung oder DEFAULT, aber nicht beides.

USEMAX (<resolution_column>) | USEMAXEQ (<resolution_column>) | USEMIN (<resolution_column>) | USEMINEQ (<resolution_column>) | USEDELTA |    
DISCARD OVERWRITE IGNORE

Die Konflikt-Handler-Logik, mit der der Konflikt gelöst wird. Gültige Lösungen sind:

USEMAX

Wenn der Wert von <resolution_column> im Traildatensatz größer als der Wert der Spalte in der Datenbank ist, wird die entsprechende Aktion ausgeführt.

USEMAXEQ

Wenn der Wert von <resolution_column> im Traildatensatz größer oder gleich dem Wert der Spalte in der Datenbank ist, wird die entsprechende Aktion ausgeführt.

USEMIN

Wenn der Wert von <resolution_column> im Traildatensatz kleiner als der Wert von <column> in der Datenbank ist, wird die entsprechende <action> ausgeführt:

USEMINEQ

Wenn der Wert von <resolution_column> im Traildatensatz kleiner oder gleich dem Wert von <column> in der Datenbank ist, wird die entsprechende <action> ausgeführt:

<resolution_column>

Der Name einer NOT NULL-Spalte, die als Auflösungsspalte dient. Diese Spalte muss Teil der Spaltengruppe sein, die mit dieser Auflösung verknüpft ist. Der Wert der Auflösungsspalte im Vergleich zum aktuellen Wert in der Zieldatenbank bestimmt, wie eine Auflösung angewendet werden soll. Das Nachbild der Auflösungsspalte wird für den Vergleich verwendet, sofern vorhanden; andernfalls wird der Vorbildwert verwendet. Verwenden Sie eine Spalte, die mit einfachem SQL verglichen werden kann:

Um eine Auflösung mit dem letzten Zeitstempel zu verwenden, verwenden Sie eine Zeitstempelspalte als <resolution_column>, und legen Sie die Zeitstempelspalte auf die aktuelle Zeit fest, zu der eine Zeile eingefügt oder aktualisiert wird. Wenn möglich definieren Sie die Auflösungsspalte mit dem Datentyp SYSTIMESTAMP, der Sekundenbruchteile unterstützt. Wenn Vergleiche mit einer Granularität von unter einer Sekunde durchgeführt werden, sind keine Tie-Breaking Conflict Handler erforderlich, die Fälle auflösen, in denen der Wert der Auflösungsspalte sowohl im Trail als auch im Ziel identisch ist. Wenn Sie sicherstellen, dass der Wert der Zeitstempelspalte (je nach Auflösung) nur erhöht oder verringert werden kann, führen USEMAX und USEMIN nicht zu Datenabweichungen.

Hinweis:

Verwenden Sie keine Primärschlüsselspalte als Auflösungsspalte in einer USEMAX-Anweisung für den UPDATEROWEXISTS-Konflikt. Andernfalls wird Replicat mit einem Fehler wie dem Folgenden beendet:

  2013-04-04 10:18:38 ERROR OGG-01922 Missing RESOLUTION COLUMN NAME while mapping to target table "FIN"."ACCT".

USEDELTA

(Nur UPDATEROWEXISTS-Konflikt) Fügen Sie die Differenz zwischen den Vorher- und Nachher-Werten im Traildatensatz zum aktuellen Wert der Spalte in der Zieldatenbank hinzu. Wenn einer der Werte NULL ist, wird ein Fehler ausgelöst. Basieren Sie USEDELTA auf Spalten, die NUMERIC-Datentypen enthalten. USEDELTA ist in einer Konfiguration mit mehreren Knoten nützlich, wenn eine Zeile gleichzeitig auf mehreren Knoten aktualisiert wird. Es propagiert nur die Differenz der Spaltenwerte an die anderen Knoten, sodass alle Knoten synchronisiert werden.

DISCARD

(Gültig für alle Konflikttypen) Behalten Sie den aktuellen Wert in der Zieldatenbank bei, und schreiben Sie die Daten im Traildatensatz in die Discard-Datei.

Verwenden Sie DISCARD mit Vorsicht, da dies zu Datenabweichungen führen kann.

OVERWRITE

(Gültig für alle Konflikttypen mit Ausnahme von DELETEROWMISSING) Wenden Sie den Traildatensatz wie folgt an:

Verwenden Sie OVERWRITE mit Vorsicht, da dies zu Datenabweichungen führen kann.

IGNORE

(Gültig für alle Konflikttypen) Behalten Sie den aktuellen Wert in der Zieldatenbank bei, und ignorieren Sie den Traildatensatz: Gilt nicht für die Zieltabelle oder eine Discard-Datei.

COLS (<column>[, ...])

Eine nicht standardmäßige Spaltengruppe. Dies ist eine Liste der Spalten in der Zieldatenbank (nach der Zuordnung), die mit einem bestimmten Auflösungstyp verknüpft sind und von diesem bearbeitet werden. Wenn für einen Konflikt keine Spaltengruppe angegeben ist, wirkt sich die für den angegebenen Konflikt angegebene Auflösung auf alle Spalten aus.

Alternativ können Sie eine DEFAULT-Spaltengruppe angeben, die alle Spalten enthält, die nicht in einer anderen Spaltengruppe aufgeführt sind. Siehe Option DEFAULT.

Sie können mehrere Spaltengruppen mit jeweils unterschiedlicher Auflösung angeben. Beispiel: Sie können OVERWRITE für col2 und col3 verwenden und USEDELTA für col4 verwenden. Keine Spalte in einer Gruppe kann in einer anderen Gruppe enthalten sein. Konflikte für Spalten in verschiedenen Spaltengruppen werden entsprechend der angegebenen Auflösung und in der aufgeführten Reihenfolge getrennt aufgelöst.

Spaltengruppen funktionieren wie folgt:

Beispiele

Beispiel 1

Dieses Beispiel zeigt alle Konflikttypen mit USEMAX, OVERWRITE, DISCARD.

MAP fin.src, TARGET fin.tgt,
    COMPARECOLS (ON UPDATE ALL, ON DELETE ALL),
    RESOLVECONFLICT (UPDATEROWEXISTS, (DEFAULT, USEMAX (last_mod_time)),
    RESOLVECONFLICT (INSERTROWEXISTS, (DEFAULT, USEMAX (last_mod_time)),
    RESOLVECONFLICT (DELETEROWEXISTS, (DEFAULT, OVERWRITE)),
    RESOLVECONFLICT (UPDATEROWMISSING, (DEFAULT, OVERWRITE)),
    RESOLVECONFLICT (DELETEROWMISSING, (DEFAULT, DISCARD)),
    );

Beispiel 2

Dieses Beispiel zeigt UPDATEROWEXISTS mit USEDELTA und USEMAX.

MAP fin.src, TARGET fin.tgt,
    COMPARECOLS
    (ON UPDATE KEYINCLUDING (address, phone, salary, last_mod_time),
    ON DELETE KEYINCLUDING (address, phone, salary, last_mod_time)),
    RESOLVECONFLICT (
    UPDATEROWEXISTS,
    (delta_res_method, USEDELTA, COLS (salary)),
    (DEFAULT, USEMAX (last_mod_time)));

Beispiel 3

Dieses Beispiel zeigt UPDATEROWEXISTS mit USEDELTA, USEMAX und IGNORE.

MAP fin.src, TARGET fin.tgt,
    COMPARECOLS
    (ON UPDATE ALLEXCLUDING (comment)),
    RESOLVECONFLICT (
    UPDATEROWEXISTS,
    (delta_res_method, USEDELTA, COLS (salary, balance)),
    (max_res_method, USEMAX (last_mod_time), COLS (address, last_mod_time)),
    (DEFAULT, IGNORE));

SQLEXEC (<SQL_specification>)

SQLEXEC ist gültig für TABLE und MAP.

Verwenden Sie SQLEXEC, um eine gespeicherte SQL-Prozedur oder -Abfrage innerhalb einer MAP-Anweisung während der Oracle GoldenGate-Verarbeitung auszuführen. Mit SQLEXEC kann Oracle GoldenGate direkt mit der Datenbank kommunizieren, um alle von der Datenbank unterstützten Aufgaben auszuführen. Diese Arbeit kann Teil des Synchronisierungsprozesses sein, z. B. das Abrufen von Werten für die Spaltenkonvertierung, oder sie kann unabhängig vom Extrahieren oder Replizieren von Daten sein, z. B. das Ausführen einer gespeicherten Prozedur, die eine Aktion innerhalb der Datenbank ausführt.

Syntax und Syntax finden Sie unter "SQLEXEC".

SQLPREDICATE 'WHERE <where_clause>'

SQLPREDICATE ist für Oracle-, Db2 LUW-, Db2 auf z/OS-, Db2 für i-, PostgreSQL-, MySQL-, SQL Server- und Sybase-Datenbanken gültig. Verwenden Sie SQLPREDICATE nicht für eine Extract-Gruppe, die für die Synchronisierung von Transaktionsänderungen konfiguriert ist. Er eignet sich nur für einen Extract zum erstmaligen Laden, da er eine SELECT-Anweisung abruft, die Datensätze direkt aus Tabellen wählt.

SQLPREDICATE wird mit TABLE verwendet.

Verwenden Sie SQLPREDICATE, um eine herkömmliche SQL-Klausel WHERE in die SELECT-Anweisung aufzunehmen, die Extract verwendet, wenn Daten aus einer Tabelle ausgewählt werden, um einen anfänglichen Ladevorgang vorzubereiten. SQLPREDICATE erzwingt, dass die von der Auswahl zurückgegebenen Datensätze nach den Schlüsselwerten sortiert werden.

SQLPREDICATE ist eine schnellere Auswahlmethode für anfängliche Ladevorgänge als die Optionen WHERE oder FILTER. Sie wirkt sich direkt auf die SQL-Anweisung aus und erfordert nicht, dass Extract alle Datensätze abruft, bevor sie gefiltert werden.

Bei Oracle-Tabellen reduziert SQLPREDICATE die Datenmenge, die im Undo-Segment gespeichert wird. Dadurch kann das Auftreten von Snapshot-zu alten Fehlern reduziert werden. Dies ist nützlich, wenn sehr große Tabellen geladen werden.

Mit einer SQLPREDICATE-Klausel können Sie die Zeilen einer großen Tabelle zwischen zwei oder mehr parallelen Extract-Prozessen partitionieren. Mit dieser Konfiguration können Sie auch die parallele Lastverarbeitung für die Zustellung nutzen.

Mit SQLPREDICATE können Sie auch Daten basierend auf einem Zeitstempel oder anderen Kriterien auswählen, um die Zeilen zu filtern, die extrahiert und in die Zieltabelle geladen werden. SQLPREDICATE kann für ORDER BY-Klauseln oder andere Auswahlklauseln verwendet werden.

Stellen Sie sicher, dass die WHERE-Klausel Spalten enthält, die Teil eines Schlüssels oder Index sind. Andernfalls führt Extract einen Full Table Scan aus, wodurch die Effizienz der SELECT-Anweisung verringert wird.

Syntax

TABLE <source_table>, SQLPREDICATE 'WHERE <where_clause>';

WHERE

Dies ist ein erforderliches Schlüsselwort.

<where_clause>

Eine gültige SQL-Klausel WHERE, die Datensätze aus den Quelltabellen auswählt.

Beispiel

TABLE hr.emp, SQLPREDICATE 'WHERE state = 'CO' and city = 'DENVER''

THREAD (<thread_ID>)

THREAD ist gültig für MAP. Diese Option ist gültig, wenn sich Replicat im koordinierten Modus befindet.

Geben Sie mit THREAD an, dass alle Objekte in derselben MAP-Anweisung vom angegebenen Replicat-Thread verarbeitet werden sollen. Der angegebene Thread verarbeitet Filterung, Manipulation, Zustellung an das Ziel, Fehlerbehandlung und andere Arbeit, die für diese Objekte konfiguriert ist. Platzhalter können in der TARGET-Klausel verwendet werden, wenn THREAD verwendet wird.

Alle Tabellen, die referenzielle Abhängigkeiten untereinander haben, müssen im selben Thread zugeordnet werden. Beispiel: Wenn die Tabellen scott.cust und scott.ord eine Fremdschlüsselbeziehung aufweisen, ist Folgendes ein mögliches Mapping:

MAP scott.cust, TARGET scott.cust, THREAD (5);
MAP scott.ord, TARGET scott.ord, THREAD (5);

Der Thread mit dem niedrigsten Thread ID verarbeitet Barrieretransaktionen immer, wenn die Option THREAD oder THREADRANGE ausgelassen wird. Darüber hinaus wird Arbeit, die einem Thread nicht explizit zugewiesen ist, über diesen Thread verarbeitet. Beispiel: Wenn Threads mit IDs zwischen 1 und 10 vorhanden sind, werden Barrieretransaktionen und nicht zugewiesene Transaktionen von Thread 1 ausgeführt.

Informationen zum Verarbeiten einer MAP-Anweisung zwischen mehreren Threads finden Sie unter THREADRANGE (thread_range, column_list). THREAD und THREADRANGE schließen sich gegenseitig aus. Verwenden Sie sie nicht zusammen in derselben MAP-Anweisung.

Syntax

THREAD (<thread_ID>)

<thread_ID>

Eine numerische ID für den Thread, der diese MAP-Anweisung verarbeitet. Gültige Werte sind 1 bis zum Wert, der mit der Option MAXTHREADS des ADD REPLICAT-Befehls angegeben wurde, der diese Gruppe erstellt hat. Mit dem Befehl INFO REPLICAT können Sie prüfen, wie viele Threads maximal für eine Replicat-Gruppe zulässig sind. Bei der Angabe von Thread-IDs muss Folgendes zutreffen:

Wenn MAXTHREADS nicht verwendet wurde, beträgt die standardmäßige maximale Anzahl von Threads 25.

Beispiele

Die folgenden Beispiele zeigen einige Möglichkeiten zur Verwendung der Option THREAD.

Beispiel 1

In diesem Beispiel verarbeitet Thread 1 Tabelle cust.

MAP scott.cust, TARGET scott.cust, THREAD (1);

Beispiel 2

In diesem Beispiel verarbeitet Thread 1 alle Tabellen im Schema scott.

MAP scott.*, TARGET scott.*, THREAD (1);

Beispiel 3

In diesem Beispiel wird die Tabelle orders mithilfe von FILTER (filter_clause) und der Funktion @RANGE zwischen zwei MAP-Anweisungen partitioniert. Weitere Informationen zu @RANGE finden Sie unter "@RANGE".

MAP scott.orders, TARGET scott.orders, FILTER (@RANGE (1, 2, OID)), THREAD (1);
MAP scott.orders, TARGET scott.orders, FILTER (@RANGE (2, 2, OID)), THREAD (2);

THREADRANGE (<thread_range>,<column_list>)

THREADRANGE ist gültig für MAP. Diese Option ist gültig, wenn sich Replicat im koordinierten Modus befindet.

Geben Sie mit THREADRANGE an, dass die Workload der Zieltabelle gleichmäßig zwischen einem Bereich von Replicat-Threads partitioniert werden soll, basierend auf dem Wert einer oder mehrerer Spalten. Beispiel: Wenn die Partitionierung auf dem Wert einer Spalte mit dem Namen ID basiert und der Wert THREADRANGE 1-3 ist, verarbeitet Thread 1 Zeilen mit ID-Werten von 1 bis 10, Thread 2 Zeilen mit ID-Werten von 11 bis 20 und Thread 3 Zeilen mit ID-Werten von 21 bis 30. Abhängig von der anfänglichen Berechnung der Arbeitslast ist die Partitionierung möglicherweise nicht so absolut wie im vorherigen Beispiel dargestellt. Sie wird jedoch so koordiniert, dass dieselbe Zeile immer vom selben Thread verarbeitet wird. Jeder angegebene Thread verarbeitet Filterung, Manipulation, Fehlerbehandlung, Zustellung an das Ziel und andere Arbeit für seinen Zeilenbereich.

Durch die Partitionierung einer Tabelle über eine Reihe von Threads kann die Apply-Performance für sehr große Tabellen oder Tabellen verbessert werden, die häufig Transaktionen mit langer Ausführungszeit oder ein hohes Volumen aufweisen, aber auch in anderen Fällen verwendet werden können. Sie können mehrere Tabellen über denselben Threadbereich verarbeiten.

Eine TARGET-Klausel mit Platzhaltern kann verwendet werden, wenn THREADRANGE verwendet wird, wenn die optionale Spaltenliste ausgelassen wird. Wenn Sie eine Spaltenliste verwenden, verwenden Sie separate explizite MAP-Anweisungen für jede Tabelle, die denselben Threadbereich verwendet.

Informationen zum Verarbeiten einer MAP-Anweisung mit einem bestimmten Thread finden Sie unter THREAD (thread_ID). THREAD und THREADRANGE schließen sich gegenseitig aus. Verwenden Sie sie nicht zusammen in derselben MAP-Anweisung.

Geben Sie keine Tabellen an, die in einem Threadbereich referenzielle Abhängigkeiten untereinander aufweisen. Verwenden Sie die Option THREAD, und verarbeiten Sie alle diese Tabellen mit demselben Thread.

Verwenden Sie THREADRANGE nicht zum Partitionieren von Sequenzen. Wenn eine Koordination erforderlich ist, z.B. wenn eine Sequenz Teil eines SQLEXEC-Vorgangs ist, partitionieren Sie die Sequenzarbeit mit der Option THREAD in einen Thread.

Der Thread mit dem niedrigsten Thread ID verarbeitet Barrieretransaktionen immer, wenn die Option THREAD oder THREADRANGE ausgelassen wird. Darüber hinaus wird Arbeit, die einem Thread nicht explizit zugewiesen ist, über diesen Thread verarbeitet. Beispiel: Wenn Threads mit IDs zwischen 1 und 10 vorhanden sind, werden Barrieretransaktionen und nicht zugewiesene Transaktionen von Thread 1 ausgeführt. Hinweis: Die in einer Spaltenliste angegebenen Spalten müssen in der Traildatei vorhanden sein. Sie können dies mit KEYCOLS in Extract steuern, um diese Spalte einzuschließen, oder indem Sie FETCHCOLS in Extract für die Spalte verwenden oder indem Sie sicherstellen, dass die Spalte Teil der zusätzlichen Loggruppe ist, und dann LOGALLSUPCOLS verwenden.

Syntax

THREADRANGE (<lowID>-<highID>, [<column>[, <column>][, ...]])

<lowID>

Die niedrigste Thread-ID dieses Bereichs. Gültige Werte sind 1 bis 500.

<highID>

Die höchste Thread-ID dieses Bereichs, die eine höhere Zahl als <lowID> sein muss. Gültige Werte sind <lowID>+1 bis 500. Die Anzahl der Threads im Bereich darf den Wert nicht überschreiten, der mit der Option MAXTHREADS des Befehls ADD REPLICAT angegeben wurde. Wenn MAXTHREADS nicht verwendet wurde, beträgt die standardmäßige maximale Anzahl von Threads 25.

[<column>[, <column>][, ...]]

Optional. Gibt eine oder mehrere eindeutige Spalten an, auf denen die Zeilenpartitionierung basieren soll. Um mehrere Spalten anzugeben, verwenden Sie eine durch Komma getrennte Liste, wie col1, col2, col3. Wenn diese Option ausgelassen wird, basiert die Partitionierung zwischen den Threads standardmäßig auf den folgenden Spalten in der angegebenen Reihenfolge:

Beispiel

Im folgenden Beispiel werden die Tabellen orders und order_lines basierend auf dem Wert der Spalte OID zwischen denselben beiden Threads aufgeteilt.

MAP scott.orders, TARGET scott.orders, THREADRANGE (1-2, OID);
MAP scott.order_lines, TARGET scott.order_lines, THREADRANGE (1-2, OID);

TOKENS (<token_definition>)

TOKENS ist gültig für TABLE.

Verwenden Sie TOKENS, um ein Benutzertoken zu definieren und mit Daten zu verknüpfen. Mit Token können Sie Daten im Benutzer-Tokenbereich eines Traildatensatzheaders extrahieren und speichern. Tokendaten können auf vielfältige Weise abgerufen und verwendet werden, um die Art und Weise anzupassen, wie Oracle GoldenGate Daten bereitstellt. Beispiel: Sie können Tokendaten in Spaltenzuordnungen, gespeicherten Prozeduren, die von SQLEXEC aufgerufen werden, oder Makros verwenden.

Um die definierten Tokendaten in Zieltabellen zu verwenden, verwenden Sie die Spaltenkonvertierungsfunktion @TOKEN in der COLMAP-Klausel einer Replicat MAP-Anweisung. Die Funktion @TOKEN ordnet den Namen eines Tokens einer Zielspalte zu.

Verwenden Sie diese Option nicht für Tabellen, die im Passthrough-Modus von einer Data Pump-Extraktgruppe verarbeitet werden.

Der Zeichensatz der Tokendaten wird nicht konvertiert. Das Token muss sich im Zeichensatz der Quelldatenbank für Extract und im Zeichensatz der Zieldatenbank für Replicat befinden.

Syntax

TOKENS (<token_name> = <token_data> [, ...])

<token_name>

Ein Name Ihrer Wahl für das Token. Dabei kann es sich um eine beliebige Anzahl gültiger Zeichen handeln, und die Groß-/Kleinschreibung wird nicht beachtet. Mehrbyte-Namen werden nicht unterstützt.

<token_data>

Beliebige gültige Zeichenfolge mit bis zu 2000 Byte. Die Daten können entweder ein Literal sein, das in einfache Anführungszeichen (oder in doppelte Anführungszeichen gesetzt ist, wenn NOUSEANSISQLQUOTES verwendet wird) oder das Ergebnis einer Oracle GoldenGate-Spaltenkonvertierungsfunktion.

Beispiel

Im Folgenden werden die Token TK-OSUSER, TK-GROUP und TK-HOST erstellt und Token zugeordnet, die mit der Funktion @GETENV abgerufen wurden.

TABLE ora.oratest, TOKENS (
TK-OSUSER = @GETENV ('GGENVIRONMENT' , 'OSUSERNAME'),
TK-GROUP = @GETENV ('GGENVIRONMENT' , 'GROUPNAME')
TK-HOST =  @GETENV ('GGENVIRONMENT' , 'HOSTNAME'));

TRIMSPACES | NOTRIMSPACES

TRIMSPACES und NOTRIMSPACES sind für TABLE und MAP gültig.

Verwenden Sie TRIMSPACES und NOTRIMSPACES auf Root-Ebene einer Parameterdatei oder in einer TABLE- oder MAP-Anweisung, um zu steuern, ob nachgestellte Leerzeichen in einer CHAR-Quellspalte abgeschnitten werden, wenn sie auf eine CHAR- oder VARCHAR-Zielspalte angewendet werden. Der Standardwert ist TRIMSPACES.

Syntax und Syntax finden Sie unter "TRIMSPACES | NOTRIMSPACES".

TRIMVARSPACES | NOTRIMVARSPACES

TRIMVARSPACES und NOTRIMVARSPACES sind für TABLE und MAP gültig.

Verwenden Sie TRIMVARSPACES und NOTRIMVARSPACES auf Root-Ebene einer Parameterdatei oder in einer TABLE- oder MAP-Anweisung, um zu steuern, ob nachgestellte Leerzeichen in einer VARCHAR-Quellspalte abgeschnitten werden, wenn sie auf eine CHAR- oder VARCHAR-Zielspalte angewendet werden. Der Standardwert ist NOTRIMVARSPACES.

Syntax und Syntax finden Sie unter "TRIMVARSPACES | NOTRIMVARSPACES".

WHERE (<clause>)

WHERE ist gültig für TABLE und MAP.

Verwenden Sie WHERE, um Datensätze basierend auf einer bedingten Anweisung auszuwählen. WHERE unterstützt Folgendes nicht:

Setzen Sie Literale in einfache Anführungszeichen. Geben Sie Spaltennamen an, bei denen die Groß-/Kleinschreibung beachtet wird, während sie in der Datenbank gespeichert werden, und setzen Sie sie in doppelte Anführungszeichen, wenn die Datenbank Anführungszeichen benötigt, um die Groß-/Kleinschreibung zu erzwingen (z. B. Oracle).

Weitere Informationen zur Datensatzfilterung abrufen

Syntax

WHERE (<clause>)

<clause>

Wählt Datensätze basierend auf einer Bedingung aus, z.B.:

WHERE (branch = 'NY')

In Tabelle 2-12 sind zulässige WHERE-Operatoren dargestellt.

Tabelle 12: Zulässige Operatoren WHERE

Bediener Beispiel
Spaltennamen PRODUCT_AMT "Product_Amt"
Numerische Werte -123, 5500.123
Literale Zeichenfolgen in einfachen Anführungszeichen 'AUTO', 'Ca'
Spaltentests @NULL, @PRESENT, @ABSENT (Spalte ist Null, im Datensatz vorhanden oder abwesend). Diese Tests sind in Oracle GoldenGate integriert.
Comparison operators =, <>, >, <,>=, <= < td>
Conjunctive operators `AND`, `OR`
Grouping parentheses Use open and close parentheses for logical grouping of multiple elements.

Example

The following WHERE example returns all records when the AMOUNT column is over 10,000 and does not cause a record to be discarded when AMOUNT is absent.

WHERE (amount = @PRESENT AND amount > 10000)

PARTITIONOBJID

Valid for Integrated Extract.

PARTITIONOBJID is used to specify the object IDs of the partitions to be captured for partitioned tables, and applies to Integrated Extract. For an IO table (with or without overflow area), index segment object ID should be used for partition level filtering. In this case, PARTITIONOBJID in the MAP or TABLE statement specifies the index segment object IDs of the partitions to be extracted.

Syntax

MAP/TABLE [container.]schema.table PARTITIONOBJID ptn_object_ID [, ptn_object_ID]

Es gelten folgende Einschränkungen:

Syntax for IO table TABLE statement:

TABLE [container.]schema.table PARTITIONOBJID index_segment_object_ID [, index_segment_object_ID]

Syntax for IO table MAP statement:

MAP [container.]schema.table PARTITIONOBJID index_segment_object_ID [, index_segment_object_ID]