Tratando Erros no BATCHSQL para Operações de Replicat do Google Spanner

Os seguintes erros são gerenciados pelo Replicat GoldenGate ao usar o BATCHSQL com o Google Spanner:

INSERT: Erro de chave duplicado
UPDATE/DELETE: Erro de linha não encontrada
Atualização da Chave Primária: erro de chave não encontrada e erro de nova Chave já existente

Se qualquer operação DML falhar com qualquer um desses erros, por padrão, a transação será abortada e o Replicat será encerrado. Se o usuário tiver ativado HANDLECOLLISIONS, OVERRIDEDUPS, INSERT_MISSING_UPDATES ou qualquer outra regra REPERROR, ele repetirá, ignorará ou modificará e, em seguida, executará o DML para resolver o erro.

Se qualquer operação DML falhar com qualquer outro erro, a transação será abortada e o processo Replicat será encerrado. Como alternativa, com base nas regras REPERROR, o Replicat aborta e repete toda a transação.

Um erro RESOURCE_EXHAUSTED no Cloud Spanner geralmente indica que o limite de transações foi excedido para o número de mutações ou o tamanho total da transação. Ocorreu um erro semelhante ao seguinte, sugerindo reduzir MAXTRANSOPS ou 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.

Usando a API Spanner Mutations

O parâmetro BATCHSQL USEMUTATIONS é necessário para aumentar a eficiência ao aplicar DMLs no Spanner, chamadas Mutações do Spanner.

Isso significa que ExecuteBatchDml é mais atraente para dados pré-implantados de carga inicial em que as operações são inserções predominantemente contíguas para a mesma tabela.

Para cargas de trabalho genéricas com DMLs mistas em tempo real, o modo BATCHSQL USEMUTATION fornece melhores métricas de desempenho.

Limitações Operacionais ao usar a opção USEMUTATIONS do BATCHSQL

As seguintes limitações existem ao usar Spanner Mutations:

Estatísticas de colisão : As estatísticas de colisão estão incompletas porque os resultados da mutação de tempo de commit não identificam quantas inserções efetivamente se tornaram atualizações, quantas atualizações de linha ausente efetivamente se tornaram inserções ou quantas operações de atualização/exclusão foram ignoradas.
Ações REPERROR no nível DML: As ações REPERROR não podem ser aplicadas a instruções DML individuais no modo BATCHSQL enquanto usam Mutações do Spanner porque o Spanner não retorna resultados no nível da instrução para mutações armazenadas em buffer e obtemos um erro para toda a transação no momento do commit.
Operações de Exclusão de linha ausentes: As operações de exclusão em linhas ausentes são ignoradas pela semântica DeleteMutation do Spanner, portanto, ao contrário de outros bancos de dados, o BATCHSQL com USEMUTATIONS sempre retornará sucesso no caso de operações de exclusão de linha ausentes.
Fallback para o modo Normal para Atualizações de PK: O processo Replicat volta ao modo normal; para qualquer transação que contenha uma atualização de Chave Primária, ela será repetida no modo clássico assim que encontrar a Atualização de PK.

Embora o comportamento da Mutação do Spanner não mude devido a essas limitações, ele pode causar degradação do desempenho.

Comportamento do Modo BATCHSQL com USEMUTATIONS

Veja a seguir um resumo de como cada modo BATCHSQL GoldenGate é mapeado para os tipos de mutação Spanner:

Caso padrão:

1,1 Inserções: A transação deve falhar no caso de inserções de chave duplicada e o erro é retornado apenas no momento do commit.

1,2 Atualizações: A transação deve falhar em caso de atualizações de linha ausentes e o erro é retornado apenas no momento do commit.

1,3 Exclui: Ignora a exclusão se a linha for NOT_FOUND
HANDLECOLLISIONS/OVERRIDEDUPS:

2,1 Inserções: Inserir deve ser convertido em uma Atualização no caso de um erro de chave duplicada e o erro é retornado apenas no momento do commit, e não teríamos nenhuma estatística de Colisão de Chave Primária.

2,2 Atualizações: As atualizações devem ser ignoradas em caso de erros de linha ausentes.
```
 **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 Exclui: DELETEMUTATION ignora a exclusão se a linha for NOT_FOUND.
Inserir Atualizações que Faltam:

3,1 Inserções: A transação deve falhar no caso de inserções de chave duplicada e o erro é retornado apenas no momento do commit.

3,2 Atualizações: A atualização deve inserir a linha em caso de erro de linha ausente e o erro é retornado apenas no momento do commit.