TABLE | MAP

Valido per

TABLE è valido per Extract. È possibile utilizzare TABLE con Replicat solo con il parametro EVENTACTIONS. MAP è valido per Extract in determinate situazioni e Replicat. Per ulteriori informazioni, vedere MAP for Extract.

Descrizione

I parametri TABLE e MAP controllano la selezione, il mapping e la manipolazione degli oggetti che devono essere interessati da un processo Oracle GoldenGate. Questi parametri funzionano come segue:

TABLE e MAP sono validi per le configurazioni di caricamento iniziale e per i processi online configurati per supportare la replica delle modifiche transazionali.

È possibile elaborare i seguenti oggetti con TABLE e MAP:

Per specificare una sequenza per l'acquisizione mediante Extract, utilizzare il parametro SEQUENCE.

Nota: Oracle GoldenGate supporta la replica dei valori dati effettivi delle viste materializzate Oracle.

È possibile utilizzare una o più istruzioni TABLE o MAP in un file di parametri, con o senza caratteri jolly, per specificare tutti gli oggetti che si desidera elaborare.

È possibile escludere gli oggetti da un'istruzione TABLE o MAP con caratteri jolly con i seguenti parametri:

Predefinito

Nessuno

Sintassi per TABLE

Per le tabelle, è possibile utilizzare tutte le opzioni TABLE. Per gli oggetti non da tavolo, utilizzare TABLE solo per specificare un oggetto da acquisire.

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>]
;

Sintassi per 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>]
;

Opzioni TABLE e MAP

La tabella seguente riassume le opzioni disponibili per i parametri TABLE e MAP. Si noti che non tutte le opzioni sono valide per entrambi i parametri.

Tabella 11 Riepilogo dei componenti di sintassi TABLE e MAP

Componente Descrizione Valido per
MAP MOD_COMPARE_COL( tgt_col = source [,...] ) Questo è un parametro solo Replicat. Assegna il valore di origine specificato all'immagine precedente della colonna di destinazione come valore chiave e il valore viene utilizzato per la clausola WHERE. MAP
TABLE <source_table>[, TARGET <target>] Specifica l'oggetto di origine in un'istruzione TABLE per Extract e un mapping facoltativo a un oggetto di destinazione. Utilizzare nel file dei parametri Extract. TABLE
MAP source_table, TARGET target_table Specifica il mapping di oggetti di origine-destinazione per il processo Replicat. Utilizzare nel file dei parametri Replicat. MAP
ATTRCHARSET (charset) specifica le informazioni sul set di caratteri di origine a livello di attributo UDT. TABLE
COLCHARSET character_set Specifica qualsiasi set di caratteri supportato. TABLE
COLMAP (column_mapping) Esegue il mapping dei record tra colonne di origine e di destinazione diverse. TABLE e MAP
{COLS \| COLSEXCEPT} (column_list) Seleziona o esclude le colonne per l'elaborazione. TABLE
COMPARECOLS (column_specification) Specifica le colonne da utilizzare per il rilevamento e la risoluzione dei conflitti. TABLE e MAP
COORDINATED Forza l'elaborazione di una transazione come transazione barriera. MAP
{DEF | TARGETDEF} template Specifica un template source-definitions o target-definitions. TABLE e MAP
EXCEPTIONSONLY Specifica che l'istruzione MAP è un'istruzione MAP delle eccezioni. MAP
EVENTACTIONS (action) Attiva un'azione basata su un record che soddisfa una regola di filtro specificata. TABLE e MAP
EXITPARAM 'parameter' Passa un parametro sotto forma di stringa letterale a un'uscita utente. TABLE e MAP
FETCHBEFOREFILTER Indica l'azione FETCHCOLS o FETCHCOLSEXCEPT da eseguire prima dell'esecuzione di un filtro. TABLE
{FETCHCOLS | FETCHCOLSEXCEPT} (column_list) Abilita il recupero dei valori di colonna dal database di origine quando i valori non sono presenti nel record transazione. TABLE
{FETCHMODCOLS | FETCHMODCOLSEXCEPT} (column_list) Forza il recupero dei valori di colonna dal database quando le colonne sono presenti nel log delle transazioni. TABLE
FILTER (filter_clause) Seleziona i record in base a un valore numerico. FILTER offre maggiore flessibilità rispetto a WHERE. TABLE e MAP
GETBEFORECOLS (column_specification) Forza prima che le immagini delle colonne vengano acquisite e scritte nel trail. TABLE
HANDLECOLLISIONS \| NOHANDLECOLLISIONS Consente di riconciliare i risultati delle modifiche apportate alla tabella target mediante un processo di caricamento iniziale con quelli applicati da un gruppo di sincronizzazione delle modifiche. MAP
INSERTALLRECORDS Applica tutte le modifiche di riga come inserimenti. MAP
INSERTAPPEND \| NOINSERTAPPEND Controlla se Replicat utilizza un suggerimento APPEND Oracle per le istruzioni INSERT. MAP
KEYCOLS (columns) Indica le colonne che identificano in modo univoco le righe. TABLE e MAP
MAPALLCOLUMNS | NOMAPALLCOLUMNS Controlla se Replicat ottiene o meno colonne non chiave. ND
MAPEXCEPTION (exceptions_mapping) Specifica che l'istruzione MAP contiene la gestione delle eccezioni per le tabelle con caratteri jolly. MAP
MAPINVISIBLECOLUMNS | NOMAPINVISIBLECOLUMNS Controlla se Replicat include colonne invisibili nelle tabelle di destinazione Oracle per il mapping delle colonne predefinito. Per le colonne invisibili nelle tabelle di destinazione Oracle che utilizzano il mapping di colonne esplicito, vengono sempre mappate, pertanto non è necessaria questa opzione. MAP
REPERROR (error, response) Controlla come Replicat risponde agli errori durante l'esecuzione dell'istruzione MAP. MAP
RESOLVECONFLICT (conflict_resolution_specification) Specifica le regole per la risoluzione dei conflitti. MAP
SQLEXEC (SQL_specification) Esegue le stored procedure e query. TABLE e MAP
SQLPREDICATE 'WHERE where_clause' Abilita una clausola WHERE per selezionare le righe per un caricamento iniziale. TABLE
THREAD (thread_ID) Valido per Replicat in modalità coordinata. Specifica che l'istruzione MAP verrà elaborata dal thread Replicat specificato. MAP
THREADRANGE (thread_range, column_list) Valido per Replicat in modalità coordinata. Specifica che l'istruzione MAP verrà elaborata dall'intervallo specificato di thread Replicat. MAP
TOKENS (token_definition) Definisce i token utente. TABLE
TRIMSPACES \| NOTRIMSPACES Controlla se gli spazi finali vengono troncati o meno durante il mapping delle colonne da CHAR a VARCHAR. TABLE e MAP
TRIMVARSPACES \| NOTRIMVARSPACES Controlla se gli spazi finali vengono troncati o meno durante il mapping delle colonne da VARCHAR a CHAR o VARCHAR. TABLE e MAP
WHERE (clause) Seleziona i record in base agli operatori condizionali. TABLE e MAP
; (Semicolon) Termina l'istruzione TABLE o MAP ed è necessaria. TABLE e MAP
PARTITIONOBJID Disponibile per l'estrazione integrata. Questa opzione viene utilizzata per specificare gli ID oggetto delle partizioni da acquisire per le tabelle partizionate. TABLE e MAP

MAPPA MOD_COMPARE_COL( tgt_col = fonte [,…] )

tgt_col deve essere il nome della colonna della tabella di destinazione e deve essere la colonna chiave per rendere effettiva correttamente. source può essere la colonna della tabella di origine, il valore costante (numero o stringa), la funzione di mapping delle colonne o i risultati SQLEXEC. Ad esempio, source col1 viene mappato a target col 1. source col1 prima che il valore dell'immagine sia 1, che è un valore fittizio perché è mascherato dal DBA per motivi di sicurezza. Replicat può eseguire una query sul valore effettivo prima del valore dell'immagine target col1 per SQLEXEC. Utilizzando MOD_COMPARE_COLS(), Replicat sostituisce il valore source col1 fittizio con il risultato SQLEXEC, in modo che l'operazione UPDATE o DELETE funzioni correttamente.

TABLE <source_table>[, TARGET <target>]

TABLE è valido in un file dei parametri Extract.

Utilizzare TABLE per specificare un oggetto di origine per il quale si desidera che Extract acquisisca i dati. Specificare il nome completo in due o tre parti dell'oggetto, ad esempio <schema.table> o <catalog.schema.table>. È possibile utilizzare un carattere jolly per specificare più oggetti con una sola istruzione TABLE. Per specificare correttamente i nomi degli oggetti e i caratteri jolly, vedere Uso dei caratteri jolly nei nomi degli oggetti di database e Uso dei caratteri jolly negli argomenti dei comandi nella documentazione dei microservizi di Oracle GoldenGate.

Utilizzare l'opzione TARGET solo quando Extract deve fare riferimento a un file di definizioni di destinazione (specificato con il parametro TARGETDEFS) per eseguire conversioni o quando l'opzione COLMAP viene utilizzata per mappare le colonne. Altrimenti, può essere omesso da un parametro TABLE. Il mapping delle colonne con COLMAP e il lavoro di conversione vengono in genere eseguiti sul sistema di destinazione per ridurre al minimo l'impatto delle attività di replica sul sistema di origine, ma possono essere eseguiti sul sistema di origine, se necessario. Ad esempio, è possibile eseguire il mapping e la conversione delle colonne nel sistema di origine in una configurazione in cui sono presenti più origini e una destinazione. In questo scenario, può essere più facile gestire un file di definizioni di destinazione piuttosto che gestire un file di definizioni per ogni database di origine, soprattutto se ci sono frequenti modifiche all'applicazione che richiedono la generazione di nuovi file di definizioni.

L'uso di TARGET in un parametro TABLE identifica i metadati dei dati estratti in base alla struttura di destinazione, anziché a quella dell'origine, per riflettere la struttura del record riflessa nel file delle definizioni o nella mappa delle colonne. Non utilizzare nomi in tre parti se TARGET specifica tabelle in un container database Oracle di destinazione. Replicat può connettersi solo a un contenitore o catalogo, quindi si presume che la parte del contenitore o del catalogo del nome sia uguale a quella in cui Replicat esegue il login (come specificato con USERIDALIAS, a seconda del database).

