RIPROGRAMMA

Valido per

Replicat

Descrizione

Utilizzare il parametro REPERROR per controllare la modalità di risposta di Replicat agli errori. La risposta predefinita di Replicat a qualsiasi errore è di interrompere.

È possibile utilizzare un'istruzione REPERROR per gestire la maggior parte degli errori in modo predefinito, mentre si utilizzano una o più altre istruzioni REPERROR per gestire errori specifici in modo diverso. Ad esempio, è possibile ignorare gli errori dei record duplicati, ma interrompere l'elaborazione in tutti gli altri casi.

È possibile utilizzare REPERROR a livello globale (alla radice del file dei parametri) per influire su tutte le istruzioni MAP che lo seguono oppure utilizzarlo all'interno di un'istruzione MAP per influire sulle tabelle specificate in tale istruzione. L'utilizzo di REPERROR all'interno di un'istruzione MAP consente di gestire gli errori in modo particolare per ogni thread di un Replicat coordinato.

Utilizzo della gestione degli errori a livello di record

Tutte le opzioni REPERROR ad eccezione di TRANSDISCARD e TRANSEXCEPTION applicano un'azione di gestione degli errori in risposta a una singola operazione SQL su un singolo record. Altri record privi di errori nella stessa transazione vengono elaborati come configurati nelle istruzioni MAP e altri parametri nel file dei parametri, a seconda dei casi.

Utilizzo della gestione degli errori a livello di transazione

Le opzioni TRANSDISCARD, TRANSEXCEPTION e ABEND applicano un'azione di gestione degli errori a un'intera transazione. L'errore di attivazione può verificarsi in un singolo record nella transazione o nell'operazione di commit. Agli errori di commit non è associato alcun record particolare. Queste opzioni possono essere usate congiuntamente per:

TRANSDISCARD e TRANSEXCEPTION si escludono a vicenda.

Effetto di altri parametri sulle opzioni a livello di transazione

TRANSDISCARD e TRANSEXCEPTION rispettano i limiti della transazione di origine; tuttavia, la presenza di BATCHSQL, GROUPTRANSOPS o MAXTRANSOPS nel file dei parametri può influire sulla logica o sul risultato di gestione degli errori, poiché alterano i limiti della transazione.

Effetto di BATCHSQL e GROUPTRANSOPS

BATCHSQL o GROUPTRANSOPS (impostazione predefinita) raggruppano le operazioni SQL da transazioni diverse in transazioni più grandi per migliorare le prestazioni, mantenendo al contempo l'ordine transazionale. Quando questi parametri sono in vigore e si verifica un errore, Replicat tenta innanzitutto di risolverli inserendo una modalità di elaborazione alternativa (vedere la documentazione per tali parametri). Se l'errore persiste, TRANSDISCARD o TRANSEXCEPTION entra in vigore e Replicat torna alla modalità di elaborazione dell'origine come segue:

  1. Esegue il rollback della transazione raggruppata o arrayata.

  2. Riproduce la transazione in errore un'operazione SQL alla volta, utilizzando gli stessi limiti di transazione della transazione di origine.

  3. Esegue la logica di eliminazione (TRANSDISCARD) o il mapping delle eccezioni (TRANSEXCEPTION). (Vedere le descrizioni delle opzioni per ulteriori dettagli.)

  4. Riprende la modalità BATCHSQL o GROUPTRANSOPS al termine della gestione degli errori TRANSDISCARD.

Effetto di MAXTRANSOPS

L'integrità della gestione degli errori a livello di transazione TRANSDISCARD e TRANSEXCEPTION può essere influenzata negativamente dall'impostazione del parametro MAXTRANSOPS. MAXTRANSOPS fa sì che Replicat divida transazioni di origine replicate di grandi dimensioni in transazioni più piccole quando le applica sulla destinazione.

La logica TRANSDISCARD e TRANSEXCEPTION fa sì che Replicat esegua il rollback al primo record dopo l'ultimo commit riuscito. Questo può o non può essere l'inizio effettivo della transazione offensiva. Dipende dal fatto che la transazione sia stata frazionata e che parti di essa siano incluse nelle transazioni precedentemente impegnate. In tal caso, Replicat non può applicare l'azione TRANSDISCARD o TRANSEXCEPTION all'intera transazione così come è stata emessa nell'origine, ma solo alla parte di cui è stato eseguito il rollback dalla destinazione.

