Rilevamento e risoluzione manuali dei conflitti

Informazioni sulla configurazione manuale di Conflict Detection and Resolution (CDR) mediante parametri specifici. Il rilevamento e la risoluzione dei conflitti sono necessari nelle configurazioni attive-attive, in cui Oracle GoldenGate deve gestire la sincronizzazione dei dati tra più database che contengono gli stessi data set.

Panoramica della funzione CDR di Oracle GoldenGate

Oracle GoldenGate Conflict Detection and Resolution (CDR) include due parti: Conflict Detection e Conflict Resolution. Prima di iniziare con la risoluzione dei conflitti, è importante indagare e completare il rilevamento dei conflitti.

Oracle GoldenGate Conflict Detection and Resolution (CDR) fornisce le routine di base per la risoluzione dei conflitti che:

Risolvere un conflitto di univocità per un INSERT.
Risolvere un conflitto "nessun dato trovato" per un UPDATE quando la riga esiste, ma l'immagine precedente di una o più colonne è diversa dal valore corrente nel database.
Risolvere un conflitto "nessun dato trovato" per un UPDATE quando la riga non esiste.
Risolvere un conflitto "nessun dato trovato" per un DELETE quando la riga esiste, ma l'immagine precedente di una o più colonne è diversa dal valore corrente nel database.
Risolvere un conflitto "nessun dato trovato" per un DELETE quando la riga non esiste.

Per utilizzare il rilevamento e la risoluzione dei conflitti (CDR), il database di destinazione deve risiedere in un sistema Windows, Linux o UNIX. Non è supportato per i database nella piattaforma NonStop.

CDR supporta tipi di dati scalari quali:

NUMERIC
BOOLEAN
DATE
TIMESTAMP
CHAR/NCHAR
VARCHAR/ NVARCHAR

Ciò significa che questi tipi di colonna possono essere utilizzati con il parametro COMPARECOLS e come colonna di risoluzione nelle opzioni USEMIN e USEMAX del parametro RESOLVECONFLICT. È possibile utilizzare solo le colonne NUMERIC per l'opzione USEDELTA di RESOLVECONFLICT. Per USEMAX, USEMIN, sono supportati solo TIMESTAMP e NUMBER.

La risoluzione dei conflitti non viene eseguita quando Replicat funziona in modalità BATCHSQL. Se si verifica un conflitto in modalità BATCHSQL, Replicat torna alla modalità GROUPTRANSOPS, quindi alla modalità a transazione singola. Il rilevamento dei conflitti avviene in tutte e tre le modalità.

Configurazione dei file dei parametri di Oracle GoldenGate per la risoluzione dei conflitti

I parametri seguenti sono obbligatori per supportare il rilevamento e la risoluzione dei conflitti.

Utilizzare l'opzione COMPARECOLS del parametro MAP nel file dei parametri Replicat per specificare le colonne da utilizzare con i valori precedenti nella clausola WHERE Replicat. I valori precedenti vengono confrontati con i valori correnti nel database di destinazione per rilevare i conflitti di aggiornamento ed eliminazione. Per impostazione predefinita, Replicat utilizza solo la chiave primaria nella clausola WHERE; questo potrebbe non essere sufficiente per il rilevamento dei conflitti.
Utilizzare l'opzione RESOLVECONFLICT del parametro MAP per specificare le routine di risoluzione dei conflitti per operazioni e tipi di conflitti diversi. È possibile utilizzare RESOLVECONFLICT più volte in un'istruzione MAP per specificare risoluzioni diverse per tipi di conflitto diversi. Tuttavia, non è possibile utilizzare RESOLVECONFLICT più volte per lo stesso tipo di conflitto. Utilizzare procedure identiche di risoluzione dei conflitti in tutti i database, in modo che lo stesso conflitto produca lo stesso risultato finale. Un metodo di risoluzione dei conflitti potrebbe non funzionare per ogni conflitto che potrebbe verificarsi. Potrebbe essere necessario creare diverse routine che possono essere richiamate in un ordine di priorità logico in modo da ridurre al minimo il rischio di errore.

Nota: è necessario prestare ulteriore attenzione quando una tabella dispone di una chiave primaria e di indici univoci aggiuntivi o chiavi univoche. Le routine automatizzate fornite con i parametri COMPARECOLS e RESOLVECONFLICT richiedono un modo coerente per identificare in modo univoco ogni riga. La mancata identificazione coerente di una riga comporterà un errore durante la risoluzione del conflitto. In queste situazioni, le chiavi univoche aggiuntive devono essere disabilitate oppure è possibile utilizzare la funzione SQLEXEC per gestire l'errore restituito e risolvere il conflitto.

Per informazioni dettagliate su questi parametri, vedere Informazioni di riferimento su parametri e funzioni per Oracle GoldenGate. Per ulteriori informazioni su questi parametri, vedere gli esempi che iniziano in CDR Esempio 1: All Conflict Types with USEMAX, OVERWRITE, DISCARD.

Impostazione dei valori di colonna obbligatori disponibili per l'estrazione

Per utilizzare CDR, è necessario registrare i seguenti valori di colonna in modo che Extract possa scriverli nel trail.

L'immagine prima completa di ogni record. Alcuni database non forniscono un'immagine precedente nel record di log e devono essere configurati per eseguire tale operazione con log supplementari. Per la maggior parte dei database supportati, è possibile utilizzare il comando ADD TRANDATA a questo scopo.
Utilizzare il parametro LOGALLSUPCOLS per assicurarsi che le immagini complete prima e dopo le colonne di pianificazione vengano scritte nel trail. Le colonne di pianificazione sono le colonne chiave primaria, indice univoco e chiave esterna. LOGALLSUPCOLS fa sì che Extract includa nel record trail l'immagine precedente per le operazioni UPDATE e l'immagine precedente di tutte le colonne registrate in modo supplementare per le operazioni UPDATE e DELETE.