Se non sono necessarie altre opzioni di sintassi TABLE per elaborare i dati di origine specificati, è possibile utilizzare una semplice istruzione TABLE, assicurandosi di terminarla con un punto e virgola.

 TABLE sales.customers;

Di seguito viene illustrato l'uso di un carattere jolly per specificare più tabelle.

 TABLE sales.*;

Le istruzioni TABLE precedenti indirizzano Extract per acquisire tutti i dati di colonna supportati per gli oggetti specificati e scriverli nel trail senza eseguire alcun filtro, conversione o altra manipolazione.

MAP <source_table>, TARGET <target_table>

MAP è valido in un file dei parametri Replicat. È inoltre possibile utilizzare MAP in un file dei parametri Extract per modificare il nome delle transazioni memorizzate da Oracle GoldenGate per la tabella. Vedere

Utilizzare MAP per specificare un oggetto di origine e TARGET per specificare l'oggetto di destinazione a cui Replicat applica i dati di origine replicati. Insieme, le clausole MAP e TARGET comprendono un mapping.

Di seguito viene illustrato l'uso di un carattere jolly per specificare più tabelle. Si noti che la clausola TARGET non include il prefisso tab prima del carattere jolly. La specifica non sarà valida perché il carattere jolly verrà risolto come sales.tabtab1, sales.tabtab2 e così via.

 MAP sales.tab*, TARGET sales.*;

Se non sono necessari filtri, mapping o altro lavoro per gli oggetti, è possibile utilizzare semplici istruzioni MAP come le seguenti, assicurandosi di terminare ciascuna di esse con un punto e virgola.

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

ATTRCHARSET <(charset)>

ATTRCHARSET è valido per TABLE.

Utilizzare la clausola ATTRCHARSET per specificare le informazioni sul set di caratteri di origine a livello di attributo UDT. Sostituisce il set di caratteri definito nel file trail o specificato dai parametri SOURCECHARSET, CHARSET o COLCHARSET.

I valori validi sono i nomi dei set di caratteri e i nomi degli attributi UDT validi. Sono supportati i nomi degli attributi con caratteri jolly. Ad esempio:

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

COLCHARSET <character_set>

COLCHARSET è valido per TABLE.

Utilizzare la clausola COLCHARSET per specificare qualsiasi set di caratteri supportato. Per ulteriori informazioni, vedere COLCHARSET.

COLMAP <(column_mapping)>

COLMAP è valido per TABLE e MAP.

Utilizzare COLMAP per effettuare le operazioni riportate di seguito.

COLMAP fornisce istruzioni per la selezione, la traduzione e lo spostamento dei dati delle colonne da una colonna di origine a una colonna di destinazione. Nota: per creare regole globali per il mapping delle colonne in tutte le tabelle nelle istruzioni MAP successive, utilizzare il parametro COLMATCH.

Ulteriori informazioni sulla configurazione del mapping di colonne

Per utilizzare COLMAP, è necessario prendere in considerazione le linee guida di configurazione correlate, ad esempio se le strutture delle colonne di origine e di destinazione sono identiche o diverse e se i parametri di mapping delle colonne globali possono essere sufficienti.

Sintassi

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

USEDEFAULTS

Mappa automaticamente le colonne di origine e di destinazione con lo stesso nome se non sono state specificate in un mapping di colonne esplicito. I tipi di dati vengono tradotti automaticamente, se necessario, in base al file di definizione dei dati locale. USEDEFAULTS elimina la necessità di un mapping di colonne esplicito se tali colonne hanno lo stesso nome e i dati non richiedono alcun filtro o conversione.

Specificare USEDEFAULTS prima dei mapping espliciti delle colonne nella clausola COLMAP.

<target_column = source_expression>

Definisce un mapping esplicito di colonne di origine-destinazione.

<target_column>

Specifica il nome della colonna di destinazione. Per i caratteri supportati nei nomi delle colonne, vedere Set di caratteri supportati.

<source_expression>

Può essere uno dei valori seguenti:

BINARYINPUT

Utilizzare BINARYINPUT quando la colonna di destinazione è definita come tipo di dati binario, ad esempio RAW o BLOB, ma l'input di origine contiene zeri binari al centro dei dati. L'input di origine viene gestito come input binario e la sostituzione dei valori dati viene eliminata.

Esempio 1

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

Esempio 2

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

{COLS | COLSEXCEPT} (<column_list>)

COLS e COLSEXCEPT sono validi per TABLE.

Utilizzare COLS e COLSEXCEPT per controllare le colonne per le quali vengono acquisiti i dati.

Per utilizzare COLS, è necessario quanto riportato di seguito.

Senza una chiave primaria, una chiave univoca o una clausola KEYCOLS nell'istruzione TABLE, Oracle GoldenGate utilizza tutte le colonne della tabella, rendendo non necessario COLS.

Nota: non utilizzare questa opzione per le tabelle elaborate in modalità pass-through da un gruppo Extract di Data Pump.

Sintassi

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

<column>

Nome di una colonna. Per specificare più <columns>, creare un elenco delimitato da virgole, ad esempio:

COLS (name, city, state, phone)

Nota: se il database registra solo i valori per le colonne modificate in un'operazione di aggiornamento, una colonna specificata per l'acquisizione con COLS potrebbe non essere disponibile. Per rendere disponibili tali colonne, utilizzare l'opzione FETCHCOLS nell'istruzione TABLE oppure abilitare la registrazione supplementare per la colonna.

Esempio

COLS <clause> in questo esempio acquisisce solo <columns> 1 e 3, mentre COLSEXCEPT <clause> acquisisce tutti i <columns> tranne <columns> 1 e 3.

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

COMPARECOLS (<column_specification>)

COMPARECOLS è valido per MAP.

Utilizzare COMPARECOLS per specificare le colonne utilizzate da Replicat per rilevare e risolvere i conflitti di aggiornamento o eliminazione quando configurato con l'opzione RESOLVECONFLICT di MAP in una configurazione multi-master. Un conflitto è una mancata corrispondenza tra l'immagine precedente di un record nel trail e i dati appropriati nella tabella di destinazione.

Per utilizzare COMPARECOLS, l'immagine precedente deve essere disponibile nel record trail mediante il parametro GETBEFORECOLS nell'istruzione Extract TABLE. Le colonne specificate devono esistere nel database di destinazione e anche far parte della configurazione Replicat (soddisfare la specifica TARGET con o senza una clausola COLMAP).

Solo i tipi di dati scalari sono supportati da COMPARECOLS come colonne di confronto. Un tipo di dati scalare può essere utilizzato in una clausola WHERE, ha un singolo valore atomico e nessun componente interno. I tipi di dati scalari supportati da Oracle GoldenGate includono i seguenti, ma non i LOB.

Alcuni esempi di tipi di dati non scalari sono dati spaziali, tipi di dati definiti dall'utente, oggetti di grandi dimensioni (LOB), XML, tipi di dati di riferimento e RAW. Una riga considerata per la CDR può includere dati non scalari purché il conflitto non si trovi nei dati non scalari stessi.

Per specificare le routine di risoluzione dei conflitti, utilizzare l'opzione RESOLVECONFLICT di MAP. COMPARECOLS e RESOLVECONFLICT possono essere inclusi in qualsiasi ordine nell'istruzione MAP.

Ulteriori informazioni sulla configurazione della funzione CDR

Per ulteriori informazioni sulla configurazione del rilevamento e della risoluzione di conflitti, vedere Rilevamento e risoluzione automatici dei conflitti o Rilevamento e risoluzione manuale dei conflitti.

Sintassi

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

Specifica se l'immagine precedente delle colonne specificate deve essere confrontata per gli aggiornamenti o le eliminazioni. È possibile utilizzare solo ON UPDATE, solo ON DELETE o entrambi. Se si utilizzano entrambi, specificarli all'interno della stessa clausola COMPARECOLS. Per informazioni sull'utilizzo di entrambi, vedere l'esempio.

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

Specifica le colonne per le quali viene acquisita un'immagine precedente.

ALL

Confronta utilizzando tutte le colonne della tabella di destinazione. Viene generato un errore se le immagini corrispondenti prima non sono disponibili nel trail. L'utilizzo di ALL impone il carico di elaborazione più elevato per Replicat, ma consente di eseguire confronti di rilevamento dei conflitti utilizzando tutte le colonne per ottenere la massima precisione.

KEY

Confronta solo le colonne chiave primaria. Questa è l'opzione più veloce, ma non consente il rilevamento dei conflitti più accurato, perché le chiavi possono corrispondere, ma le colonne non chiave potrebbero essere diverse.

KEYINCLUDING

Confronta le colonne chiave primaria e la colonna o le colonne specificate. Si tratta di un compromesso ragionevole tra velocità e precisione di rilevamento.

ALLEXCLUDING

Confronta tutte le colonne tranne quelle specificate. Per le tabelle con numerose colonne, ALLEXCLUDING può essere più efficiente di KEYINCLUDING. Non escludere le colonne chiave.

Esempio 1

Nell'esempio seguente, per i conflitti vengono confrontate le colonne chiave più le colonne name, address e salary.

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

Esempio 2

Nell'esempio seguente, la colonna comment viene ignorata e tutte le altre colonne vengono confrontate per i conflitti.

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

COORDINATO

COORDINATED è valido per MAP. Questa opzione è valida quando Replicat è in modalità coordinata.

Utilizzare l'opzione COORDINATED per forzare l'elaborazione delle transazioni eseguite su oggetti nella stessa istruzione MAP come transazioni barriera. Fa sì che tutti i thread di tutte le istruzioni MAP vengano sincronizzati con la stessa posizione di trail. La posizione sincronizzata è l'inizio della transazione che contiene un record che soddisfa un valore MAP contenente la parola chiave COORDINATED. La transazione viene quindi applicata atomicamente da un singolo thread, che è il thread con il thread più basso ID tra i thread attualmente in esecuzione o un thread dedicato con il ID di 0 se nel file dei parametri è specificato USEDEDICATEDCOORDINATIONTHREAD.

Le clausole THREAD e THREADRANGE specificate insieme a COORDINATED vengono ignorate perché il record non verrà applicato dai thread designati. La parola chiave COORDINATED comporta la sospensione temporanea del parallelismo in modo che le tabelle di destinazione si trovino in uno stato coerente prima dell'applicazione della transazione forzata coordinata. Dopo questo punto, l'esecuzione parallela ricomincia.

Replicat coordina per impostazione predefinita le transazioni in cui viene aggiornata la chiave primaria, le transazioni che eseguono DDL e alcune azioni EVENTACTIONS. COORDINATED prevede un coordinamento esplicito.

