O que acontece quando uma atualização do SQL Server fica pela metade

Uma atualização cumulativa do SQL Server não é uma instalação: é uma migração do mecanismo e dos seus bancos de dados do sistema. Quando termina bem, ninguém fica sabendo. Quando é interrompida no meio —porque o serviço reiniciou, porque um disco encheu, porque um banco ficou em um estado que o script não esperava— o mecanismo inicia, começa a aplicar a mudança sobre o master, não consegue concluí-la e para. Visto de fora, tudo parece um serviço fora do ar. Visto de dentro, o mecanismo está fazendo exatamente o que lhe pediram: não deixar pela metade uma mudança estrutural.

Vivemos isso em um cliente do setor farmacêutico, em plena operação. A história completa está resumida em um caso publicado: o serviço voltou em quarenta minutos e o ambiente original foi reconstruído naquela mesma noite. O que segue é como se chega a essa decisão.

Primeiro: ler, não reiniciar

O primeiro impulso —reiniciar o serviço para ver se ele sobe— é o pior. Cada reinicialização volta a lançar o mesmo script de atualização, que volta a falhar no mesmo ponto e, de quebra, acrescenta ruído ao diagnóstico. Antes de tocar em qualquer coisa, é preciso ir ao log do servidor, o ERRORLOG do mecanismo, que fica na pasta LOG da instância e pode ser lido com qualquer editor mesmo que o serviço não esteja no ar.

Ali aparece a frase que organiza todo o resto. Uma atualização que não termina costuma deixar uma mensagem sobre o nível de script do banco master, com o número da etapa em que parou e o erro que a interrompeu. Esse número é o que importa: diz se o mecanismo ficou esperando espaço, se tropeçou em um objeto que alguém modificou à mão anos atrás ou se um banco de usuário ficou em recuperação e bloqueia o resto.

O que se verifica, em ordem

O último bloco do ERRORLOG, que diz em que etapa da atualização ela parou.
O espaço livre nas unidades de dados, de log de transações e do banco tempdb.
O estado de cada banco: se algum ficou em recuperação ou suspeito, a inicialização não vai terminar.
O Visualizador de Eventos do Windows, para saber se o serviço parou sozinho ou se algo o parou: uma reinicialização por atualização do sistema operacional, um agente de backup, uma política de grupo.

Segundo: decidir contra o relógio, não contra o orgulho

Com o diagnóstico em mãos aparece a pergunta real, e ela não é técnica: quanto vale cada minuto deste banco parado? Reparar o mecanismo no lugar pode levar vinte minutos ou três horas, e essa incerteza é o problema. Um diagnóstico honesto não diz “eu resolvo”; diz “ainda não sei quanto tempo leva”.

Por isso, quando existe uma réplica sincronizada e a operação está rodando, a decisão certa quase sempre é a mesma: fazer o failover. O serviço volta em um tempo delimitado e conhecido, a pressão desaparece, e o reparo do nó original deixa de ser uma emergência para se tornar um trabalho de janela noturna, com calma e com evidências.

É isso que faz uma réplica valer o que custa. Ela não está ali para um desastre de cinema: está ali para a terça-feira em que uma atualização fica pela metade.

Terceiro: reconstruir e deixar registrado

Com o serviço no ar na réplica, o nó original é reconstruído sem usuários: a atualização é concluída ou revertida, a integridade dos bancos é validada, a sincronização é restabelecida e se confirma que o conjunto voltou a ter dois nós saudáveis. O que não pode faltar depois é a análise do evento por escrito, com a causa, o tempo real de indisponibilidade e o que muda para a próxima vez.

O que evita que aconteça de novo

Janela de aplicação de patches com plano de reversão, comunicada antes, e não avisada depois.
Backup verificado imediatamente antes de aplicar a atualização, incluindo os bancos do sistema.
Atualizar primeiro o nó que não atende a operação, e fazer o failover só quando ele já estiver saudável.
Limites de espaço monitorados, para que o disco não seja a causa raiz de um incidente de banco de dados.

Nenhuma dessas quatro coisas é cara. A que sai cara é a outra: descobrir no meio do incidente que a réplica existia, mas que ninguém nunca tinha feito o failover para ela.

Se você quiser revisar como está a sua plataforma de dados, escreva para nós: o diagnóstico é delimitado e dele sai um mapa, não uma proposta de quarenta páginas.