Se si utilizza MAXTRANSOPS, assicurarsi che sia impostato su un valore maggiore della transazione più grande che si prevede venga gestita da TRANSDISCARD e TRANSEXCEPTION. Ciò garantirà che le transazioni non vengano suddivise in transazioni più piccole sul target.

Effetto delle opzioni a livello di transazione sulle statistiche

L'output dei comandi informativi, ad esempio STATS REPLICAT, mostrerà il numero totale di record nella transazione elaborati dalla logica TRANSDISCARD o TRANSEXCEPTION. Questo numero può riflettere quanto segue:

Replicat interrompe gli errori causati dall'elaborazione degli elementi eliminati (TRANSDISCARD) o dal mapping delle eccezioni (TRANSEXCEPTION).

Recupero di ulteriori informazioni sulla gestione degli errori

Per ulteriori informazioni sulla configurazione della gestione degli errori per Extract e Replicat, vedere Gestisci errori nella documentazione dei microservizi di Oracle GoldenGate.

Per ulteriori informazioni sul parametro MAP, vedere "TABLE | MAP".

Predefinito

TRANSABORT per i deadlock; ABEND per tutti gli altri

Sintassi

REPERROR {
(
{DEFAULT | DEFAULT2 | <SQL_error> | <user_defined_error>},
{ABEND |
DISCARD |
EXCEPTION |
IGNORE |
RETRYOP [MAXRETRIES <n>] |
TRANSABORT [, MAXRETRIES] [, DELAYSECS <n> | DELAYCSECS <n>] |
TRANSDISCARD |
TRANSEXCEPTION
}
{PROCEDURE,[ABEND|IGNORE|DISCARD]}) |
RESET }

Opzioni specifica errori

DEFAULT

Imposta una risposta globale a tutti gli errori, ad eccezione di quelli per i quali sono state specificate istruzioni REPERROR esplicite.

DEFAULT2

Fornisce un'azione predefinita di backup quando la risposta per DEFAULT è impostata su EXCEPTION. Utilizzare DEFAULT2 quando non viene specificata un'istruzione MAP delle eccezioni per un'istruzione MAP per la quale si prevedono errori.

<SQL_error>

Numero di errore SQL. Questo può essere un errore a livello di record o un errore a livello di commit se si utilizzano TRANSDISCARD e TRANSEXCEPTION.

<user_defined_error>

Errore definito dall'utente specificato con l'opzione RAISEERROR di una clausola FILTER all'interno di un'istruzione MAP.

Opzioni risposta errore

ABEND

Esegue il rollback della transazione e interrompe l'elaborazione in modo anomalo. ABEND è l'impostazione predefinita.

DISCARD

Registra l'operazione non valida nel file di scarto, ma continua a elaborare la transazione e le transazioni successive.

EXCEPTION

Gestisce l'operazione che causa un errore come eccezione, ma elabora normalmente le operazioni esenti da errori nella transazione. Utilizzare questa opzione insieme a un'istruzione MAP delle eccezioni o per utilizzare l'opzione MAPEXCEPTION di MAP. Ad esempio, è possibile mappare le colonne da istruzioni di aggiornamento non riuscite in una tabella "Aggiornamenti mancanti". Nel file dei parametri, specificare l'istruzione MAP delle eccezioni dopo l'istruzione MAP per la quale è previsto l'errore.

EXCEPTION applica la gestione delle eccezioni solo a una singola operazione SQL su un singolo record. Per applicare la gestione delle eccezioni all'intera transazione, utilizzare l'opzione TRANSEXCEPTION.

Nota: quando la funzione di rilevamento e risoluzione dei conflitti (CDR) è attiva, considera automaticamente tutte le operazioni che causano errori come eccezioni se esiste un'istruzione MAP delle eccezioni per la tabella interessata. In questo caso, REPERROR con EXCEPTION non è necessario in quanto AUTOCDR non è compatibile con REPERROR e pertanto REPERROR verrà ignorato per le tabelle con AUTOCDR abilitato. Utilizzare REPERROR con altre opzioni per gestire i conflitti che CDR non è in grado di risolvere o per i conflitti che non si desidera gestire da CDR.

IGNORE

Ignora l'errore.

RETRYOP [MAXRETRIES <n>]

Riprova l'operazione non valida. Utilizzare l'opzione MAXRETRIES per controllare il numero di tentativi. Ad esempio, se una tabella non è estesa, RETRYOP con MAXRETRIES consente di aggiungere estensioni in modo che la transazione non riesca. Replicat termina dopo il numero specificato di MAXRETRIES.

