Tarefa SQL longa: mantenha-a em execução quando a VPN cai

A VPN cai vinte minutos depois do início de uma reconstrução de índice, o cliente SQL mostra uma conexão quebrada, e a pergunta óbvia não tem resposta nesse erro. A instrução terminou, foi revertida ou continuou sem você? Reconectar e reenviar é a pior das três opções, porque transforma um resultado incerto em dois possíveis. Mova o trabalho para algo com um proprietário durável antes da próxima janela.

O que o erro de conexão não conta

Um erro do lado do cliente descreve o cliente. Ele informa que o socket foi fechado, não o que o servidor fez com a transação. A instrução pode estar em execução ainda, pode ter sido confirmada pouco antes de o link morrer, ou pode ter sido revertida quando a sessão foi limpa. Os três produzem a mesma mensagem no seu portátil.

Só o estado do servidor pode resolver isso. Olhe lá antes de decidir qualquer coisa.

Entregue o trabalho a um proprietário do lado do servidor

Para trabalho que não precisa de alguém vigiando, deixe o host do banco de dados ser dono da execução. O SQL Server Agent executa tarefas sob demanda ou segundo um agendamento e registra cada execução, de modo que o ciclo de vida da tarefa é independente da sua sessão VPN. A identidade da tarefa precisa exatamente das permissões que a tarefa exige, não do contexto interativo completo de um administrador. Então o portátil inicia o trabalho e lê os resultados em vez de ser o processo que o mantém vivo.

EXEC msdb.dbo.sp_start_job @job_name = N'nightly-customer-reindex';

A disponibilidade do Agent depende da edição e do serviço que você implantou. Use o mecanismo que sua plataforma realmente oferece em vez de supor que este exista em toda parte.

Um host de salto perto do banco de dados encurta o caminho e vale a pena, mas não muda a questão da propriedade. A sessão ainda termina quando a rede termina. Use-o para observar, não para ser o que mantém o trabalho vivo.

Deixe um registro que a próxima sessão possa ler

Anote um nome de tarefa ou identificador, o banco de dados de destino e o resultado que você espera. Esse registro é o que permite que outra sessão, ou outra pessoa, responda à pergunta que o erro não conseguiu. Sem ele fica uma lembrança vaga de uma atualização e nenhuma forma de verificar.

EXEC msdb.dbo.sp_help_jobhistory @job_name = N'nightly-customer-reindex';

O histórico mostra resultado e tempo por etapa, o que é mais útil que um único sinalizador de sucesso. Para tarefas que alteram dados, acrescente também a verificação da própria aplicação: uma contagem de linhas, um checksum ou uma linha de status escrita pela tarefa. Dois registros independentes são o que torna uma nova tentativa segura, e o histórico de tarefas registrado é o primeiro deles.

Reconcilie antes de reenviar

Quando a conexão de observação desaparece, encontre a execução existente antes de iniciar outra. Leia os resultados das etapas e decida se o trabalho foi confirmado, concluído parcialmente ou nunca começou. Só então aplique a regra de nova tentativa definida pelo fluxo de trabalho, porque um reenvio às cegas pode duplicar uma carga ou falhar no meio do caminho pela segunda vez.

Mantenha o proprietário durável e o resultado inspecionável, e uma breve falha de acesso torna-se um incômodo em vez de um palpite. Esse é todo o objetivo do projeto: o trabalho deve sobreviver à conexão que o pediu.