Cumulative Update do SQL Server: como atualizar com segurança

Um Cumulative Update (CU) do SQL Server é o pacote acumulado de correções — de bugs, de segurança e, com frequência, de comportamento do otimizador — lançado pela Microsoft num ritmo regular para cada versão suportada. Desde o SQL Server 2017, ele é o único trilho oficial de manutenção: não existe mais Service Pack. Isso significa que um ambiente que nunca aplica CU não está apenas "sem as últimas novidades" — está rodando com bugs já documentados, e às vezes já explorados, que a própria Microsoft já corrigiu.

O que muda entre RTM, GDR e CU

Depois da instalação inicial (RTM), o SQL Server recebe dois tipos de atualização com propósitos diferentes. GDR (General Distribution Release) é reservado para correções de segurança críticas aplicadas sobre um baseline específico, sem acumular as demais correções do período — é o caminho mais conservador, usado por ambientes que querem só o mínimo necessário. CU acumula todas as correções lançadas até aquele ponto, incluindo as de segurança, e é o caminho que a Microsoft recomenda para a maioria dos ambientes: cada CU já contém tudo dos anteriores, então aplicar o mais recente da série é suficiente — não é preciso instalar CU por CU em sequência.

A confusão mais comum é achar que pular CUs "economiza risco". Na prática, o oposto costuma ser verdade: quanto mais CUs atrasados, maior o pacote de mudanças aplicado de uma vez quando a atualização finalmente acontece, e mais provável que alguma correção de segurança relevante tenha ficado exposta por meses.

Como descobrir a versão e o CU atual

Antes de planejar qualquer atualização, o ambiente precisa responder duas perguntas: qual build está rodando, e qual é o build do CU mais recente disponível para essa versão.

SELECT @@VERSION; SELECT    SERVERPROPERTY('ProductVersion')     AS ProductVersion,    SERVERPROPERTY('ProductLevel')       AS ProductLevel,      -- RTM, SP, ou CU    SERVERPROPERTY('ProductUpdateLevel') AS CU,                -- disponível a partir do SQL Server 2017    SERVERPROPERTY('ProductBuildType')   AS BuildType,    SERVERPROPERTY('Edition')            AS Edition;

O número retornado em ProductVersion é o que se compara contra a tabela de builds que a Microsoft mantém publicamente para cada versão do SQL Server. Essa comparação — build atual contra build do último CU — é o ponto de partida de qualquer decisão de manutenção, e vale rodar em todas as instâncias do ambiente, não só na que parece mais crítica. É comum um ambiente ter o servidor de produção relativamente em dia e as instâncias de homologação, relatórios ou instâncias secundárias de um Always On paradas há vários CUs.

Por que isso não é só sobre corrigir bugs

Ficar atrasado em CU custa em três frentes que raramente aparecem juntas numa única conversa, mas se somam:

Segurança. Boa parte dos CUs carrega correções para vulnerabilidades já divulgadas publicamente. Um ambiente parado em um build antigo não está apenas sem a correção — está anunciando, para quem souber consultar o build, exatamente quais falhas conhecidas ainda funcionam ali.

Suporte. Ao abrir um chamado de suporte com a Microsoft para um problema sério, a primeira pergunta costuma ser o build atual. Ambientes muitos CUs atrasados podem ser orientados a atualizar antes de qualquer investigação mais profunda — o que transforma um incidente em produção numa corrida contra o tempo para aplicar uma atualização não testada sob pressão, exatamente o cenário que uma cadência de manutenção normal evita.

Comportamento do otimizador e correções silenciosas. Vários CUs corrigem regressões de plano de execução, comportamento de estatísticas ou bugs específicos de cardinality estimation que não têm aviso nenhum até alguém pesquisar um sintoma específico e descobrir que já foi corrigido dois CUs atrás.

Antes de aplicar: o que checar

Um CU não deveria ser aplicado a partir do momento em que termina o download. Antes disso:

• Ler as notas da versão do CU específico, procurando por problemas conhecidos relacionados aos recursos realmente usados no ambiente — replicação, Always On, particionamento, Integration Services. A Microsoft documenta publicamente os known issues de cada CU.
• Confirmar que existe um backup completo recente e restaurável do banco de dados de sistema master e dos bancos de usuário, além de espaço em disco suficiente para o instalador e para os arquivos temporários que ele gera.
• Testar em um ambiente que não seja produção primeiro, mesmo que seja uma cópia restaurada rapidamente numa instância separada. Isso não elimina risco, mas troca uma surpresa em produção por uma surpresa controlada.
• Verificar o estado de saúde do ambiente antes de começar — jobs travados, réplicas de Always On fora de sincronia, ou um disco quase cheio tornam qualquer atualização mais arriscada do que precisa ser.
• Baixar o instalador apenas do canal oficial — Microsoft Update Catalog ou a página de downloads do SQL Server — nunca de um espelho de terceiros.