Per informazioni dettagliate su questi parametri e comandi, vedere la Guida di riferimento su parametri e funzioni per Oracle GoldenGate. Per ulteriori informazioni sul funzionamento di questi parametri con CDR, vedere gli esempi che iniziano con CDR Esempio 1: All Conflict Types with USEMAX, OVERWRITE, DISCARD.

Visualizzazione delle statistiche CDR

La funzione CDR fornisce i seguenti metodi per visualizzare i risultati della risoluzione dei conflitti.

Di seguito sono riportate diverse tecniche che è possibile utilizzare per visualizzare le statistiche CDR.

File di report

Replicat scrive le statistiche CDR nel file di report:

Total CDR conflicts        7
    CDR resolutions succeeded       6
    CDR resolutions failed          1
    CDR INSERTROWEXISTS conflicts   1
    CDR UPDATEROWEXISTS conflicts   4
    CDR UPDATEROWMISSING conflicts
    CDR DELETEROWEXISTS conflicts      1
    CDR DELETEROWMISSING conflicts     1

Riga di comando

È possibile visualizzare le statistiche CDR dalla riga di comando utilizzando il comando STATS REPLICAT con l'opzione REPORTCDR:

STATS REPLICAT *group*, REPORTCDR

Funzioni di conversione della colonna

Le statistiche CDR riportate di seguito possono essere recuperate e mappate a una tabella eccezioni o utilizzate in altri parametri di Oracle GoldenGate che accettano l'input dalle funzioni di conversione delle colonne, a seconda dei casi.

Numero di conflitto rilevati da Replicat
Numero di risoluzioni risolte dal Replicat
Numero di risoluzioni che Replicat non è riuscito a risolvere

Per recuperare queste statistiche, utilizzare la funzione di conversione delle colonne @GETENV con il tipo di informazioni STATS o DELTASTATS. I risultati si basano sulla sessione Replicat corrente. Se Replicat si arresta e si riavvia, le statistiche vengono reimpostate.

È possibile restituire queste statistiche per una tabella o un set specifico di tabelle con caratteri jolly:

@GETENV ('STATS','TABLE','SCHEMA.TABLNAME','CDR_CONFLICTS')
@GETENV ('STATS','TABLE','SCHEMA.TABLNAME','CDR_RESOLUTIONS_SUCCEEDED')
@GETENV ('STATS','TABLE','SCHEMA.TABLNAME','CDR_RESOLUTIONS_FAILED')

È possibile restituire queste statistiche per tutte le tabelle in tutte le istruzioni MAP nel file dei parametri Replicat:

@GETENV ('STATS','CDR_CONFLICTS')
@GETENV ('STATS','CDR_RESOLUTIONS_SUCCEEDED')
@GETENV ('STATS','CDR_RESOLUTIONS_FAILED')

Il tipo di informazioni 'STATS' negli esempi precedenti può essere sostituito da 'DELTASTATS' per restituire i conteggi richiesti dall'ultima esecuzione di 'DELTASTATS'. Per ulteriori informazioni su @GETENV, vedere @GETENV

Esempio CDR 1: Tutti i tipi di conflitto con USEMAX, OVERWRITE, DISCARD

Questo esempio risolve tutti i tipi di conflitto utilizzando le risoluzioni USEMAX, OVERWRITE e DISCARD.

Tabella utilizzata in questo esempio

Gli esempi presumono database Oracle identici.

CREATE TABLE hr.emp_tgt(
    name varchar2(30) primary key,
    phone varchar2(10),
    address varchar2(100),
    salary number,
    balance number,
    comment varchar2(100),
    last_mod_time timestamp);

Nel database di origine, tutte le colonne vengono registrate in modo supplementare:

ADD TRANDATA hr.emp_src, COLS (name, phone, address, salary, balance, comment, last_mod_time);

Dichiarazione MAP con specifiche di risoluzione dei conflitti

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

Descrizione del rendiconto MAP

Di seguito viene descritta l'istruzione MAP.

Per COMPARECOLS, utilizzare l'immagine precedente di tutte le colonne nel record trail nella clausola Replicat WHERE per aggiornamenti ed eliminazioni.
Per DEFAULT, utilizzare tutte le colonne come gruppo di colonne per tutti i tipi di conflitto; pertanto, la risoluzione si applica a tutte le colonne.
Per un conflitto INSERTROWEXISTS, utilizzare la risoluzione USEMAX: se la riga esiste durante un inserimento, utilizzare la colonna last_mod_time come colonna di risoluzione per decidere quale sia il valore maggiore: il valore nel trail o quello nel database. Se il valore del trail è maggiore, applicare il record ma modificare l'inserimento in un aggiornamento. Se il valore del database è superiore, ignorare il record.
Per un conflitto UPDATEROWEXISTS, utilizzare la risoluzione USEMAX: se la riga esiste durante un aggiornamento, utilizzare la colonna last_mod_time come colonna di risoluzione: se il valore nel trail è maggiore, applicare l'aggiornamento.
Se si utilizza USEMIN o USEMAX e i valori sono esattamente gli stessi, RESOLVECONFLICT non viene attivato e la riga in entrata viene ignorata. Se si utilizza USEMINEQ o USEMAXEQ e i valori sono esattamente gli stessi, viene attivata la risoluzione.
Per un conflitto DELETEROWEXISTS, utilizzare la risoluzione OVERWRITE: se la riga esiste durante un'operazione di eliminazione, applicare l'eliminazione.
Per un conflitto UPDATEROWMISSING, utilizzare la risoluzione OVERWRITE: se la riga non esiste durante un aggiornamento, modificare l'aggiornamento in un inserimento e applicarlo.
Per un conflitto DELETROWMISSING utilizzare la risoluzione DISCARD: se la riga non esiste durante un'operazione di eliminazione, eliminare il record trail.

