Gestione degli errori in BATCHSQL per Google Spanner Replicat Operations

I seguenti errori sono gestiti da GoldenGate Replicat quando si utilizza BATCHSQL con Google Spanner:

INSERT: Errore chiave duplicata
UPDATE/DELETE: Errore riga non trovata
Aggiornamento chiave primaria: chiave non trovata, errore e nuova chiave già esistente

Se un'operazione DML non riesce con uno qualsiasi di questi errori, per impostazione predefinita la transazione viene interrotta e Replicat viene interrotto. Se l'utente ha abilitato HANDLECOLLISIONS, OVERRIDEDUPS, INSERT_MISSING_UPDATES o qualsiasi altra regola REPERROR, riprova, salta o modifica e quindi esegue il DML per risolvere l'errore.

Se un'operazione DML non riesce con un altro errore, la transazione viene interrotta e Replicat viene interrotto. In alternativa, in base alle regole REPERROR, Replicat interrompe e riprova l'intera transazione.

Un errore RESOURCE_EXHAUSTED in Cloud Spanner indica spesso che il limite di transazione è stato superato per il numero di mutazioni o la dimensione totale della transazione. Si verifica un errore simile al seguente, suggerendo di ridurre MAXTRANSOPS o BATCHTRANSOPS.

Error: Operation failed on Spanner database due to quota, session limit, or batch size limit error:

Poosible causes :
BATCH LIMIT: Transaction >80,000 mutations or >100 MiB
QUOTA LIMIT: Spanner API quota exhausted (rate-limited)
SESSION LIMIT: Max concurrent sessions (100,000+) exceeded

Action:
For BATCH LIMIT: Reduce batch size or reduce MAXTRANSOPS and restart Replicat.
For QUOTA LIMIT: Increase Spanner quota in Google Cloud Console and restart Replicat.
For SESSION LIMIT: Reduce concurrent sessions to the Spanner and restart Replicat.
Retry using REPERROR with TRANSABORT, MAXRETRIES 5, DELAYSECS 1 is suggested.

Utilizzo dell'API Mutazioni scanner

Il parametro BATCHSQL USEMUTATIONS è necessario per aumentare l'efficienza durante l'applicazione di DML in Spanner, chiamato Spanner Mutations.

Ciò significa che ExecuteBatchDml è più interessante per i seeddata di carico iniziale in cui le operazioni sono prevalentemente inserti contigui per la stessa tabella.

Per i carichi di lavoro generici con DML misti in tempo reale, la modalità USEMUTATION di BATCHSQL fornisce metriche di prestazioni migliori.

Limiti operativi durante l'utilizzo dell'opzione USEMUTATIONS di BATCHSQL

Le seguenti limitazioni esistono quando si utilizza Spanner Mutations:

Statistiche di collisione: le statistiche di collisione sono incomplete perché i risultati della mutazione del tempo di commit non identificano il numero di inserimenti effettivamente diventati aggiornamenti o il numero di aggiornamenti delle righe mancanti effettivamente diventati inserimenti o il numero di operazioni di aggiornamento/eliminazione saltate.
Azioni REPERROR a livello DML: le azioni REPERROR non possono essere applicate a singole istruzioni DML in modalità BATCHSQL durante l'utilizzo di Spanner Mutations perché Spanner non restituisce i risultati a livello di istruzione per le mutazioni inserite nel buffer e viene visualizzato un errore per l'intera transazione al momento del commit.
Operazioni di eliminazione righe mancanti: le operazioni di eliminazione nelle righe mancanti vengono ignorate dalla semantica Spanner DeleteMutation, pertanto, a differenza di altri database, BATCHSQL con USEMUTATIONS restituirà sempre risultati positivi in caso di operazioni di eliminazione righe mancanti.
Fallback alla modalità normale per gli aggiornamenti PK: Replicat torna alla modalità normale. Per qualsiasi transazione che contiene un aggiornamento della chiave primaria, verrà eseguito un nuovo tentativo in modalità classica non appena rileva un aggiornamento PK.

Anche se il comportamento di Spanner Mutation non cambia a causa di queste limitazioni, può causare un degrado delle prestazioni.

Comportamento della modalità BATCHSQL con USEMUTATIONS

Di seguito è riportato un riepilogo di come ogni modalità BATCHSQL GoldenGate viene mappata ai tipi di mutazione Spanner:

Caso predefinito:

1,1 Inserimenti: la transazione non riesce in caso di inserimenti di chiavi duplicate e l'errore viene restituito solo in fase di commit.

1,2 Aggiornamenti: la transazione non riesce in caso di aggiornamenti della riga mancante e l'errore viene restituito solo in fase di commit.

1,3 Elimina: Ignora eliminazione se la riga è NOT_FOUND
HANDLECOLLISIONS/OVERRIDEDUPS:

2,1 Inserti: l'inserimento deve essere convertito in un aggiornamento in caso di errore di chiave duplicata e l'errore viene restituito solo al momento del commit e non avremmo alcuna statistica PK Collision.

2,2 Aggiornamenti: gli aggiornamenti devono essere saltati in caso di errori della riga mancante.
```
 **NOTE:** Spanner locks the row for that specific primary key using Replicat transaction even if it does not exist, which means that Spanner would not allow any other transaction to INSERT that row until Replicat transaction is committed or aborted.  
 {: .infoboxnote}
```
2,3 Elimina: DELETEMUTATION ignora l'eliminazione se la riga è NOT_FOUND.
Inserisci aggiornamenti mancanti:

3,1 Inserimenti: la transazione non riesce in caso di inserimenti di chiavi duplicate e l'errore viene restituito solo in fase di commit.

3,2 Aggiornamenti: l'aggiornamento deve inserire la riga in caso di errore della riga mancante e l'errore viene restituito solo al momento del commit.