Per ulteriori informazioni, vedere Informazioni sulla replica coordinata.

Sintassi

COORDINATED

Esempio

Di seguito è riportato un esempio di utilizzo dell'opzione COORDINATED. In questo esempio, le regole business richiedono che le tabelle di destinazione si trovino in uno stato coerente prima che Replicat esegua le transazioni che includono operazioni SQLEXEC sugli oggetti specificati nell'istruzione MAP. In questo caso, il parallelismo deve essere temporaneamente convertito in elaborazione SQL seriale.

Data la seguente istruzione MAP, se un altro thread inserisce in t2 un record con valore 100 per col_val prima che il thread 1 esegua l'inserimento in t1, SQLEXEC eliminerà la riga. Se altri thread stanno ancora elaborando il record con valore 100, SQLEXEC non riesce. I risultati di questa istruzione MAP non sono pertanto prevedibili.

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

Al contrario, quando si utilizza COORDINATED, tutti i thread vengono sincronizzati in un punto comune, incluso quello che elabora il record col_val=100, eliminando così l'ambiguità dei risultati.

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 e TARGETDEF sono validi per TABLE e MAP.

Utilizzare DEF e TARGETDEF per specificare il nome di un modello di definizioni creato dalla utility DEFGEN.

Un modello si basa sulle definizioni di una tabella specifica. Consente di aggiungere nuove tabelle con le stesse definizioni della tabella originale alla configurazione di Oracle GoldenGate senza eseguirne DEFGEN e senza dover arrestare e avviare il processo Oracle GoldenGate. Le definizioni nel modello vengono utilizzate per le ricerche delle definizioni.

Sintassi

{DEF | TARGETDEF} <template>

<template>

Il nome di uno dei modelli di definizione seguenti generati dalla utility DEFGEN:

Le definizioni contenute nel modello devono essere identiche alle definizioni della tabella o delle tabelle specificate nella stessa istruzione TABLE o MAP.

La distinzione tra maiuscole e minuscole del nome del modello viene osservata quando il nome viene specificato nello stesso modo in cui viene memorizzato nel database. Assicurarsi che il nome del modello sia specificato allo stesso modo sia nella clausola DEF o TARGETDEF in questa istruzione TABLE o MAP, sia nel file dei parametri DEFGEN che ha creato il modello.

Esempio 1

In questo esempio viene illustrato un nome di modello senza distinzione tra maiuscole e minuscole.

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

Esempio 2

Questo esempio mostra un nome di modello con distinzione tra maiuscole e minuscole quando il database richiede virgolette per applicare la distinzione tra maiuscole e minuscole.

  TABLE acct.cust*, DEF "CustDef";

Esempio 3

Questo esempio mostra un caso in cui vengono utilizzati sia DEF che TARGETDEF.

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

SOLO ECCEZIONI

EXCEPTIONSONLY è valido per MAP.

Utilizzare EXCEPTIONSONLY in un'istruzione MAP delle eccezioni destinata alla gestione degli errori. L'istruzione MAP delle eccezioni deve seguire l'istruzione MAP per la quale si prevedono errori. L'istruzione MAP delle eccezioni viene eseguita solo se si verifica un errore per l'ultimo record elaborato nella precedente istruzione MAP normale.

Per utilizzare EXCEPTIONSONLY, utilizzare un'istruzione REPERROR con l'opzione EXCEPTION all'interno dell'istruzione MAP normale o alla radice del file dei parametri. Per ulteriori informazioni, vedere REPERROR. Nota: se si utilizza la funzione CDR (Conflict Detection and Resolution) di Oracle GoldenGate, non è necessario un REPERROR con EXCEPTION. CDR invia automaticamente tutte le operazioni che causano errori all'istruzione MAP delle eccezioni.

L'istruzione MAP delle eccezioni deve specificare la stessa tabella di origine dell'istruzione MAP normale, ma la tabella di destinazione nell'istruzione MAP delle eccezioni deve essere una tabella delle eccezioni.

Nota: per supportare i nomi degli oggetti con caratteri jolly, vedere "MAPEXCEPTION (exceptions_mapping)".

Sintassi

EXCEPTIONSONLY

EVENTACTIONS (<action>)

EVENTACTIONS è valido per TABLE e MAP. Alcune opzioni si applicano solo all'uno o all'altro parametro e sono indicate come tali nelle descrizioni.

Utilizzare EVENTACTIONS per fare in modo che il processo esegua un'azione definita in base a un record nello trail, noto come record evento, che si qualifica per una regola di filtro specifica. È possibile utilizzare questo sistema, noto come sistema di marcatori di eventi (o infrastruttura di marcatori di eventi) per personalizzare l'elaborazione in base agli eventi del database. Ad esempio, è possibile sospendere un processo per eseguire una trasformazione o le statistiche dei report. La funzione di indicatore di evento è supportata per la replica delle modifiche ai dati, ma non per i caricamenti iniziali.

Per attivare azioni che non richiedono l'applicazione di dati alle tabelle di destinazione, è possibile utilizzare il parametro Replicat TABLE con opzioni di filtro che supportano EVENTACTIONS. Per ulteriori informazioni, vedere "TABLE for Replicat".

Potrebbe essere necessario combinare due o più azioni per raggiungere i tuoi obiettivi. Quando vengono combinate più azioni, l'intera istruzione EVENTACTIONS viene analizzata prima e le opzioni specificate vengono eseguite in ordine di precedenza. L'elenco seguente mostra l'ordine di precedenza. Le azioni elencate prima di Process the record si verificano prima che il record venga scritto nel trail o applicato alla destinazione (a seconda del processo). Le azioni elencate dopo l'esecuzione di Process the record vengono eseguite dopo l'elaborazione del record.

Per evitare che il record evento venga elaborato in modo normale, utilizzare l'opzione IGNORE o DISCARD. Poiché IGNORE e DISCARD vengono valutati prima del record stesso, impediscono l'elaborazione del record. Senza queste opzioni, EVENTACTIONS per Extract scrive il record nel trail e EVENTACTIONS per Replicat applica tale operazione al database di destinazione.

Si dovrebbe tenere conto della possibilità che una transazione possa contenere due o più record che attivano un'azione evento. In tal caso, potrebbero esserci più esecuzioni di determinate specifiche EVENTACTIONS. Ad esempio, il verificarsi di due record qualificanti che attivano due azioni ROLLOVER successive causerà il riporto di Extract due volte, lasciando uno dei due file vuoti dei dati delle transazioni.

È inoltre necessario tenere presente che quando il parametro GETUPDATEBEFORES è attivo, vengono generati due record per le operazioni UPDATE: un record che contiene l'immagine precedente e un record che contiene l'immagine successiva. Un'azione evento viene attivata per ciascuno di tali record quando l'operazione è qualificata come record evento. È possibile utilizzare il token BEFOREAFTERINDICATOR della funzione di conversione colonna GGHEADER come filtro in una clausola FILTER per qualificare i record in modo che l'azione evento venga attivata una sola volta, sia nel record precedente che nel record successivo, ma non in entrambi.

L'esempio seguente filtra l'indicatore BEFORE. EVENTACTION invia il comando della shell ECHO per l'output della stringa 'Triggered on BEFORE' nel log degli eventi quando viene rilevato un record BEFORE.

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

Di seguito viene illustrato il risultato dell'evento <action>.

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

L'esempio seguente fa la stessa cosa, ma per l'indicatore AFTER.

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

Sintassi

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

Valido in TABLE per Extract e in MAP per Replicat.

Porta il processo a un arresto esteso quando viene rilevato il record evento specificato. Il processo attende il completamento di altre operazioni nella transazione evento prima dell'arresto. Se la transazione è una transazione raggruppata o in batch Replicat, il gruppo corrente di transazioni viene applicato prima che il processo si interrompa in modo esteso. Il processo viene riavviato al record successivo dopo il record evento, purché tale record indichi anche la fine di una transazione.

Il processo registra un messaggio se non è possibile interromperlo immediatamente perché una transazione è ancora aperta. Tuttavia, se il record evento viene rilevato in una transazione aperta con tempi di esecuzione lunghi, non viene visualizzato alcun messaggio di avvertenza che avvisa l'utente dello stato di non commit della transazione. Pertanto, il processo potrebbe rimanere in esecuzione per molto tempo nonostante l'evento STOP.

STOP può essere combinato con altre opzioni EVENTACTIONS, ad eccezione delle opzioni ABORT e FORCESTOP.

SUSPEND

Valido in TABLE per Extract e in MAP per Replicat.

Sospende il processo in modo che mantenga il contesto attivo dell'esecuzione corrente e possa comunque rispondere ai comandi SEND emessi nel client di amministrazione. Quando un processo viene sospeso, il comando INFO lo mostra come RUNNING e il campo RBA mostra l'ultima posizione del checkpoint.

Per riprendere l'elaborazione, eseguire il comando SEND con l'opzione RESUME.

Per utilizzare l'opzione CHECKPOINT BEFORE insieme a SUSPEND, il record evento deve essere l'inizio di una transazione per l'esecuzione di SUSPEND. In questo modo, se il processo viene interrotto mentre è in stato sospeso, il record evento con l'azione SUSPEND è il primo record da rielaborare al riavvio. Se vengono specificati sia CHECKPOINT BERORE che SUSPEND, ma il record evento non è l'inizio di una transazione, il processo viene interrotto prima che SUSPEND possa essere eseguito.

Per utilizzare l'opzione CHECKPOINT AFTER insieme a SUSPEND, è necessario eseguire il comando RESUME prima di poter eseguire il checkpoint e il record evento deve essere un record COMMIT. Se il processo viene interrotto mentre si trova in uno stato SUSPEND, il processo rielabora la transazione dall'ultima posizione di checkpoint al riavvio.

SUSPEND non può essere combinato con ABORT, ma può essere combinato con tutte le altre opzioni.

ABORT

Valido in TABLE per Extract e in MAP per Replicat.

Forza l'uscita immediata del processo quando viene rilevato il record evento specificato, indipendentemente dal fatto che siano presenti o meno transazioni aperte. Il record evento non è stato elaborato. Viene scritto un errore irreversibile nel log e il record dell'evento viene scritto nel file di scarto se viene specificato anche DISCARD. Il processo sarà sottoposto a recupero all'avvio.

ABORT può essere combinato solo con CHECKPOINT BEFORE, DISCARD, SHELL e REPORT.

FORCESTOP