Nota: in alternativa a USEMAX, è possibile utilizzare la risoluzione USEMAXEQ per applicare una condizione >=. Per ulteriori informazioni, vedere Riferimento su parametri e funzioni per Oracle GoldenGate.

INSERTROWEXISTS con risoluzione USEMAX

Per questo esempio, la risoluzione USEMAX viene illustrata con le immagini precedenti e successive applicabili per il record nel trail e nel database. Mostra come risolvere un inserimento in cui la riga esiste nell'origine e nella destinazione, ma alcuni o tutti i valori di riga sono diversi.

Tabella 10 INSERTROWEXISTS Conflitto con la risoluzione USEMAX

Immagine	SQL	Commenti
Prima dell'immagine nel trail	None (row was inserted on the source).	ND
Dopo l'immagine nel trail	name='Mary' phone='1234567890' address='Oracle Pkwy' salary=100 balance=100 comment=NULL last_mod_time='9/1/10 3:00'	`last_mod_time='9/1/10 3:00` è l'immagine successiva della colonna di risoluzione. Poiché esiste un'immagine successiva, questa verrà utilizzata per determinare la risoluzione.
Immagine del database di destinazione	name='Mary' phone='111111' address='Ralston' salary=200 balance=500 comment='aaa' last_mod_time='9/1/10 1:00'	`last_mod_time='9/1/10 1:00` è l'immagine corrente della colonna di risoluzione nella destinazione rispetto alla quale viene confrontato il valore della colonna di risoluzione nel trail.
`INSERT` iniziale applicato da Replicat che rileva il conflitto	Variabili di bind SQL: 1)'Mary' 2)'1234567890' 3)'Oracle Pkwy' 4)100 5)100 6)NULL 7)'9/1/10 3:00'	Questa istruzione SQL restituisce un conflitto di univocità su 'Maria'.
`UPDATE` applicato da Replicat per risolvere il conflitto	Variabili di bind SQL: 1)'1234567890' 2)'Oracle Pkwy' 3)100 4)100 5)NULL 6)'9/1/10 3:00' 7)'Mary' 8)'9/1/10 3:00'	Poiché `USEMAX` è specificato per `INSERTROWEXISTS`, Replicat converte l'inserimento in un aggiornamento e confronta il valore di `last_mod_time` nel record trail con il valore nel database. Il valore del record è maggiore, quindi le immagini successive per le colonne nel file trail vengono applicate alla destinazione.

AGGIORNAMENTI con la Risoluzione USEMAX

Per questo esempio, la risoluzione USEMAX viene illustrata con le immagini precedenti e successive applicabili per il record nel trail e nel database. Mostra come risolvere un aggiornamento in cui la riga esiste nell'origine e nella destinazione, ma alcuni o tutti i valori di riga sono diversi.

Tabella 11 UPDATEROWEXISTS Conflitto con la risoluzione USEMAX

Immagine	SQL	Commenti
Prima dell'immagine nel trail	name='Mary' phone='1234567890' address='Oracle Pkwy' salary=100 balance=100 comment=NULL last_mod_time='9/1/10 3:00'	`last_mod_time='9/1/10 3:00` è l'immagine precedente della colonna di risoluzione.
Dopo l'immagine nel trail	phone='222222' address='Holly' last_mod_time='9/1/10 5:00'	`last_mod_time='9/1/10 5:00` è l'immagine successiva della colonna di risoluzione. Poiché esiste un'immagine successiva, questa verrà utilizzata per determinare la risoluzione.
Immagine del database di destinazione	name='Mary' phone='1234567890' address='Oracle Pkwy' salary=100 balance=600 comment='com' last_mod_time='9/1/10 6:00'	`last_mod_time='9/1/10 6:00` è l'immagine corrente della colonna di risoluzione nella destinazione rispetto alla quale viene confrontato il valore della colonna di risoluzione nel trail.
`UPDATE` iniziale applicato da Replicat che rileva il conflitto	Variabili di bind SQL: 1)'222222' 2)'Holly' 3)'9/1/10 5:00' 4)'Mary' 5)'1234567890' 6)'Oracle Pkwy' 7)100 8)100 9)NULL 10)'9/1/10 3:00'	Questa istruzione SQL restituisce un errore non trovato dai dati poiché i valori per `balance`, `comment` e `last_mod_time` sono diversi nella destinazione. Tutte le colonne vengono utilizzate nella clausola `WHERE` perché l'istruzione `COMPARECOLS` è impostata su `ALL`.
`UPDATE` applicato da Replicat per risolvere il conflitto	Variabili di bind SQL: 1)'Mary' 2)'222222' 3)'Holly' 4)100 5)100 6)NULL 7)'9/1/10 5:00' 8)'Mary' 9)'9/1/10 5:00'	Poiché il valore successivo a `last_mod_time` nel record trail è minore del valore corrente nel database, il valore del database viene conservato. Replicat applica l'operazione con una clausola `WHERE` contenente la chiave primaria più un valore `last_mod_time` impostato su un valore minore di `9/1/10 5:00`. Nessuna riga corrisponde a questi criteri, quindi l'istruzione non riesce con un errore "data not found", ma Replicat ignora l'errore perché si prevede che una risoluzione `USEMAX` non riesca se la condizione non viene soddisfatta.

UPDATEROWMISSING con risoluzione OVERWRITE

Per questo esempio, la risoluzione OVERWRITE viene illustrata con le immagini precedenti e successive applicabili per il record nel trail e nel database. Mostra come risolvere il caso in cui manca la riga di destinazione. La risoluzione logica, e quella utilizzata, è quella di sovrascrivere la riga nella destinazione in modo che entrambi i database siano nuovamente sincronizzati.

