Recuperar uma carga de SQL Server para Oracle após a queda da VPN

Uma transferência entre bancos de dados morre quando a VPN cai, e «execute de novo» não é um plano de recuperação. A extração da origem pode estar concluída, o destino pode já ter feito commit, ou a resposta pode simplesmente ter se perdido no caminho de volta. Esses três estados exigem ações diferentes, e um cliente que só conhece «erro» não consegue distingui-los.

A correção é arquitetural: dê a cada execução uma identidade de lote durável e deixe os bancos de dados responderem às perguntas em vez de deixar o cliente adivinhar.

O que o banco de dados realmente garante

SQL Server e Oracle oferecem ambos atomicidade dentro de uma transação. Nenhum oferece atomicidade entre os dois. Uma conexão perdida não corrompe o banco de dados nem força um rollback manual, porque o servidor resolve a própria transação sem você. O que se rompe é o conhecimento do chamador sobre o resultado.

Commitado separadamente significa commitado separadamente. Uma VPN que transporta as duas conexões não funde dois commits em uma única unidade de trabalho.

O commit do qual você nunca ouviu falar

Um modo de falha pune a lógica de nova tentativa ingênua: o servidor faz commit, e a confirmação nunca chega ao chamador. O Oracle documenta isso como o problema do resultado desconhecido e fornece o Transaction Guard para isso na documentação de transações. Um erro de comunicação não é prova de que um commit enviado falhou, e tratá-lo como prova é como um lote é publicado duas vezes. A distinção importa mais no caminho de nova tentativa, onde o operador tem uma mensagem de erro e nenhum outro sinal para agir.

Portanto, a etapa de recuperação precisa ler o resultado no destino em vez de inferi-lo do texto do erro.

Dê uma identidade de lote à transferência

Cada execução recebe um identificador de lote imutável, e o destino registra o que fez com esse identificador. O ciclo de vida tem quatro etapas e parece o mesmo independentemente do fornecedor:

1. Extraia um lote de origem identificado e imutável com esquema e limite registrados.
2. Transfira-o para a área de preparação do destino e detecte conteúdo incompleto ou conflitante antes de declará-lo pronto.
3. Aplique-o sob as regras de unicidade ou bloqueio do próprio destino e registre a conclusão na mesma transação local.
4. Reconcilie o resultado durável pelo protocolo suportado antes de confirmar ou tentar novamente.

As novas tentativas reutilizam o identificador. Um novo identificador por tentativa anula a prevenção de duplicatas que você acabou de construir, o que parece óbvio até que um invólucro de nova tentativa gere um automaticamente.

O identificador também lhe dá algo com que reconciliar mais tarde, muito depois de o processo do cliente desaparecer.

Reivindique o lote e depois aplique

A etapa de aplicação deve reivindicar o identificador de lote, fazer as mudanças de negócio e registrar a conclusão em uma única transação local. Fazer a verificação e a inserção como instruções separadas reintroduz a corrida que você tentava remover. Se dois trabalhadores competem, exatamente uma reivindicação vence e o outro é informado.

Um registro de conclusão ausente não é prova de que uma transação em andamento nunca fará commit. A reivindicação precisa serializar as tentativas concorrentes, ou o protocolo precisa ler o resultado durável antes de decidir qualquer coisa.

Use o mecanismo suportado do banco de dados para essa serialização em vez de um laço de verificar-e-repetir no código da aplicação.

O que o projeto ainda não pode prometer

A preparação torna o trabalho reiniciável e reduz a dependência de uma única sessão de longa duração. Ela não cria um único commit atômico entre SQL Server, Oracle e qualquer efeito colateral externo que o trabalho realize. Se o negócio realmente precisa disso, projete e qualifique uma transação distribuída suportada ou um processo de reconciliação, incluindo quem é dono do trabalho com resultado incerto. Qualquer coisa mais fraca pertence a um runbook de reconciliação, não ao código de transferência.

Aceite a interrupção em três lugares: durante a transferência, durante a aplicação e após o commit mas antes da confirmação. Depois verifique o resultado de negócio em vez da mensagem do cliente, e deixe o livro de lotes dizer se o trabalho está incompleto, commitado ou ainda não resolvido.