Valido in TABLE per Extract e in MAP per Replicat.

Forza l'arresto esteso del processo quando viene rilevato il record evento specificato, ma solo se il record evento è l'ultima operazione della transazione o l'unico record della transazione. Il disco è scritto normalmente.

Se il record evento viene rilevato in una transazione aperta con tempi di esecuzione lunghi, il processo scrive un messaggio di avvertenza nel log e esce immediatamente, come in ABORT. In questo caso, potrebbe essere necessario il recupero all'avvio. Se l'azione FORCESTOP viene attivata durante una transazione con tempi di esecuzione lunghi, il processo viene chiuso senza un messaggio di avvertenza.

FORCESTOP può essere combinato con altre opzioni EVENTACTIONS, ad eccezione di ABORT, STOP, CHECKPOINT AFTER e CHECKPOINT BOTH. Se utilizzato con ROLLOVER, il rinnovo si verifica solo se il processo si arresta in modo normale.

IGNORE [RECORD TRANSACTION [INCLUDEVENT]]

Valido in TABLE per Extract e in MAP per Replicat.

Ignora parte o tutta la transazione, a seconda dell'azione selezionata.

IGNORE può essere combinato con tutte le altre opzioni EVENTACTIONS ad eccezione delle opzioni ABORT e DISCARD.

Un'azione IGNORE viene elaborata dopo l'elaborazione di tutte le operazioni di qualifica, filtro, mapping e uscita utente. Il record o la transazione viene ignorato nella fase di output finale e impedisce la scrittura del record o della transazione nella destinazione di output (il trail nel caso di Extract o il database nel caso di Replicat). Pertanto, in alcune espressioni, ad esempio quelle che includono operazioni SQLEXEC, SQLEXEC verrà eseguito prima dell'elaborazione di IGNORE. Ciò significa che, mentre il record non viene scritto nel trail o nel database di destinazione, si verificheranno tutti gli effetti dell'elaborazione del record tramite qualifica, filtro, mapping e uscita utente.

Azione non valida per i record DDL. Poiché le operazioni DDL sono autonome, ignorare un record equivale a ignorare l'intera transazione.

DISCARD

Valido in TABLE per Extract e in MAP per Replicat.

Causa il processo di:

Il processo riprende l'elaborazione con il record successivo nel trail.

DISCARD può essere combinato con tutte le altre opzioni EVENTACTIONS ad eccezione di IGNORE.

LOG [INFO WARNING]

Valido in TABLE per Extract e in MAP per Replicat.

Causa al processo di registrare l'evento quando viene rilevato il record evento specificato. Il messaggio viene scritto nel file di report, nel log degli errori di Oracle GoldenGate e nel log degli eventi di sistema.

Utilizzare le seguenti opzioni per specificare la severità del messaggio:

LOG può essere combinato con tutte le altre opzioni EVENTACTIONS ad eccezione di ABORT. Se si utilizza ABORT, LOG non è necessario perché ABORT registra un errore irreversibile prima della chiusura del processo.

REPORT

Valido in TABLE per Extract e in MAP per Replicat.

Causa al processo di generare un file di report quando viene rilevato il record evento specificato. Questo equivale all'utilizzo del comando SEND con l'opzione REPORT in GGSCI.

Il messaggio REPORT si verifica dopo l'elaborazione del record evento (a meno che non vengano utilizzati DISCARD, IGNORE o ABORT), pertanto i dati del report includeranno il record evento.

REPORT può essere combinato con tutte le altre opzioni EVENTACTIONS.

ROLLOVER

Valido in TABLE per Extract.

Fa in modo che Extract esegua il riporto a un nuovo file quando viene rilevato il record evento specificato. L'azione ROLLOVER si verifica prima che Extract scriva il record evento nel file trail, il che fa sì che il record sia il primo nel nuovo file a meno che non vengano utilizzati anche DISCARD, IGNORE o ABORT.

ROLLOVER può essere combinato con tutte le altre opzioni EVENTACTIONS ad eccezione di ABORT. ROLLOVER non può essere combinato con ABORT perché ROLLOVER non causa la scrittura di un checkpoint da parte del processo e ROLLOVER viene eseguito prima di ABORT.

Senza un checkpoint ROLLOVER, ABORT fa sì che Extract passi al checkpoint precedente al riavvio, che si troverebbe nel file trail precedente. In effetti, questo annulla il rinnovo.

SHELL '<command>'

Valido in TABLE per Extract e in MAP per Replicat.

Causa al processo di eseguire il comando shell specificato quando viene rilevato il record evento. SHELL '<command'> esegue un comando shell di base. La stringa di comando viene presa al suo valore letterale e inviata al sistema in questo modo. Per il comando viene fatta distinzione tra maiuscole e minuscole. Racchiudere la stringa di comando tra apici, ad esempio:

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

Se il comando shell riesce, il processo scrive un messaggio informativo nel file di report e nel log degli eventi. L'operazione riuscita si basa sullo stato di uscita del comando in conformità alla lingua della shell UNIX. In questa lingua, zero indica il successo.

Se la chiamata di sistema non riesce, il processo viene interrotto con un errore irreversibile. Nella lingua della shell UNIX, il valore diverso da zero equivale a un errore. Si noti che il messaggio di errore si riferisce solo all'esecuzione del comando SHELL stesso e non allo stato di uscita di qualsiasi comando subordinato. Ad esempio, SHELL può eseguire uno script correttamente, ma i comandi in tale script potrebbero non riuscire.

SHELL può essere combinato con tutte le altre opzioni EVENTACTIONS.

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

Valido in TABLE per Extract e in MAP per Replicat.

Causa al processo di eseguire il comando shell specificato quando viene rilevato il record evento e supporta il passaggio dei parametri. Il comando e i parametri sono sensibili alla distinzione tra maiuscole e minuscole.

Quando si utilizza SHELL con argomenti, l'intera stringa <command> e quella degli argomenti devono essere racchiuse tra parentesi, ad esempio:

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

L'input è il seguente:

<command>

È il comando, che viene trasmesso letteralmente al sistema.

VAR

Parola chiave obbligatoria che avvia l'input del parametro.

<variable>

È il nome definito dall'utente della variabile segnaposto in cui verrà sostituito il valore della variabile runtime. Le variabili extra non utilizzate nel comando vengono ignorate. Si noti che qualsiasi valore del comando SHELL corrispondente a un nome di variabile VAR viene sostituito dal valore VAR sostituito. Questo può avere conseguenze indesiderate, quindi prova il tuo codice prima di metterlo in produzione.

<column_name>

Può essere l'immagine precedente o successiva (corrente) di un valore di colonna.

<expression>

può essere il seguente, a seconda che i dati della colonna o DDL siano gestiti.

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

Valido in TABLE per Extract e in MAP per Replicat.

Fa in modo che le informazioni di trace del processo vengano scritte in un file di trace quando viene rilevato il record evento specificato. TRACE fornisce informazioni dettagliate sull'elaborazione. TRACE2 identifica i segmenti di codice in cui il processo sta spendendo più tempo.

Per impostazione predefinita (senza opzioni), il trace DML standard senza linee guida sui limiti delle transazioni viene abilitato fino alla fine del processo.

TRACE può essere combinato con tutte le altre opzioni EVENTACTIONS ad eccezione di ABORT.

Per disabilitare il trace nel file di trace specificato, eseguire il comando del processo SEND GGSCI con l'opzione TRACE OFF <file_name>.

CHECKPOINT [BEFORE AFTER BOTH]

Valido in TABLE per Extract e in MAP per Replicat.

Fa in modo che il processo scriva un checkpoint quando viene rilevato il record evento specificato. Le azioni di checkpoint forniscono un contesto relativo all'elaborazione definita nelle istruzioni TABLE o MAP. Questo contesto ha un punto iniziale e un punto finale, fornendo così punti di sincronizzazione per il mapping delle funzioni eseguite con SQLEXEC e le uscite utente.

BEFORE

BEFORE per un processo Extract scrive un checkpoint prima che Extract scriva il record evento nel trail. BEFORE per un processo Replicat scrive un checkpoint prima che Replicat applichi l'operazione SQL contenuta nel record alla destinazione.

BEFORE richiede che il record evento sia il primo record di una transazione. Se non è il primo record, il processo verrà interrotto. Utilizzare BEFORE per assicurarsi che venga eseguito il commit di tutte le transazioni precedenti a quella che inizia con il record evento.

Quando si utilizza EVENTACTIONS per un record DDL, si noti che poiché ogni record DDL è autonomo, il record DDL è garantito come inizio di una transazione; pertanto, l'azione evento CHECKPOINT BEFORE è implicita per un record DDL.

CHECKPOINT BEFORE può essere combinato con tutte le opzioni EVENTACTIONS.

AFTER

AFTER per Extract scrive un checkpoint dopo che Extract scrive il record evento nel trail. AFTER per Replicat scrive un checkpoint dopo che Replicat applica l'operazione SQL contenuta nel record alla destinazione.

AFTER contrassegna la richiesta di checkpoint come advisory, il che significa che il processo emetterà un checkpoint solo alla successiva opportunità pratica. Ad esempio, nel caso in cui il record evento faccia parte di una transazione con più record, il checkpoint verrà eseguito al limite successivo della transazione, in conformità al modello di integrità dei dati di Oracle GoldenGate.

Quando si utilizza EVENTACTIONS per un record DDL, si noti che poiché ogni record DDL è autonomo, il record DDL è garantito come fine (limite) di una transazione; pertanto, l'azione evento CHECKPOINT AFTER è implicita per un record DDL.

CHECKPOINT AFTER può essere combinato con tutte le opzioni EVENTACTIONS ad eccezione di ABORT.

BOTH

BOTH combina BEFORE e AFTER. Il processo Extract o Replicat scrive un checkpoint prima e dopo l'elaborazione del record evento.

CHECKPOINT BOTH può essere combinato con tutte le opzioni EVENTACTIONS ad eccezione di ABORT.

CHECKPOINT può essere abbreviato in CP.

Esempio 1

L'esempio seguente mostra come configurare un processo per ignorare determinati record. Quando Extract elabora qualsiasi record trail con name = abc, ignora il record.

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

Esempio 2

In base alle regole di compatibilità e precedenza delle opzioni EVENTACTIONS, DISCARD ha la precedenza maggiore di ABORT, quindi in questo esempio il record evento viene scritto nel file degli oggetti eliminati prima dell'interruzione del processo.

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

Esempio 3