Tabella 12 AGGIORNAMENTO Conflitto con risoluzione sovrascritta

Immagine	SQL	Commenti
Prima dell'immagine nel trail	name='Jane' phone='333' address='Oracle Pkwy' salary=200 balance=200 comment=NULL last_mod_time='9/1/10 7:00'	ND
Dopo l'immagine nel trail	phone='4444' address='Holly' last_mod_time='9/1/10 8:00'
Immagine del database di destinazione	None (row for Jane is missing)
`UPDATE` iniziale applicato da Replicat che rileva il conflitto	Variabili di bind SQL: 1)'4444' 2)'Holly' 3)'9/1/10 8:00' 4)'Jane' 5)'333' 6)'Oracle Pkwy' 7)200 8)200 9)NULL 10)'9/1/10 7:00'	Questa istruzione SQL restituisce un errore non trovato dai dati. Tutte le colonne vengono utilizzate nella clausola `WHERE` perché l'istruzione `COMPARECOLS` è impostata su `ALL`.
`INSERT` applicato da Replicat per risolvere il conflitto	Variabili di bind SQL: 1)'Jane' 2)'4444' 3)'Holly' 4)200 5)200 6)NULL 7)'9/1/10 8:00'	L'aggiornamento viene convertito in un inserimento perché `OVERWRITE` è la risoluzione. Se disponibile, viene utilizzata l'immagine successiva di una colonna, altrimenti viene utilizzata l'immagine precedente.

DELETEROWEXISTS con risoluzione OVERWRITE

Per questo esempio, la risoluzione OVERWRITE viene illustrata con le immagini precedenti e successive applicabili per il record nel trail e nel database. Mostra come risolvere il caso in cui la riga di origine è stata eliminata ma la riga di destinazione esiste. In questo caso, la risoluzione OVERWRITE applica l'eliminazione alla destinazione.

Tabella 13 DELETEROWEXISTS Conflitto con risoluzione OVERWRITE

Immagine	SQL	Commenti
Prima dell'immagine nel trail	name='Mary' phone='222222' address='Holly' salary=100 balance=100 comment=NULL last_mod_time='9/1/10 5:00'	ND
Dopo l'immagine nel trail	None	ND
Immagine del database di destinazione	name='Mary' phone='1234567890' address='Oracle Pkwy' salary=100 balance=600 comment=com last_mod_time='9/1/10 7:00'	La riga esiste nella destinazione, ma le colonne `phone`, `address`, `balance`, `comment` e `last_mod_time` sono diverse dall'immagine precedente nel trail.
`DELETE` iniziale applicato da Replicat che rileva il conflitto	Variabili di bind SQL: 1)'Mary' 2)'222222' 3)'Holly' 4)100 5)100d 6)NULL 7)'9/1/10 5:00'	Tutte le colonne vengono utilizzate nella clausola `WHERE` perché l'istruzione `COMPARECOLS` è impostata su `ALL`. Si verifica un errore non trovato dai dati a causa della differenza tra i valori precedente e corrente.
`DELETE` applicato da Replicat per risolvere il conflitto	Variabili di bind SQL: 1)'Mary'	Poiché `OVERWRITE` è la risoluzione, `DELETE` viene applicato solo utilizzando la chiave primaria (per evitare un errore di integrità).

DELETEROWMISSING con risoluzione DISCARD

Per questo esempio, la risoluzione DISCARD viene illustrata con le immagini precedenti e successive applicabili per il record nel trail e nel database. Mostra come risolvere il caso in cui manca la riga di destinazione. Nel caso di un'eliminazione nell'origine, è accettabile che la riga di destinazione non esista (dovrebbe essere eliminata comunque), quindi la risoluzione consiste nell'eliminare l'operazione DELETE che si trova nel trail.

Tabella 14 DELETEROWMSING Conflitto con risoluzione DISCARD

Immagine	SQL	Commenti
Prima dell'immagine nel trail	name='Jane' phone='4444' address='Holly' salary=200 balance=200 comment=NULL last_mod_time='9/1/10 8:00'	ND
Dopo l'immagine nel trail	None	ND
Immagine del database di destinazione	None (row missing)	ND
`DELETE` iniziale applicato da Replicat che rileva il conflitto	Variabili di bind SQL: 1)'Jane' 2)'4444' 3)'Holly' 4)200 5)200 6)NULL 7)'9/1/10 8:00'	Questa istruzione SQL restituisce un errore non trovato dai dati. Tutte le colonne vengono utilizzate nella clausola `WHERE` perché l'istruzione `COMPARECOLS` è impostata su `ALL`.
SQL applicato da Replicat per risolvere il conflitto	None	Poiché `DISCARD` è specificato come risoluzione per `DELETEROWMISSING`, l'eliminazione dal trail passa al file di scarto.

Esempio CDR 2: AGGIORNAMENTI con USEDELTA e USEMAX

Questo esempio risolve la condizione in cui una riga di destinazione esiste in UPDATE ma le colonne non chiave sono diverse e utilizza due tipi di risoluzione diversi per gestire questa condizione in base alla colonna interessata.

Tabella utilizzata in questo esempio

Gli esempi presumono database Oracle identici.

CREATE TABLE tgt(
    name varchar2(30) primary key,
    phone varchar2(10),
    address varchar2(100),
    salary number,
    balance number,
    comment varchar2(100),
    last_mod_time timestamp);

Nel database di origine, tutte le colonne vengono registrate in modo supplementare:

ADD TRANDATA scott.src, COLS (name, phone, address, salary, balance, comment, last_mod_time);

Istruzione MAP

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

Descrizione del rendiconto MAP