TRANSABORT [, MAXRETRIES <n>] [, DELAYSECS <n> | DELAYCSECS <n>]

Interrompe la transazione e riposiziona all'inizio della transazione. Questa sequenza continua finché i record non vengono elaborati correttamente o finché MAXRETRIES non scade. Se MAXRETRIES non è impostato, l'azione TRANSABORT verrà eseguita in modo continuo.

Utilizzare una delle opzioni DELAY per ritardare il nuovo tentativo. DELAYSECS <n> imposta il ritardo in secondi e il valore predefinito è 60 secondi. DELAYCSECS <n> imposta il ritardo in centisecondi.

L'opzione TRANSABORT è utile per la gestione di timeout e deadlock nei database che supportano tali condizioni.

TRANSDISCARD

Elimina l'intera transazione di origine se qualsiasi operazione all'interno di tale transazione, inclusa l'operazione di commit, causa un errore Replicat elencato nella specifica di errore REPERROR. Replicat interrompe la transazione e, se l'errore si è verificato in un record, scrive il record nel file eliminato. Replicat quindi ripete la transazione e scrive tutti i record nel file di scarto, incluso il record di commit. Replicat interrompe gli errori causati dall'elaborazione degli scarti.

Se il record eliminato è già stato mappato ai dati in un record di destinazione, Replicat lo scrive nel file di scarto nel formato di destinazione; in caso contrario, verrà scritto in formato di origine. La transazione ripetuta è sempre scritta in formato sorgente.

TRANSDISCARD supporta gli errori a livello di record e gli errori di commit.

Ulteriori informazioni sono disponibili all'inizio di questo argomento.

TRANSEXCEPTION

Se si verifica un errore specificato con REPERROR in qualsiasi record di una transazione, esegue il mapping delle eccezioni per ogni record della transazione in base alla specifica di mapping delle eccezioni corrispondente, come definito da una clausola MAPEXCEPTION o EXCEPTIONSONLY in un'istruzione MAP delle eccezioni. Se un record non dispone di una specifica di mapping delle eccezioni corrispondente o se si verifica un errore durante la scrittura nella tabella delle eccezioni, Replicat viene interrotto con un messaggio di errore.

Quando si verifica un errore e si utilizza TRANSEXCEPTION, Replicat interrompe la transazione e, se l'errore si è verificato in un record, scrive il record nel file eliminato. Replicat ripete la transazione ed esamina i record di origine per trovare le specifiche di mappatura delle eccezioni, quindi le esegue.

TRANSEXCEPTION supporta gli errori a livello di record e gli errori di commit. Per gestire gli errori a livello di record (per singole operazioni SQL), senza influire sulle operazioni prive di errori nella stessa transazione, utilizzare l'opzione EXCEPTION in un'istruzione MAP.

PROCEDURE,[ABEND IGNORE DISCARD]

Utilizzare PROCEDURE per configurare il funzionamento di Replicat quando si verifica un errore di replica procedurale. Per impostazione predefinita, Replicat eseguirà il comando ABEND quando si verifica un errore di replica procedurale.

L'opzione IGNORE ignora la chiamata non riuscita. L'opzione DISCARD posiziona gli errori eliminati nella coda degli errori di applicazione nel database di destinazione. Questi errori possono essere rieseguiti o eliminati in un secondo momento.

RESET

Utilizzare un'istruzione REPERROR RESET per rimuovere le regole di gestione degli errori specificate nei parametri REPERROR precedenti e applicare la gestione degli errori predefinita a tutte le istruzioni MAP successive.

Esempi di utilizzo di REPERROR a livello globale

Questi esempi mostrano REPERROR utilizzato nella radice del file dei parametri per impostare le regole di gestione degli errori globali. È possibile sostituire una o tutte queste regole per una determinata tabella o tabella utilizzando REPERROR in un'istruzione MAP. Vedere "Esempi di utilizzo di REPERROR a livello globale e in un'istruzione MAP".

Esempio 1

L'esempio seguente mostra come interrompere l'elaborazione per la maggior parte degli errori, ma ignora gli errori dei record duplicati.

REPERROR (DEFAULT, ABEND)
REPERROR (-1, IGNORE)

Esempio 2

Nell'esempio seguente viene richiamata un'istruzione MAP delle eccezioni creata per gestire gli errori nella tabella dei conti. Gli errori nella tabella dei prodotti causano la fine anomala di Replicat perché non è stata definita un'istruzione MAP delle eccezioni.