Nell'esempio seguente viene eseguita un'azione SHELL. Ottiene il risultato di una query SQLEXEC e la associa all'indicatore orario corrente.

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));

La shell <command> che restituisce questo esempio potrebbe essere simile alla seguente:

'Current timestamp: 212156002704718000  SQLEXEC result is test passed'

Esempio 4

L'esempio seguente mostra come possono verificarsi risultati non validi se un nome segnaposto è in conflitto con il testo letterale nella stringa di comando. In questo esempio, un segnaposto denominato $1 è associato a un valore di colonna e il comando SHELL fa eco a una stringa letterale che include $1.

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

Questo è il risultato non previsto, supponendo che il valore <column> sia gift wrap:

'Extra charge for gift wrap is gift wrap'

La modifica del segnaposto <variable> in $col determina l'output corretto:

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'

Quanto segue mostra un potenziale simile per risultati non previsti:

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

L'output reindirizzato <file> potrebbe contenere un <string> simile a questo (si noti che il secondo indicatore orario contiene un valore aggiunto di 3):

'Timestamp: 212156002704718000 Price is 2121560027047180003'

Il risultato previsto è:

'Timestamp: 212156002704718000 Price is $13'

Esempio 5

Questi esempi mostrano diversi modi per configurare il trace.

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

Esempio 6

Di seguito viene illustrato come utilizzare EVENTACTIONS con SUSPEND.

EXITPARAM '<parameter>'

EXITPARAM è valido per TABLE e MAP.

Utilizzare EXITPARAM per passare un parametro alla funzione EXIT_PARAMS di una routine user exit ogni volta che viene rilevato un record dell'istruzione TABLE o MAP.

Sintassi

EXITPARAM '<parameter string>'

<'parameter string'>

Parametro che è una stringa letterale. Racchiudere il parametro tra apici. È possibile specificare fino a 100 caratteri per la stringa del parametro.

RECUPERA PRIMA DEL FILTRO

FETCHBEFOREFILTER è valido per TABLE.

Utilizzare FETCHBEFOREFILTER per recuperare le colonne specificate con FETCHCOLS o FETCHCOLSEXCEPT prima di eseguire un'operazione FILTER. Il recupero prima del filtro garantisce la disponibilità dei valori richiesti per il filtro. Senza FETCHBEFOREFILTER, i fetch specificati con FETCHCOLS o FETCHCOLSEXCEPT non vengono eseguiti prima dell'esecuzione dei filtri. Specificare FETCHBEFOREFILTER prima di FILTER nel file dei parametri.

Non utilizzare questa opzione per le tabelle elaborate in modalità pass-through da un gruppo Extract di Data Pump.

Sintassi

FETCHBEFOREFILTER

Esempio

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

{FETCHCOLS | FETCHCOLSEXCEPT} (<column_list>)

FETCHCOLS e FETCHCOLSEXCEPT sono validi per TABLE. Queste opzioni sono valide solo per l'estrazione principale.

Utilizzare FETCHCOLS e FETCHCOLSEXCEPT per recuperare i valori delle colonne dal database quando i valori non sono presenti nel record di log delle transazioni. Utilizzare questa opzione se il database registra solo i valori delle colonne modificate in un'operazione di aggiornamento, ma è necessario assicurarsi che siano disponibili altri valori di colonna necessari per le operazioni FILTER.

FETCHCOLS e FETCHCOLSEXCEPT sono validi per tutti i database supportati da Oracle GoldenGate.

Per un Oracle AI Database, Oracle GoldenGate recupera i valori dalla tablespace di undo tramite il meccanismo Flashback Query di Oracle. La query fornisce un'immagine coerente in lettura delle colonne a partire da un'ora specifica o da un SCN. Per ulteriori informazioni sull'utilizzo della query Flashback da parte di Oracle GoldenGate.

Anziché utilizzare FETCHCOLS o FETCHCOLSEXCEPT, potrebbe essere più efficiente abilitare la registrazione supplementare per le colonne desiderate.

Per controllare il recupero e abilitare una risposta quando non è possibile individuare una colonna specificata per il recupero, utilizzare il parametro FETCHOPTIONS. Per includere i risultati del recupero nelle visualizzazioni statistiche generate dal comando STATS EXTRACT, utilizzare il parametro STATOPTIONS.

Se nel log delle transazioni sono presenti valori per le colonne specificate con FETCHCOLS o FETCHCOLSEXCEPT, non viene eseguito alcun recupero del database. Ciò riduce il sovraccarico del database.

Sintassi

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

<column>

Può essere uno dei nomi riportati di seguito.

Esempio

La clausola FETCHCOLS in questo esempio recupera solo le colonne 1 e 3, mentre la clausola FETCHCOLSEXCEPT recupera tutte le colonne tranne le colonne 1 e 3.

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

{FETCHMODCOLS | FETCHMODCOLSEXCEPT} (<column_list>)

FETCHMODCOLS e FETCHMODCOLSEXCEPT sono validi per TABLE. Queste opzioni sono valide solo per l'estrazione principale.

Utilizzare FETCHMODCOLS e FETCHMODCOLSEXCEPT per forzare il recupero dei valori di colonna dal database anche se le colonne sono presenti nel log delle transazioni. A seconda del tipo di database, un record di log può contenere tutte le colonne di una tabella o solo le colonne modificate nell'operazione di transazione specificata.

FETCHMODCOLS e FETCHMODCOLSEXCEPT sono validi per tutti i database supportati da Oracle GoldenGate.

Osservare le istruzioni d'uso riportate di seguito.

Sintassi

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

(<column> [, ...])

Può essere uno dei nomi riportati di seguito.

Esempio

La clausola FETCHMODCOLS in questo esempio recupera solo le colonne 1 e 3, mentre la clausola FETCHMODCOLSEXCEPT recupera tutte le colonne tranne le colonne 1 e 3.

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

FILTER (<filter_clause>)

FILTER è valido per TABLE e MAP.

Utilizzare FILTER per selezionare o escludere i record in base a un valore numerico. Un'espressione di filtro può utilizzare operatori condizionali, funzioni di conversione delle colonne di Oracle GoldenGate o entrambe. Nota: per filtrare in base a una stringa, utilizzare una delle funzioni stringa di Oracle GoldenGate. Per ulteriori informazioni su queste funzioni, vedere "Funzioni di mapping di tabelle e colonne". È anche possibile utilizzare l'opzione WHERE. Vedere "WHERE (clausola)".

Separare tutti i componenti di FILTER con una virgola. Una clausola FILTER può includere quanto segue:

Racchiudere i valori letterali tra apici. Specificare i nomi delle colonne con distinzione tra maiuscole e minuscole mentre vengono memorizzati nel database e racchiuderli tra virgolette se il database richiede virgolette per applicare la distinzione tra maiuscole e minuscole (ad esempio, Oracle).

Oracle GoldenGate supporta FILTER per le colonne con un set di caratteri a più byte.

Sintassi

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

<filter_clause>

Seleziona i record in base a un valore <expression>, ad esempio:

FILTER ((PRODUCT_PRICE*PRODUCT_AMOUNT) > 10000))

È possibile utilizzare le funzioni di conversione delle colonne di Oracle GoldenGate in un filtro <clause>, come descritto di seguito.

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

Racchiudere i valori letterali tra apici. Specificare i nomi di colonna con distinzione tra maiuscole e minuscole mentre vengono memorizzati nel database e racchiuderli tra virgolette se il database richiede virgolette per applicare la distinzione tra maiuscole e minuscole (ad esempio, Oracle).

Oracle GoldenGate non supporta FILTER per le colonne con un set di caratteri a più byte o un set di caratteri incompatibile con il set di caratteri del sistema operativo locale.

La dimensione massima della clausola di filtro è di 5.000 byte.

ON INSERT ON UPDATE ON DELETE

Limita il filtro dei record alle operazioni specificate. Separare le operazioni con virgole, ad esempio:

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

Nell'esempio precedente viene eseguito il filtro per le operazioni UPDATE e DELETE, ma non per le operazioni INSERT.

IGNORE INSERT IGNORE UPDATE IGNORE DELETE

Non applica il filtro per l'operazione o le operazioni specificate. Separare le operazioni con virgole, ad esempio:

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

Nell'esempio precedente il filtro viene eseguito sulle operazioni UPDATE e DELETE, ma le operazioni INSERT vengono ignorate.

RAISEERROR <error>

Genera un numero di errore definito dall'utente se il filtro non riesce. Può essere utilizzato come input per il parametro REPERROR per richiamare la gestione degli errori. Assicurarsi che il valore di <error> non sia compreso nell'intervallo di numeri di errore utilizzato dal database o da Oracle GoldenGate. Ad esempio: RAISEERROR 21000.

GETBEFORECOLS (<column_specification>)

GETBEFORECOLS è valido per TABLE.

Utilizzare GETBEFORECOLS per specificare le colonne per le quali si desidera acquisire e scrivere l'immagine nel trail durante un'operazione di aggiornamento o eliminazione. Utilizzare GETBEFORECOLS quando si utilizza la funzione CDR (Conflict Detection and Resolution) di Oracle GoldenGate in una configurazione bidirezionale o multi-master. Utilizzarlo anche quando si utilizzano funzioni di conversione o altre funzioni di elaborazione che richiedono l'immagine precedente di un record.

Per gli aggiornamenti, l'immagine precedente delle colonne specificate viene inclusa nel trail indipendentemente dalla modifica di una determinata colonna. Oltre alle colonne specificate nella clausola GETBEFORECOLS, un Oracle AI Database registrerà anche l'immagine precedente di altre colonne modificate. Per altri database supportati, è possibile utilizzare il parametro GETUPDATEBEFORES per forzare l'inclusione dei valori precedenti di altre colonne modificate.

Nota: GETUPDATEBEFORES sostituisce GETBEFORECOLS se entrambi vengono utilizzati nello stesso file di parametri.

Per utilizzare questo parametro, è necessario abilitare il log supplementare per qualsiasi database che non registra prima dei valori per impostazione predefinita.

GETBEFORECOLS sostituisce COMPRESSUPDATES e COMPRESSDELETES se utilizzati nello stesso file dei parametri.

Questo parametro è valido per tutti i database ad eccezione di Db2 z/OS. Per Db2 z/OS su tutte le piattaforme supportate da Oracle GoldenGate, utilizzare il parametro GETUPDATEBEFORES anziché GETBEFORECOLS.

Sintassi

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