Per un conflitto UPDATEROWEXISTS, in cui una riga di destinazione esiste in UPDATE ma le colonne non chiave sono diverse, utilizzare due risoluzioni diverse a seconda della colonna:

Per la risoluzione delta_res_method, utilizzare la logica di risoluzione USEDELTA per la colonna salary in modo che la modifica del valore venga aggiunta al valore corrente della colonna.
Per DEFAULT, utilizzare la logica di risoluzione USEMAX per tutte le altre colonne della tabella (il gruppo di colonne predefinito), utilizzando la colonna last_mod_time come colonna di risoluzione. Questa colonna viene aggiornata con l'ora corrente ogni volta che la riga viene modificata; il valore di questa colonna nel trail viene confrontato con il valore nella destinazione. Se il valore di last_mod_time nel record trail è maggiore del valore corrente di last_mod_time nel database di destinazione, le modifiche apportate a name, phone, address, balance, comment e last_mod_time vengono applicate alla destinazione.

Per COMPARECOLS, utilizzare la chiave primaria (colonna name ) più le colonne address, phone, salary e last_mod_time come colonne di confronto per il rilevamento dei conflitti per le operazioni UPDATE e DELETE. Le colonne balance e comment non vengono confrontate.

Nota: in alternativa a USEMAX, è possibile utilizzare la risoluzione USEMAXEQ per applicare una condizione >=. Per ulteriori informazioni, vedere Riferimento su parametri e funzioni per Oracle GoldenGate.

Gestione errori

Per un esempio di gestione degli errori in una tabella delle eccezioni, vedere Configurazione dei file dei parametri di Oracle GoldenGate per la gestione degli errori.

Tabella 15 AGGIORNAMENTI con USEDELTA e USEMAX

Immagine	SQL	Commenti
Prima dell'immagine nel trail	`name='Mary' phone='1234567890' address='Oracle Pkwy' salary=100 balance=100 comment=NULL last_mod_time='9/1/10 3:00'`	`last_mod_time='9/1/10 3:00` è l'immagine precedente della colonna di risoluzione per la risoluzione `USEMAX`. `salary=100` è l'immagine precedente per la risoluzione `USEDELTA`.
Dopo l'immagine nel trail	`phone='222222' address='Holly' salary=200 comment='new' last_mod_time='9/1/10 5:00'`	`last_mod_time='9/1/10 5:00` è l'immagine successiva della colonna di risoluzione per `USEMAX`. Poiché esiste un'immagine successiva, questa verrà utilizzata per determinare la risoluzione.
Immagine del database di destinazione	`name='Mary' phone='1234567890' address='Oracle Pkwy' salary=600 balance=600 comment='com' last_mod_time='9/1/10 4:00'`	`last_mod_time='9/1/10 4:00` è l'immagine corrente della colonna di risoluzione nella destinazione rispetto alla quale viene confrontato il valore della colonna di risoluzione nel trail. `salary=600` è l'immagine corrente della colonna di destinazione per la risoluzione `USEDELTA`.
`UPDATE` iniziale applicato da Replicat che rileva il conflitto	Variabili di bind SQL: `1)'222222' 2)'Holly' 3)200 4)'new' 5)'9/1/10 5:00' 6)'Mary' 7)'1234567890' 8)'Oracle Pkwy' 9)100 10)'9/1/10 3:00'`	Questo SQL restituisce un errore non trovato dai dati perché i valori per `salary` e `last_mod_time` sono diversi. Anche i valori per `comment` e `balance` sono diversi, ma queste colonne non vengono confrontate.
`UPDATE` applicato da Replicat per risolvere il conflitto per `salary`, utilizzando `USEDELTA`.	Variabili di bind SQL: `1)200 2)100 3)'Mary'`	Per `USEDELTA`, la differenza tra l'immagine successiva di `salary` (200) nel trail e l'immagine precedente di `salary` (100) nel trail viene aggiunta al valore corrente di `salary` nel target (600). Il risultato è 700. `600 + (200 - 100) = 700`
`UPDATE` applicato da Replicat per risolvere il conflitto per le colonne predefinite, utilizzando `USEMAX`.	Variabili di bind SQL: `1)'222222' 2)'Holly' 3)'new' 4)'9/1/10 5:00' 5)'Mary' 6)'9/1/10 5:00'`	Per `USEMAX`, poiché il valore successivo a `last_mod_time` nel record trail è maggiore del valore corrente nel database, la riga viene aggiornata con i valori successivi del record trail. Si noti che la colonna `salary` non è impostata qui perché viene risolta con `UPDATE` dalla risoluzione `USEDELTA`.

Esempio CDR 3: UPDATEROWEXISTS con USEDELTA, USEMAX e IGNORE

Questo esempio risolve il conflitto in cui una riga di destinazione esiste in UPDATE ma le colonne non chiave sono diverse e utilizza tre tipi di risoluzione diversi per gestire questa condizione in base alla colonna interessata.

Tabella utilizzata in questo esempio

Gli esempi presumono database Oracle identici.

CREATE TABLE tgt(
    name varchar2(30) primary key,
    phone varchar2(10),
    address varchar2(100),
    salary number,
    balance number,
    comment varchar2(100),
    last_mod_time timestamp);

Nel database di origine, tutte le colonne vengono registrate in modo supplementare:

ADD TRANDATA scott.src, COLS (name, phone, address, salary, balance, comment, last_mod_time);

Istruzione MAP

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

Descrizione del rendiconto MAP