Como aplicar, na prática

Para uma instância standalone, o instalador do CU pode rodar em modo silencioso, o que facilita repetir o mesmo processo em várias instâncias sem depender de cliques manuais:

Start-Process -FilePath ".\SQLServer2022-KB xxxxxxx-x64.exe" `  -ArgumentList "/quiet /IAcceptSQLServerLicenseTerms /Action=Patch" `  -Wait

O parâmetro /quiet evita qualquer interface, /IAcceptSQLServerLicenseTerms é obrigatório em modo silencioso, e /Action=Patch direciona o instalador a atualizar a instância existente em vez de tentar uma nova instalação. Vale rodar primeiro com /qs (modo silencioso com barra de progresso visível) numa janela de teste, antes de automatizar com /quiet em produção.

Em um grupo de disponibilidade Always On, a sequência recomendada evita indisponibilidade: aplicar o CU primeiro nas réplicas secundárias, uma de cada vez, confirmando que cada uma volta a sincronizar antes de seguir para a próxima. Só depois de todas as secundárias atualizadas é que acontece o failover planejado para uma delas, e a instância que era primária — agora secundária — recebe o mesmo CU por último. Esse padrão mantém a aplicação servida durante quase todo o processo, com uma janela de indisponibilidade limitada ao tempo do failover em si.

Depois de aplicar: validar, não presumir

A instalação terminar sem erro não é a confirmação final. Depois de qualquer CU:

SELECT SERVERPROPERTY('ProductVersion') AS ProductVersion,       SERVERPROPERTY('ProductUpdateLevel') AS CU;

O build precisa bater exatamente com o esperado. Além disso, vale conferir o log de erros do SQL Server em busca de qualquer mensagem nova desde o reinício, confirmar que os jobs do SQL Server Agent voltaram a rodar, e — em ambientes com Always On — validar que todas as réplicas estão de volta a SYNCHRONIZED ou HEALTHY antes de considerar o processo concluído.

Se algo der errado

O SQL Server não oferece um caminho simples de "desinstalar" um CU e voltar ao build anterior de forma limpa e suportada na maioria dos cenários — tecnicamente existe uma opção de reparo em Programas e Recursos, mas não é o caminho recomendado para reverter produção sob pressão. Por isso o plano de contingência real precisa estar pronto antes de começar, não improvisado depois:

• Backup completo e testável do estado anterior, para restore em caso de problema grave.
• Em Always On, a réplica ainda não atualizada funciona como plano B natural — é por isso que a ordem de aplicação (secundárias primeiro, failover, depois a antiga primária) importa tanto quanto a atualização em si.
• Snapshot de VM ou do storage, quando a infraestrutura permite, como caminho de reversão mais rápido que um restore completo.

O custo de deixar para depois

Um ambiente que nunca teve uma cadência de manutenção definida tende a acumular CUs atrasados por anos, não por meses — e cada versão do SQL Server tem uma data de fim de suporte estendido definida pela Microsoft, a partir da qual nenhuma correção nova sai, nem mesmo para vulnerabilidades críticas. Um ambiente parado numa versão que já passou dessa data está permanentemente exposto a qualquer falha descoberta depois, sem caminho de correção oficial além de migrar para uma versão suportada.

A cadência mais comum entre ambientes bem mantidos não é aplicar todo CU no dia do lançamento — costuma ser manter uma folga curta e deliberada, como ficar no penúltimo CU disponível, dando tempo para que problemas eventuais apareçam relatados por outros ambientes antes de chegar ao seu. O que diferencia isso de simplesmente não atualizar é a intenção: uma decisão revisada periodicamente, não um esquecimento que se acumula.

Próximo passo

Descobrir o build atual de cada instância do ambiente, comparar contra o CU mais recente disponível e ler as notas de versão dos CUs pulados no caminho é o primeiro passo antes de agendar qualquer atualização. Isso se conecta diretamente com o que discutimos sobre validação de migração: aplicar um CU sem validar o resultado depois tem o mesmo risco de qualquer outra mudança de banco que só parece ter dado certo.

Para quem quer esse levantamento feito por quem acompanha builds de SQL Server no dia a dia, a H1 Data oferece um diagnóstico gratuito do ambiente SQL Server: mapeamento do build atual de cada instância, do quanto o ambiente está atrasado e do plano de atualização seguro para colocá-lo em dia.