Specifica se l'immagine precedente delle colonne specificate deve essere acquisita per aggiornamenti o eliminazioni. È possibile utilizzare solo ON UPDATE, solo ON DELETE o entrambi. Se si utilizzano entrambi, specificarli all'interno della stessa clausola GETBEFORECOLS. Per informazioni sull'utilizzo di entrambi, vedere l'esempio.

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

Specifica le colonne per le quali viene acquisita un'immagine precedente.

ALL

Acquisisce un'immagine precedente di tutte le colonne di tipo dati supportate nella tabella di destinazione, inclusa la chiave primaria; tutte le colonne non supportate vengono saltate e registrate nel file dei parametri Extract o Replicat come messaggio informativo. Ciò impone il carico di elaborazione più elevato per Extract, ma consente di eseguire confronti di rilevamento dei conflitti utilizzando tutte le colonne per la massima precisione.

KEY

Acquisisci prima dell'immagine solo per la chiave primaria. Questa è l'opzione più veloce, ma non consente il rilevamento dei conflitti più accurato, perché le chiavi possono corrispondere, ma le colonne non chiave potrebbero essere diverse. KEY è l'impostazione predefinita.

KEYINCLUDING

Acquisisci prima dell'immagine della chiave primaria e anche la colonna o le colonne specificate. Si tratta di un compromesso ragionevole tra velocità e precisione di rilevamento.

KEYANDMOD

Utilizzare questa opzione come estensione dell'opzione chiave sia per Extract che per Replicat. Per aggiornare i DML nell'origine, Extract registra la chiave e le colonne modificate. Replicat sulla destinazione utilizzerà le colonne KEY e MODIFIED durante il rilevamento dei conflitti in una clausola WHERE. Con i database Oracle AI, la colonna modificata viene sempre utilizzata per il rilevamento dei conflitti per impostazione predefinita e questo parametro lo rende esplicito.

ALLEXCLUDING

Acquisisci prima dell'immagine di tutte le colonne tranne quelle specificate. Per le tabelle con numerose colonne, ALLEXCLUDING può essere più efficiente di KEYINCLUDING. Non escludere le colonne chiave.

Esempio

Nell'esempio seguente, le immagini precedenti per le colonne chiave più name, address e salary vengono sempre scritte nel file trail durante le operazioni di aggiornamento ed eliminazione.

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

HANDLECOLLISIONS | NOHANDLECOLLISIONS

HANDLECOLLISIONS e NOHANDLECOLLISIONS sono validi per MAP.

Utilizzare HANDLECOLLISIONS e NOHANDLECOLLISIONS per controllare se Oracle GoldenGate riconcilia i risultati di un caricamento iniziale con le modifiche transazionali replicate apportate alle stesse tabelle. Quando Oracle GoldenGate applica le modifiche replicate al termine del caricamento, HANDLECOLLISIONS fa in modo che Replicat sovrascriva i record duplicati nelle tabelle di destinazione e fornisce una gestione alternativa degli errori per i record mancanti.

HANDLECOLLISIONS e NOHANDLECOLLISIONS possono essere utilizzati globalmente per tutte le istruzioni MAP nel file dei parametri o come switch ON/OFF per i gruppi di tabelle specificati con le istruzioni MAP e possono essere utilizzati all'interno di un'istruzione MAP. Se utilizzati in un'istruzione MAP, sostituiscono le specifiche globali.

Per la sintassi e l'uso, vedere "HANDLECOLLISIONS | NOHANDLECOLLISIONS".

INSERISCI RECORD

INSERTALLRECORDS è valido per MAP.

Utilizzare il parametro INSERTALLRECORDS per convertire tutte le operazioni mappate in operazioni INSERT sulla destinazione. INSERTALLRECORDS può essere utilizzato al livello radice del file dei parametri, all'interno di un'istruzione MAP e all'interno di una clausola MAPEXCEPTION di un'istruzione MAP.

Per la sintassi e l'uso, vedere "INSERTALLRECORDS".

INSERTAPPEND | NOINSERTAPPEND

INSERTAPPEND è valido per MAP.

Utilizzare i parametri INSERTAPPEND e NOINSERTAPPEND per controllare se Replicat utilizza o meno un suggerimento APPEND quando applica le operazioni INSERT alle tabelle di destinazione Oracle. Questi parametri sono validi solo per i database Oracle.

Per la sintassi e l'uso, vedere "INSERTAPPEND | NOINSERTAPPEND".

KEYCOLS (<columns>)

KEYCOLS è valido per TABLE e MAP.

Utilizzare KEYCOLS per definire una o più colonne della tabella di destinazione come univoche. L'uso principale di KEYCOLS consiste nel definire una chiave primaria sostitutiva quando non è disponibile una chiave primaria o un indice univoco appropriato per la tabella. È inoltre possibile utilizzare KEYCOLS per specificare colonne aggiuntive da utilizzare nell'identificativo di riga utilizzato da Replicat. Senza la disponibilità di una chiave o di una clausola KEYCOLS, Replicat utilizza tutte le colonne della tabella per creare la clausola WHERE, eseguendo essenzialmente una scansione completa della tabella.

Le colonne di una chiave visualizzata da KEYCOLS devono identificare in modo univoco una riga e devono corrispondere alle colonne utilizzate come chiave nella tabella di origine. La tabella di origine deve contenere almeno il numero di colonne chiave o indice specificato per la tabella di destinazione dalla chiave KEYCOLS. In caso contrario, in caso di aggiornamento alla chiave di origine o alle colonne di indice, Replicat non avrà le immagini precedenti per le colonne KEYCOL di destinazione aggiuntive.

Durante la definizione di una chiave sostitutiva con KEYCOLS, osservare le linee guida riportate di seguito.

Quando si utilizza KEYCOLS, assicurarsi che le colonne specificate siano configurate per il log in modo che siano disponibili per Replicat nei record trail. Per un database Oracle AI, è possibile abilitare il log utilizzando l'opzione COLS del comando ADD TRANDATA.

Nelle tabelle di destinazione creare un indice univoco nelle colonne chiave definite da KEYCOLS. Un indice migliora la velocità con cui Oracle GoldenGate individua le righe di destinazione che deve elaborare.

Non utilizzare KEYCOLS per le tabelle elaborate in modalità pass-through da un gruppo Extract di Data Pump.

Ulteriori linee guida per KEYCOLS quando si utilizza Parallel Replicat o Integrated Replicat:

Sintassi

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

<column>

Definisce una colonna da utilizzare come chiave primaria sostitutiva. Se esiste una chiave primaria o univoca, tali colonne devono essere incluse nella specifica KEYCOLS. Per specificare più colonne, creare un elenco delimitato da virgole come descritto di seguito.

KEYCOLS (id, name)

I seguenti tipi di colonna non sono supportati in KEYCOLS:

Esempio

KEYCOLS

MAPEXCEPTION (<exceptions_mapping>)

MAPEXCEPTIONS è valido per MAP.

Utilizzare MAPEXCEPTION come parte di un'istruzione MAP delle eccezioni destinata alla gestione degli errori. MAPEXCEPTION esegue il mapping di operazioni non riuscite contrassegnate come eccezioni dal parametro REPERROR a una tabella delle eccezioni. Replicat scrive i valori di queste operazioni insieme ad altre informazioni nella tabella delle eccezioni.

È possibile utilizzare MAPEXCEPTION all'interno della stessa istruzione MAP che include il mapping delle tabelle di destinazione di origine e altre opzioni MAP standard. I nomi delle tabelle di origine e di destinazione possono includere caratteri jolly.

Quando si utilizza MAPEXCEPTION, utilizzare un'istruzione REPERROR con l'opzione EXCEPTION all'interno della stessa istruzione MAP o alla radice del file dei parametri Replicat. Vedere "EXCEPTIONSONLY" e "REPERROR".

Sintassi

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

TARGET <exceptions_table>

Nome completamente qualificato della tabella delle eccezioni. Le regole standard di Oracle GoldenGate per i nomi degli oggetti si applicano al nome della tabella delle eccezioni.

<exception_MAP_options>

Qualsiasi opzione valida del parametro MAP che si desidera applicare alla gestione delle eccezioni.

INSERTALLRECORDS

Applica tutte le eccezioni alla tabella delle eccezioni come operazioni INSERT. Questo parametro è obbligatorio quando si utilizza MAPEXCEPTION.

Esempio

Questo è un esempio di come utilizzare MAPEXCEPTION per il mapping delle eccezioni. Le clausole MAP e TARGET contengono i nomi delle tabelle di origine e di destinazione dei caratteri jolly. Le eccezioni che si verificano durante l'elaborazione di qualsiasi tabella con un nome che inizia con TRX verranno acquisite nella tabella fin.trxexceptions utilizzando il mapping specificato.

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')
)
);

MAPALLCOLUMNS | NOMAPALLCOLUMNS

MAPALLCOLUMNS e NOMAPALLCOLUMNS sono validi per MAP.

Utilizzare MAPALLCOLUMNS per ottenere colonne non mappate (non chiave). Quando si specifica questa opzione, Extract o Replicat controlla se tutte le colonne di origine sono mappate direttamente alla destinazione senza la funzione di mapping delle colonne. Se non viene eseguito il mapping di alcuna colonna di origine, l'estrazione e/o il Replicat vengono interrotti.

Vedere "MAPALLCOLUMNS| NOMAPALLCOLUMNS".

MAPPAINVISIBLECOLONNE | NOMAPINVISIBLECOLONNE

MAPINVISIBLECOLUMNS e NOMAPINVISIBLECOLUMNS sono validi per MAP.

Utilizzare MAPINVISIBLECOLUMNS e NOMAPINVISIBLECOLUMNS per controllare se Replicat include o meno colonne invisibili nelle tabelle di destinazione Oracle per il mapping di colonne predefinito. Per le colonne invisibili nelle tabelle di destinazione Oracle che utilizzano il mapping di colonne esplicito, vengono sempre mappate, pertanto non è necessaria questa opzione.

MAPINVISIBLECOLUMNS e NOMAPINVISIBLECOLUMNS possono essere utilizzati in due modi diversi. Se specificato a livello globale, un parametro rimane attivo per tutte le istruzioni MAP successive fino a quando non viene specificato l'altro parametro. Se utilizzati in un'istruzione MAP, sostituiscono le specifiche globali

Per la sintassi e l'uso, vedere "MAPINVISIBLECOLUMNS | NOMAPINVISIBLECOLUMNS".

REPERROR (<error>,<response>)

REPERROR è valido per MAP.