Per un conflitto UPDATEROWEXISTS, in cui una riga di destinazione esiste in UPDATE ma le colonne non chiave sono diverse, utilizzare due risoluzioni diverse a seconda della colonna:
- Per la risoluzione delta_res_method, utilizzare la logica di risoluzione USEDELTA per le colonne salary e balance in modo che la modifica in ciascun valore venga aggiunta al valore corrente di ogni colonna.
- Per la risoluzione max_res_method, utilizzare la logica di risoluzione USEMAX per le colonne address e last_mod_time. La colonna last_mod_time è la colonna di risoluzione. Questa colonna viene aggiornata con l'ora corrente ogni volta che la riga viene modificata; il valore di questa colonna nel trail viene confrontato con il valore nella destinazione. Se il valore di last_mod_time nel record trail è maggiore del valore corrente di last_mod_time nel database di destinazione, le modifiche a address e last_mod_time vengono applicate alla destinazione; in caso contrario, vengono ignorate a favore dei valori di destinazione.
- Per DEFAULT, utilizzare la logica di risoluzione IGNORE per le colonne rimanenti (phone e comment) nella tabella (il gruppo di colonne predefinito). Le modifiche apportate a queste colonne verranno sempre ignorate da Replicat.
Per COMPARECOLS, utilizzare tutte le colonne tranne la colonna comment come colonne di confronto per il rilevamento dei conflitti per le operazioni UPDATE. Il commento non verrà utilizzato nella clausola WHERE per gli aggiornamenti, ma verranno utilizzate tutte le altre colonne con un'immagine precedente nel record trail. Nota: in alternativa a USEMAX, è possibile utilizzare la risoluzione USEMAXEQ per applicare una condizione >=. Per ulteriori informazioni, vedere Riferimento su parametri e funzioni per Oracle GoldenGate.

Gestione errori

Per un esempio di gestione degli errori in una tabella delle eccezioni, vedere Configurazione dei file dei parametri di Oracle GoldenGate per la gestione degli errori.

Tabella 16 AGGIORNAMENTI con USEDELTA, USEMAX e IGNORE

Immagine	SQL	Commenti
Prima dell'immagine nel trail	`name='Mary' phone='1234567890' address='Oracle Pkwy' salary=100 balance=100 comment=NULL last_mod_time='9/1/10 3:00`	`last_mod_time='9/1/10 3:00` è l'immagine precedente della colonna di risoluzione per la risoluzione `USEMAX`. `salary=100` e `balance=100` sono le immagini precedenti per la risoluzione `USEDELTA`.
Dopo l'immagine nel trail	`phone='222222' address='Holly' salary=200 comment='new' last_mod_time='9/1/10 5:00'`	`last_mod_time='9/1/10 5:00` è l'immagine successiva della colonna di risoluzione per `USEMAX`. Poiché esiste un'immagine successiva, questa verrà utilizzata per determinare la risoluzione. `salary=200` è l'unica immagine successiva disponibile per la risoluzione `USEDELTA`. Per `balance`, nel calcolo verrà utilizzata l'immagine precedente.
Immagine del database di destinazione	`name='Mary' phone='1234567890' address='Ralston' salary=600 balance=600 comment='com' last_mod_time='9/1/10 4:00'`	`last_mod_time='9/1/10 4:00` è l'immagine corrente della colonna di risoluzione nella destinazione rispetto alla quale viene confrontato il valore della colonna di risoluzione nel trail per `USEMAX`. `salary=600` e `balance=600` sono le immagini correnti delle colonne di destinazione per `USEDELTA`.
`UPDATE` iniziale applicato da Replicat che rileva il conflitto	Variabili di bind SQL: `1)'222222' 2)'Holly' 3)200 4)'new' 5)'9/1/10 5:00' 6)'Mary' 7)'1234567890' 8)'Oracle Pkwy' 9)100 10)100 11)'9/1/10 3:00'`	Questo codice SQL restituisce un errore non trovato dai dati perché i valori per le colonne `address`, `salary`, `balance` e `last_mod_time` sono diversi.
`UPDATE` applicato da Replicat per risolvere il conflitto per `salary`, utilizzando `USEDELTA`.	Variabili di bind SQL: `1)200 2)100 3)'Mary'`	Per `salary`, esiste una differenza di 100, ma non è stata apportata alcuna modifica al valore per `balance`, pertanto non è necessaria nell'SQL di aggiornamento. Per `USEDELTA`, la differenza (delta) tra l'immagine dopo (200) e l'immagine prima (100) di `salary` nel trail viene aggiunta al valore corrente di `salary` nel target (600). Il risultato è 700.
`UPDATE` applicato da Replicat per risolvere il conflitto per `USEMAX`.	Variabili di bind SQL: `1)'Holly' 2)'9/1/10 5:00' 3)'Mary' 4)'9/1/10 5:00'`	Poiché il valore successivo a `last_mod_time` nel record trail è maggiore del valore corrente del database, la colonna più la colonna `address` viene aggiornata con i valori successivi del record trail. Si noti che la colonna `salary` non è impostata qui perché viene risolta con `UPDATE` dalla risoluzione `USEDELTA`.
`UPDATE` applicato da Replicat per `IGNORE`.	Variabili di bind SQL: `1)'222222' 2)'new' 3)'Mary'`	`IGNORE` è specificato per il gruppo di colonne `DEFAULT` (`phone` e `comment`), pertanto non viene applicata alcuna istruzione SQL di risoluzione.

Configurazione dei file dei parametri di Oracle GoldenGate per la gestione degli errori

Il CDR manuale deve essere utilizzato insieme alla gestione degli errori per acquisire gli errori risolti e gli errori che il CDR non è riuscito a risolvere.