REPERROR (DEFAULT, EXCEPTION)
REPERROR (DEFAULT2, ABEND)
MAP sales.product, TARGET sales.product;
MAP sales.account, TARGET sales.account;
INSERTALLRECORDS
MAP sales.account, TARGET sales.account_exception,
EXCEPTIONSONLY,
COLMAP (account_no = account_no,
optype = @GETENV ('lasterr', 'optype'),
dberr = @GETENV ('lasterr', 'dberrnum'),
dberrmsg = @GETENV ('lasterr', 'dberrmsg'));

Esempio 3

Di seguito vengono applicate le regole di errore per la prima istruzione MAP, quindi viene ripristinato il valore predefinito di ABEND per la seconda istruzione.

REPERROR (-1, IGNORE)
MAP sales.product, TARGET sales.product;
REPERROR RESET
MAP sales.account, TARGET sales.account;

Esempio 4

Di seguito viene ignorato il record non valido, quindi viene riprodotta l'intera transazione se un'operazione qualsiasi in un record al suo interno genera un errore 1403. Altri tipi di errore causano l'interruzione di Replicat.

REPERROR DEFAULT ABEND
REPERROR 1403 TRANSDISCARD

Esempio 5

Di seguito viene ignorato il record non valido, quindi viene riprodotta l'intera transazione per cercare una specifica di mapping delle eccezioni che scrive nella tabella delle eccezioni denominata tgtexception. Altri errori fanno sì che Replicat elimini il record offensivo (se applicabile) e quindi abbandoni.

REPERROR DEFAULT ABEND
REPERROR 1403 TRANSEXCEPTION
MAP src, TARGET tgt, &
MAPEXCEPTION (TARGET tgtexception, INSERTALLRECORDS, COLMAP (...) );

Esempi di utilizzo di REPERROR a livello globale e in una dichiarazione MAP

Gli esempi seguenti mostrano diversi modi in cui REPERROR può essere utilizzato in un'istruzione MAP insieme a un'istruzione REPERROR globale.

Esempio 1

REPLICAT <group_name>
REPERROR (<error1> , <response1>)
MAP <src1>, TARGET <tgt1>, REPERROR (<error1>, <response2>);
MAP <src2>, TARGET <tgt2>, REPERROR (<error2>, <response3>);

Nell'esempio precedente, quando si verifica error1 per la prima istruzione MAP, l'azione deve essere response2, non response1, poiché è stata specificata una sostituzione. Tuttavia, se si verifica un valore error1 per la seconda istruzione MAP, la risposta deve essere response1, ovvero la risposta globale. La risposta per error2 sarebbe response3, che è specifico di MAP.

Esempio 2

REPLICAT <group_name>
REPERROR (<error1> , <response1>)
MAP <src1>, TARGET <tgt1>, REPERROR (<error2>, <response2>),
REPERROR (<error3>, <response3>);

Nell'esempio precedente, quando si esegue la replica da src1 a src2, si dovrebbero applicare tutti gli errori e le azioni (da 1 a 3), poiché tutte le istruzioni REPERROR risolvono errori diversi (non esistono sostituzioni specifiche di MAP).

Esempio 3

REPLICAT <group_name>
REPERROR (<error1> , <response1>)
MAP <src1>, TARGET <tgt1>, REPERROR (<error1>, <response2>);
MAP <src2>, TARGET <tgt2>, REPERROR (<error2>, <response3>);
REPERROR (<error1> , <response4>)
MAP <src2>, TARGET <tgt2>, REPERROR (<error3>, <response3>);

Nell'esempio precedente, se si verifica error1 per la prima istruzione MAP, l'azione deve essere response2. Per la seconda sarebbe response1 (la risposta globale), e per la terza sarebbe response4 (a causa della seconda istruzione REPERROR). Un'istruzione REPERROR globale si applica a tutte le istruzioni MAP che la seguono nel file dei parametri finché un'altra istruzione REPERROR non avvia nuove regole.

Esempio 4

REPERROR DEFAULT ABEND
REPERROR 1403 TRANSDISCARD.
MAP src, TARGET tgt, REPERROR(600 TRANSDISCARD);

Nell'esempio precedente, se si verifica l'errore 600 durante l'applicazione della tabella di origine src alla tabella di destinazione tgt, l'intera transazione viene scritta per eliminare il file. Il rilevamento dell'errore 1403 comporta anche la stessa azione in base alla specifica REPERROR globale. Negli altri errori, il processo semplicemente scarta solo il record offensivo e poi si abbassa.