Utilizzare REPERROR per specificare un errore e una risposta che insieme controllano il modo in cui Replicat risponde all'errore durante l'esecuzione dell'istruzione MAP. È possibile utilizzare REPERROR a livello MAP per sostituire e integrare le regole di gestione degli errori globali impostate con il parametro REPERROR a livello radice del file dei parametri. È possibile applicare più istruzioni REPERROR alla stessa istruzione MAP per consentire la gestione automatica e completa degli errori e l'elaborazione della replica senza interruzioni.

Per la sintassi e le descrizioni, vedere "REPERROR".

RESOLVECONFLICT (<conflict_resolution_specification>)

RESOLVECONFLICT è valido per MAP.

Utilizzare RESOLVECONFLICT in una configurazione bidirezionale o multimaster per specificare il modo in cui Replicat gestisce i conflitti sulle operazioni eseguite sulle tabelle nell'istruzione MAP.

È possibile specificare più risoluzioni per lo stesso tipo di conflitto e vengono eseguite nell'ordine elencato in RESOLVECONFLICT. Le risoluzioni multiple sono limitate solo a conflitti INSERTROWEXISTS e UPDATEROWEXISTS.

RESOLVECONFLICT può essere utilizzato più volte in un'istruzione MAP per specificare risoluzioni diverse per tipi di conflitto diversi.

Di seguito sono riportati i tipi di dati e le piattaforme supportate da RESOLVECONFLICT.

Sintassi

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  

Il tipo di conflitto gestito dalla risoluzione.

INSERTROWEXISTS

Una riga inserita viola un vincolo di univocità nella destinazione.

UPDATEROWEXISTS

Nella destinazione esiste una riga aggiornata, ma una o più colonne hanno un'immagine precedente nel trail diversa dal valore corrente nel database.

UPDATEROWMISSING

Una riga aggiornata non esiste nella destinazione.

DELETEROWEXISTS

Nella destinazione esiste una riga eliminata, ma una o più colonne hanno un'immagine precedente nel trail diversa dal valore corrente nel database.

DELETEROWMISSING

Una riga eliminata non esiste nella destinazione.

DEFAULT | <resolution_name>

DEFAULT

Gruppo di colonne predefinito. La risoluzione associata al gruppo di colonne DEFAULT viene utilizzata per tutte le colonne che non si trovano in un gruppo di colonne denominato in modo esplicito. Definire un gruppo di colonne DEFAULT.

<resolution_name>

Nome di un gruppo di colonne specifico collegato a un tipo di risoluzione specifico. Fornire un nome che identifichi il tipo di risoluzione. I valori validi sono caratteri alfanumerici. Evitare spazi e caratteri speciali, ma i caratteri di sottolineatura sono consentiti, ad esempio:

delta_res_method

Utilizzare una risoluzione denominata o DEFAULT, ma non entrambi.

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

La logica di gestione dei conflitti utilizzata per risolvere il conflitto. Le risoluzioni valide sono:

USEMAX

Se il valore di <resolution_column> nel record trail è maggiore del valore della colonna nel database, viene eseguita l'azione appropriata.

USEMAXEQ

Se il valore di <resolution_column> nel record trail è maggiore o uguale al valore della colonna nel database, viene eseguita l'azione appropriata.

USEMIN

Se il valore di <resolution_column> nel record trail è inferiore al valore di <column> nel database, viene eseguito il valore <action> appropriato:

USEMINEQ

Se il valore di <resolution_column> nel record trail è minore o uguale al valore di <column> nel database, viene eseguito il valore <action> appropriato:

<resolution_column>

Nome di una colonna NOT NULL che funge da colonna di risoluzione. Questa colonna deve far parte del gruppo di colonne associato a questa risoluzione. Il valore della colonna di risoluzione rispetto al valore corrente nel database di destinazione determina la modalità di applicazione di una risoluzione. L'immagine successiva della colonna di risoluzione viene utilizzata per il confronto, se disponibile; in caso contrario, viene utilizzato il valore dell'immagine precedente. Utilizzare una colonna che può essere confrontata tramite SQL semplice:

Per utilizzare una risoluzione dell'indicatore orario più recente, utilizzare una colonna dell'indicatore orario come <resolution_column> e impostare la colonna dell'indicatore orario sull'ora corrente in cui viene inserita o aggiornata una riga. Se possibile, definire la colonna di risoluzione con il tipo di dati SYSTIMESTAMP, che supporta i secondi frazionari. Quando i confronti vengono eseguiti con una granularità inferiore al secondo, non c'è bisogno di gestori di conflitti che risolvano i casi in cui il valore della colonna di risoluzione sia identico sia nel trail che nel target. Se si garantisce che il valore della colonna indicatore orario possa solo aumentare o diminuire (a seconda della risoluzione), USEMAX e USEMIN non causano divergenze tra i dati.

Nota:

Non utilizzare una colonna chiave primaria come colonna di risoluzione in un'istruzione USEMAX per il conflitto UPDATEROWEXISTS. In caso contrario, Replicat viene interrotto con un errore simile al seguente:

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

USEDELTA

(Solo conflitto UPDATEROWEXISTS) Aggiungere la differenza tra i valori prima e dopo nel record trail al valore corrente della colonna nel database di destinazione. Se uno qualsiasi dei valori è NULL, viene generato un errore. Basare USEDELTA su colonne che contengono tipi di dati NUMERIC. USEDELTA è utile in una configurazione a più nodi quando una riga viene aggiornata contemporaneamente su più nodi. Propaga solo la differenza nei valori delle colonne agli altri nodi, in modo che tutti i nodi vengano sincronizzati.

DISCARD

(Valido per tutti i tipi di conflitto) Conservare il valore corrente nel database di destinazione e scrivere i dati nel record trail nel file di scarto.

Usare DISCARD con cautela perché può causare divergenze tra i dati.

OVERWRITE

(Valido per tutti i tipi di conflitto tranne DELETEROWMISSING) Applicare il record trail come indicato di seguito.

Usare OVERWRITE con cautela perché può causare divergenze tra i dati.

IGNORE

(Valido per tutti i tipi di conflitto) Conservare il valore corrente nel database di destinazione e ignorare il record trail: non applicare alla tabella di destinazione o a un file eliminato.

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

Gruppo di colonne non predefinito. Questa è una lista di colonne nel database di destinazione (dopo il mapping) collegate e gestite da un tipo di risoluzione specifico. Se non viene specificato alcun gruppo di colonne per un conflitto, tutte le colonne sono interessate dalla risoluzione specificata per il conflitto specificato.

In alternativa, è possibile specificare un gruppo di colonne DEFAULT, che include tutte le colonne non elencate in un altro gruppo di colonne. Vedere l'opzione DEFAULT.

È possibile specificare più gruppi di colonne, ciascuno con una risoluzione diversa. Ad esempio, è possibile utilizzare OVERWRITE per col2 e col3 e USEDELTA per col4. Nessuna colonna in un gruppo può trovarsi in un altro gruppo. I conflitti per le colonne in gruppi di colonne diversi vengono risolti separatamente in base alla risoluzione specificata e nell'ordine elencato.

I gruppi di colonne funzionano come segue:

Esempi

Esempio 1

Questo esempio mostra tutti i tipi di conflitto con USEMAX, OVERWRITE e 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)),
    );

Esempio 2

Questo esempio mostra UPDATEROWEXISTS con USEDELTA e 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)));

Esempio 3

Questo esempio mostra UPDATEROWEXISTS con USEDELTA, USEMAX e 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 è valido per TABLE e MAP.

Utilizzare SQLEXEC per eseguire una stored procedure o una query SQL da un'istruzione MAP durante l'elaborazione di Oracle GoldenGate. SQLEXEC consente a Oracle GoldenGate di comunicare direttamente con il database per eseguire qualsiasi lavoro supportato dal database. Questo lavoro può essere parte del processo di sincronizzazione, ad esempio il recupero dei valori per la conversione delle colonne, oppure può essere indipendente dall'estrazione o dalla replica dei dati, ad esempio l'esecuzione di una stored procedure che esegue un'azione all'interno del database.

Per la sintassi e l'uso, vedere "SQLEXEC".

SQLPREDICATE 'WHERE <where_clause>'

SQLPREDICATE è valido per i database Oracle, Db2 LUW, Db2 su z/OS, Db2 per i, PostgreSQL, MySQL, SQL Server e Sybase. Non utilizzare SQLPREDICATE per un gruppo Extract configurato per sincronizzare le modifiche transazionali. È appropriato solo per un'estrazione di caricamento iniziale, poiché esegue di nuovo il test di un'istruzione SELECT che seleziona i record direttamente dalle tabelle.

SQLPREDICATE viene utilizzato con TABLE.

Utilizzare SQLPREDICATE per includere una clausola WHERE SQL convenzionale nell'istruzione SELECT utilizzata da Extract quando si selezionano dati da una tabella in preparazione di un caricamento iniziale. SQLPREDICATE forza l'ordinamento dei record restituiti dalla selezione in base ai valori chiave.

SQLPREDICATE è un metodo di selezione più rapido per i caricamenti iniziali rispetto alle opzioni WHERE o FILTER. Influisce direttamente sull'istruzione SQL e non richiede che Extract recuperi tutti i record prima di filtrare i record.

Per le tabelle Oracle, SQLPREDICATE riduce la quantità di dati memorizzati nel segmento di undo, il che può ridurre l'incidenza di errori snapshot troppo vecchi. Questo è utile quando si caricano tabelle molto grandi.

Utilizzando una clausola SQLPREDICATE, è possibile partizionare le righe di una tabella di grandi dimensioni tra due o più processi Extract paralleli. Questa configurazione consente di sfruttare anche l'elaborazione parallela del carico di consegna.

SQLPREDICATE consente inoltre di selezionare i dati in base a un indicatore orario o ad altri criteri per filtrare le righe estratte e caricate nella tabella di destinazione. SQLPREDICATE può essere utilizzato per le clausole ORDER BY o qualsiasi altro tipo di clausola di selezione.

Assicurarsi che la clausola WHERE contenga colonne che fanno parte di una chiave o di un indice. In caso contrario, Extract esegue una scansione completa della tabella, riducendo l'efficienza dell'istruzione SELECT.

Sintassi

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

WHERE

Questa è una parola chiave obbligatoria.

<where_clause>

Una clausola SQL WHERE valida che seleziona i record dalle tabelle di origine.

Esempio

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

THREAD (<thread_ID>)

THREAD è valido per MAP. Questa opzione è valida quando Replicat è in modalità coordinata.