La risoluzione dei conflitti viene eseguita prima di questi altri parametri di gestione degli errori: HANDLECOLLSIONS, INSERTMISSINGUPDATES e REPERROR. Utilizzare il parametro REPERROR per assegnare regole per la gestione degli errori che non possono essere risolti da CDR o per gli errori che non si desidera gestire tramite CDR. Potrebbe essere appropriato che REPERROR gestisca alcuni errori e CDR ne gestisca altri; tuttavia, se REPERROR e CDR sono configurati per gestire lo stesso conflitto, CDR ha la precedenza. I parametri INSERTMISSINGUPDATES e HANDLECOLLISIONS possono essere utilizzati anche per gestire alcuni errori non gestiti da CDR. Per informazioni dettagliate su questi parametri, vedere Riferimento parametri e funzioni per Oracle GoldenGate.
(Facoltativo) Creare una tabella delle eccezioni. Quando viene utilizzata una tabella delle eccezioni con una statistica MAP delle eccezioni, Replicat invia tutte le operazioni che generano un conflitto (risolto o meno) all'istruzione MAP delle eccezioni da mappare alla tabella delle eccezioni. Omettere una chiave primaria in questa tabella se Replicat deve elaborare conflitti UPDATE e DELETE; in caso contrario, possono verificarsi errori di vincolo di integrità.

Almeno una tabella delle eccezioni deve contenere le stesse colonne della tabella di destinazione. Queste righe conterranno ogni immagine di riga applicata da Replicat alla destinazione (o che si è tentato di applicare).

Inoltre, è possibile definire colonne aggiuntive per acquisire altre informazioni che consentono di inserire i dati nel contesto transazionale. Oracle GoldenGate fornisce gli strumenti per acquisire queste informazioni tramite l'istruzione MAP delle eccezioni. Tali colonne possono essere, ma non sono limitate a:
- L'immagine precedente del record trail. Questo è un set duplicato delle colonne di destinazione con nomi quali col1_before, col2_before e così via.
- I valori correnti delle colonne target. Si tratta inoltre di un set duplicato delle colonne di destinazione con nomi quali col1_current, col2_current e così via.
- Il nome della tabella di destinazione
- L'indicatore orario del conflitto
- Tipo di operazione
- Numero di errore del database
- (Facoltativo) Messaggio di errore del database
- Indica se il conflitto è stato risolto o meno
Creare un'istruzione MAP delle eccezioni per mappare i dati delle eccezioni alla tabella delle eccezioni. Un'istruzione MAP delle eccezioni contiene:
- (Obbligatorio) Opzione INSERTALLRECORDS. Questo parametro converte tutte le operazioni mappate in INSERT in modo che tutti i valori di colonna siano mappati alla tabella delle eccezioni.
- (Obbligatorio) Opzione EXCEPTIONSONLY. Questo parametro fa sì che Replicat esegua il mapping delle operazioni che generano un errore, ma non di quelle riuscite.
- (Facoltativo) Una clausola COLMAP. Se i nomi e le definizioni delle colonne nella tabella delle eccezioni sono identici a quelli della tabella di origine e la tabella delle eccezioni contiene solo tali colonne, non è necessario utilizzare COLMAP. Tuttavia, se i nomi o le definizioni sono diversi o se nella tabella delle eccezioni sono presenti colonne aggiuntive che si desidera popolare con dati aggiuntivi, utilizzare una clausola COLMAP per mappare tutte le colonne.

Strumenti per il mapping dei dati supplementari alla tabella Eccezioni

Di seguito sono riportati alcuni strumenti che è possibile utilizzare nella clausola COLMAP per popolare colonne aggiuntive.

Se i nomi e le definizioni delle colonne di origine sono identici a quelli delle colonne di destinazione nella tabella delle eccezioni, è possibile utilizzare la parola chiave USEDEFAULTS anziché mappare esplicitamente i nomi. In caso contrario, è necessario mappare tali colonne nella clausola COLMAP, ad esempio:
```
COLMAP (exceptions_col1 = col1, [...])
```
Per mappare l'immagine precedente della riga di origine alle colonne nella tabella delle eccezioni, utilizzare la funzione di conversione @BEFORE, che acquisisce l'immagine precedente di una colonna dal record trail. Questo esempio mostra l'uso di @BEFORE.
```
COLMAP (USEDEFAULTS, exceptions_col1 = @BEFORE (source_col1), &
exceptions_col2 = @BEFORE (source_col2), [...])
```
Per mappare l'immagine corrente della riga di destinazione alle colonne della tabella delle eccezioni, utilizzare una query SQLEXEC per acquisire l'immagine, quindi mappare i risultati della query alle colonne della tabella delle eccezioni utilizzando la sintassi 'queryID.column' nella clausola COLMAP, come nell'esempio seguente:
```
COLMAP (USEDEFAULTS, name_current = *queryID*.*name*, phone_current = *queryID*.*phone*, [...])
```
Per mappare gli indicatori orari, gli errori del database e altre informazioni ambientali, utilizzare le funzioni di conversione delle colonne Oracle GoldenGate appropriate. Ad esempio, la seguente mappa l'indicatore orario corrente al momento dell'esecuzione.
```
res_date = @DATENOW ()
```

Vedere Mapping eccezioni di esempio con colonne aggiuntive nella tabella Eccezioni per informazioni su come combinare queste funzioni in una clausola COLMAP nell'istruzione MAP delle eccezioni per popolare una tabella delle eccezioni dettagliata.

Vedere Riferimento parametri e funzioni per Oracle GoldenGate per l'uso e la sintassi dei parametri e delle funzioni di conversione delle colonne mostrati in questi esempi.

Mapping eccezioni campione con solo colonne di origine e di destinazione

Di seguito è riportato un file di parametri di esempio che mostra la gestione degli errori e il mapping di eccezioni semplici per le tabelle di origine e di destinazione utilizzate negli esempi di CDR che iniziano. In questo esempio vengono mappate le colonne di origine e di destinazione, ma non le colonne aggiuntive. Per i seguenti motivi, non è necessaria una clausola COLMAP nell'istruzione MAP delle eccezioni in questo esempio:

Le colonne delle eccezioni di origine e destinazione sono identiche per nome e definizione.
Nella tabella delle eccezioni non sono presenti altre colonne. Nota: in questo esempio vengono esclusi intenzionalmente altri parametri richiesti in un file dei parametri Replicat, ad esempio il nome del processo e le credenziali di login, nonché eventuali parametri facoltativi che potrebbero essere necessari per un determinato tipo di database. Quando si utilizzano le interruzioni di riga per frazionare un'istruzione di parametro in più righe, utilizzare una e commerciale (&) alla fine di ogni riga.

    -- REPERROR error handling: DEFAULT represents all error types. DISCARD

    -- writes operations that could not be processed to a discard file.
REPERROR (DEFAULT, DISCARD)

    -- Specifies a discard file.
DISCARDFILE /users/ogg/discards/discards.dsc, PURGE

    -- The regular MAP statement with the CDR parameters
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)), &
);

    -- Starts the exceptions MAP statement by mapping the source table to the

    -- exceptions table.
MAP fin.src, TARGET fin.exception, &

    -- directs Replicat only to map operations that caused the error specified

    -- in REPERROR.
EXCEPTIONSONLY, &

    -- directs Replicat to convert all the exceptions to inserts into the

    -- exceptions table. This is why there cannot be a primary key constraint

    -- on the exceptions table.
INSERTALLRECORDS
;

Mapping eccezioni di esempio con colonne aggiuntive nella tabella Eccezioni

Di seguito è riportato un file di parametri di esempio che mostra la gestione degli errori e il mapping di eccezioni complesse per le tabelle di origine e di destinazione utilizzate negli esempi di CDR che iniziano. In questo esempio, la tabella delle eccezioni ha le stesse righe della tabella di origine, ma dispone anche di colonne aggiuntive per acquisire i dati di contesto.

Nota: in questo esempio vengono esclusi intenzionalmente altri parametri richiesti in un file dei parametri Replicat, ad esempio il nome del processo e le credenziali di login, nonché eventuali parametri facoltativi che potrebbero essere necessari per un determinato tipo di database. Quando si utilizzano le interruzioni di riga per frazionare un'istruzione di parametro in più righe, utilizzare una e commerciale (&) alla fine di ogni riga.

    -- REPERROR error handling: DEFAULT represents all error types. DISCARD
    -- writes operations that could not be processed to a discard file.
REPERROR (DEFAULT, DISCARD)
    -- Specifies the discard file.
DISCARDFILE /users/ogg/discards/discards.dsc, PURGE
    -- The regular MAP statement with the CDR parameters
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))
);
    -- Starts the exceptions MAP statement by mapping the source table to the -- exceptions table.
MAP fin.src, TARGET fin.exception, &
    -- directs Replicat only to map operations that caused the error specified
    -- in REPERROR.
EXCEPTIONSONLY, &
    -- directs Replicat to convert all the exceptions to inserts into the
    -- exceptions table. This is why there cannot be a primary key constraint
    -- on the exceptions table.
INSERTALLRECORDS &
    -- SQLEXEC query to select the values from the target record before the
    -- Replicat statement is applied. These are mapped to the *_target
    -- columns later.
SQLEXEC (id qry, query 'select name, phone, address, salary, balance, & comment, last_mod_time from fin.tgt where name = :p1', PARAMS(p1 = name )), &
    -- Start of the column mapping, specifies use default column definitions.
COLMAP ( &
    -- USEDEFAULTS maps the source columns to the target exceptions columns
    -- that receive the after image that Replicat applied or tried to apply.
    -- In this case, USEDEFAULTS can be used because the names and definitions
    -- of the source and target exceptions columns are identical; otherwise
    -- the columns must be mapped explicitly in the COLMAP clause.
USEDEFAULTS, &
    -- captures the timestamp when the resolution was performed.
res_date = @DATENOW (), &
    -- captures and maps the DML operation type.
optype = @GETENV ('LASTERR', 'OPTYPE'), &
    -- captures and maps the database error number that was returned.
dberrnum = @GETENV ('LASTERR', 'DBERRNUM'), &
    -- captures and maps the database error that was returned.
dberrmsge = @GETENV ('LASTERR', 'DBERRMSG'), &
    -- captures and maps the name of the target table
tabname = @GETENV ('GGHEADER', 'TABLENAME'), &
    -- If the names and definitions of the source columns and the target
    -- exceptions columns were not identical, the columns would need to
    -- be mapped in the COLMAP clause instead of using USEDEFAULTS, as
    -- follows:
       -- name_after = name, &
       -- phone_after = phone, &
       -- address_after = address, &
       -- salary_after = salary, &
       -- balance_after = balance, &
       -- comment_after = comment, &
       -- last_mod_time_after = last_mod_time &
    -- maps the before image of each column from the trail to a column in the
    -- exceptions table.
name_before = @BEFORE (name), &
phone_before = @BEFORE (phone), &
address_before = @BEFORE (address), &
salary_before = @BEFORE (salary), &
balance_before = @BEFORE (balance), &
comment_before = @BEFORE (comment), &
last_mod_time_before = @BEFORE (last_mod_time), &
    -- maps the results of the SQLEXEC query to rows in the exceptions table
    -- to show the current image of the row in the target.
name_current = qry.name, &
phone_current = qry.phone, &
address_current = qry.address, &
salary_current = qry.salary, &
balance_current = qry.balance, &
comment_current = qry.comment, &
last_mod_time_current = qry.last_mod_time)
;

Una volta che sei sicuro che le tue routine funzionino come previsto in tutte le situazioni, puoi ridurre la quantità di dati registrati nella tabella delle eccezioni per ridurre il carico di lavoro delle routine di risoluzione.