Utilizzare THREAD per specificare che tutti gli oggetti o gli oggetti nella stessa istruzione MAP devono essere elaborati dal thread Replicat specificato. Il thread specificato gestisce l'applicazione di filtri, la manipolazione, la consegna alla destinazione, la gestione degli errori e altri lavori configurati per tali oggetti. I caratteri jolly possono essere utilizzati nella clausola TARGET quando si utilizza THREAD.

Tutte le tabelle con dipendenze referenziali tra loro devono essere mappate nello stesso thread. Ad esempio, se le tabelle scott.cust e scott.ord hanno una relazione chiave esterna, è possibile eseguire il mapping seguente:

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

Il thread con il thread più basso ID elabora sempre le transazioni barriera se l'opzione THREAD o THREADRANGE viene omessa. Inoltre, il lavoro non esplicitamente assegnato a un thread viene elaborato tramite questo thread. Ad esempio, se sono presenti thread con ID compresi tra 1 e 10, le transazioni barriera e non assegnate vengono eseguite dal thread 1.

Per elaborare un'istruzione MAP tra più thread, vedere THREADRANGE (thread_range, column_list). Le opzioni THREAD e THREADRANGE si escludono a vicenda. Non utilizzarli insieme nella stessa istruzione MAP.

Sintassi

THREAD (<thread_ID>)

<thread_ID>

Identificativo numerico per il thread che elaborerà questa istruzione MAP. I valori validi sono compresi tra 1 e il valore specificato con l'opzione MAXTHREADS del comando ADD REPLICAT che ha creato questo gruppo. È possibile utilizzare il comando INFO REPLICAT per verificare il numero massimo di thread consentiti per un gruppo Replicat. Quando si specificano gli ID thread, deve essere vero quanto segue:

Se non si utilizza MAXTHREADS, il numero massimo predefinito di thread è 25.

Esempi

Gli esempi seguenti mostrano alcuni modi per utilizzare l'opzione THREAD.

Esempio 1

In questo esempio, il thread 1 elabora la tabella cust.

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

Esempio 2

In questo esempio, il thread 1 elabora tutte le tabelle nello schema scott.

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

Esempio 3

In questo esempio, la tabella orders viene partizionata tra due istruzioni MAP mediante l'uso di FILTER (filter_clause) e della funzione @RANGE. Per ulteriori informazioni su @RANGE, vedere "@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 è valido per MAP. Questa opzione è valida quando Replicat è in modalità coordinata.

Utilizzare THREADRANGE per specificare che il carico di lavoro della tabella di destinazione deve essere partizionato in modo uniforme tra un intervallo di thread Replicat, in base al valore di una o più colonne specificate. Ad esempio, se il partizionamento si basa sul valore di una colonna denominata ID e il valore THREADRANGE è compreso tra 1 e 3, il thread 1 elabora le righe con valori ID da 1 a 10, il thread 2 elabora le righe con valori ID da 11 a 20 e il thread 3 elabora le righe con valori ID da 21 a 30. Il partizionamento potrebbe non essere assolutamente uguale a quello mostrato nell'esempio precedente, a seconda del calcolo iniziale del carico di lavoro, ma è coordinato in modo che la stessa riga venga sempre elaborata dallo stesso thread. Ogni thread specificato gestisce il filtraggio, la manipolazione, la gestione degli errori, la consegna alla destinazione e altro lavoro per la sua gamma di righe.

Il partizionamento di una tabella in una gamma di thread può migliorare le prestazioni di applicazione per tabelle o tabelle molto grandi che spesso comportano transazioni con tempi di esecuzione lunghi o volumi elevati, ma possono essere utilizzati anche in altri casi. È possibile elaborare più tabelle nello stesso intervallo di thread.

Una clausola TARGET con caratteri jolly può essere utilizzata quando si utilizza THREADRANGE se l'elenco di colonne facoltativo viene omesso. Quando si utilizza un elenco di colonne, utilizzare istruzioni MAP esplicite separate per ogni tabella che utilizza lo stesso intervallo di thread.

Per elaborare un'istruzione MAP con un thread specifico, vedere THREAD (thread_ID). Le opzioni THREAD e THREADRANGE si escludono a vicenda. Non utilizzarli insieme nella stessa istruzione MAP.

Non specificare tabelle con dipendenze referenziali tra loro in un intervallo di thread. Utilizzare l'opzione THREAD ed elaborare tutte le tabelle con lo stesso thread.

Non utilizzare THREADRANGE per partizionare le sequenze. Se è necessario il coordinamento, ad esempio quando una sequenza fa parte di un'operazione SQLEXEC, suddividere la sequenza in un thread con l'opzione THREAD.

Il thread con il thread più basso ID elabora sempre le transazioni barriera se l'opzione THREAD o THREADRANGE viene omessa. Inoltre, il lavoro non esplicitamente assegnato a un thread viene elaborato tramite questo thread. Ad esempio, se sono presenti thread con ID compresi tra 1 e 10, le transazioni barriera e non assegnate vengono eseguite dal thread 1. Nota: le colonne specificate in un elenco di colonne devono esistere nel file trail. È possibile controllarlo utilizzando KEYCOLS nell'estrazione per includere questa colonna oppure utilizzando FETCHCOLS nell'estrazione per la colonna oppure assicurandosi che la colonna faccia parte del gruppo di log supplementare e quindi utilizzando LOGALLSUPCOLS.

Sintassi

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

<lowID>

Identificativo del thread più basso di questo intervallo. I valori validi sono compresi tra 1 e 500.

<highID>

L'identificativo thread più alto di questo intervallo, che deve essere un numero maggiore di <lowID>. I valori validi sono da <lowID>+1 a 500. Il numero di thread nell'intervallo non può superare il valore specificato con l'opzione MAXTHREADS del comando ADD REPLICAT. Se non si utilizza MAXTHREADS, il numero massimo predefinito di thread è 25.

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

Facoltativa. Specifica una o più colonne univoche su cui basare il partizionamento delle righe. Per specificare più colonne, utilizzare un elenco delimitato da virgole, ad esempio col1, col2, col3. Quando questa opzione viene omessa, il partizionamento tra i thread si basa per impostazione predefinita sulle seguenti colonne, nell'ordine di preferenza visualizzato:

Esempio

L'esempio seguente divide le tabelle orders e order_lines tra gli stessi due thread, in base al valore della colonna OID.

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 è valido per TABLE.

Utilizzare TOKENS per definire un token utente e associarlo ai dati. I token consentono di estrarre e memorizzare i dati all'interno dell'area token utente di un'intestazione di record trail. I dati del token possono essere recuperati e utilizzati in molti modi per personalizzare il modo in cui Oracle GoldenGate fornisce i dati. Ad esempio, è possibile utilizzare i dati token nelle mappe di colonne, nelle stored procedure richiamate da SQLEXEC o nelle macro.

Per utilizzare i dati token definiti nelle tabelle di destinazione, utilizzare la funzione di conversione delle colonne @TOKEN nella clausola COLMAP di un'istruzione Replicat MAP. La funzione @TOKEN mappa il nome di un token a una colonna di destinazione.

Non utilizzare questa opzione per le tabelle elaborate in modalità pass-through da un gruppo Extract di Data Pump.

Il set di caratteri dei dati del token non è convertito. Il token deve essere incluso nel set di caratteri del database di origine per Extract e nel set di caratteri del database di destinazione per Replicat.

Sintassi

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

<token_name>

Nome scelto per il token. Può contenere un numero qualsiasi di caratteri validi e non fa distinzione tra maiuscole e minuscole. I nomi multibyte non sono supportati.

<token_data>

Qualsiasi stringa di caratteri valida fino a 2000 byte. I dati possono essere un valore racchiuso tra apici singoli (o virgolette doppie se NOUSEANSISQLQUOTES è in uso) o il risultato di una funzione di conversione delle colonne di Oracle GoldenGate.

Esempio

Di seguito vengono creati i token denominati TK-OSUSER, TK-GROUP e TK-HOST e mappati ai dati dei token ottenuti con la funzione @GETENV.

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

TRIMSPACES | NOTRIMSPACES

TRIMSPACES e NOTRIMSPACES sono validi per TABLE e MAP.

Utilizzare TRIMSPACES e NOTRIMSPACES al livello radice di un file di parametri o all'interno di un'istruzione TABLE o MAP per controllare se gli spazi finali in una colonna CHAR di origine vengono troncati quando vengono applicati a una colonna CHAR o VARCHAR di destinazione. L'impostazione predefinita è TRIMSPACES.

Per la sintassi e l'uso, vedere "TRIMSPACES | NOTRIMSPACES".

TRIMVARSPACES | SPAZI NOTRIMVARSPACES

TRIMVARSPACES e NOTRIMVARSPACES sono validi per TABLE e MAP.

Utilizzare TRIMVARSPACES e NOTRIMVARSPACES al livello radice di un file di parametri o all'interno di un'istruzione TABLE o MAP per controllare se gli spazi finali in una colonna VARCHAR di origine vengono troncati quando vengono applicati a una colonna CHAR o VARCHAR di destinazione. L'impostazione predefinita è NOTRIMVARSPACES.

Per la sintassi e l'uso, vedere "TRIMVARSPACES | NOTRIMVARSPACES".

WHERE (<clause>)

WHERE è valido per TABLE e MAP.

Utilizzare WHERE per selezionare i record in base a un'istruzione condizionale. WHERE non supporta quanto segue:

Racchiudere i valori letterali tra apici. Specificare i nomi di colonna con distinzione tra maiuscole e minuscole mentre vengono memorizzati nel database e racchiuderli tra virgolette se il database richiede virgolette per applicare la distinzione tra maiuscole e minuscole (ad esempio, Oracle).

Recupero di ulteriori informazioni sul filtro dei record

Sintassi

WHERE (<clause>)

<clause>

Seleziona i record in base a una condizione, ad esempio:

WHERE (branch = 'NY')

Nella Tabella 2-12 sono visualizzati gli operatori WHERE consentiti.

Tabella 12 Operatori WHERE autorizzati

Operatore Esempio
Nomi colonna PRODUCT_AMT "Product_Amt"
valori numerici -123, 5500.123
Stringhe letterali racchiuse tra virgolette singole 'AUTO', 'Ca'
Test di colonna @NULL, @PRESENT, @ABSENT (la colonna è nulla, presente o assente nel record). Questi test sono integrati in Oracle GoldenGate.
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]

The following restrictions apply:

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]