Cumulative update, aplicar ou não, eis a questão!

Post bem controverso, vamos ver no que vai dar…

Tudo começou com a seguinte pergunta: "Amigos, vocês recomendam um cliente a aplicar Cummulative Updates no SQL Server se não for por um erro encontrado?"

A resposta padrão para essa pergunta é NÃO, inclusive se você ler os textos dos cumulative updates (vulgo CUs) vai encontrar frases como essa: "This cumulative package is intended to correct only the problems that are described in this article. Apply it only to systems that are experiencing these specific problems". E nós, consultores, não podemos levianamente sugerir a aplicação de um fix sem analisar todo o cenário, então por segurança, muitos vão responder NÃO.

Dito isso, deixo minha opinião: eu sugiro que sua empresa crie a rotina de aplicar frequentemente CUs em produção, mesmo que você não tenha registro de problemas que são corrigidos por um CU específico.

Estou louco? Talvez, e se eu disser que acredito que o principal motivo para fazer isso é cultural?
Vamos as minhas justificativas…


CULTURA

Comparado a frequência de atualização de uma aplicação web, banco de dados é um componente bem mais estático, que sobre menos atualização. Se considerarmos que o tempo entre o service pack 1 (onde normalmente acontece a adoção do produto no Brasil) e o service pack 2, usualmente são quase 2 anos de espera, então sua equipe pode ficar aproximadamente 2 anos sem aplicar um fix em produção.

Por curiosidade, datas de lançamento de SPs do SQL Server 2012: SP1 (Novembro 2012) e SP2 (Junho de 2014).

Ótimo você pensa, isso é uma bela estabilidade! Sim, mas agora vamos a um índice que criamos na Nimbus e eu cito muito em minhas aulas: IPM ou Índice do Potencial Merdístico. Isto é, dependendo do que você está fazendo, o IPM indica quão grande é o potencial de dar alguma merda no que você está fazendo.

Vamos a uma situação hipotética…

E se o deploy de uma nova aplicação ou uma implementação de novo recurso faz com que um bug seja encontrado em produção, com resolução documentada em um CU ou SP?
Sua equipe vai ter que usar uma janela de noite no meio da semana para aplicar a correção. Ok, só um detalhe, coincidentemente nosso DBA sênior está de férias na Austrália (Murphy é um FDP mesmo!), então vamos com nosso DBA júnior… Mas o último fix que aplicamos faz 2 anos, como é mesmo o processo? E o backup? Foi feito no fim de semana, mas ainda não deu tempo de testar, então vamos torcer para ele estar íntegro (se esse Murphy aparecer aqui eu quebro ele na porrada)… E como uma grande fila de dominó, seu IPM vai aumentando, e junto com ele os riscos de sua organização. No fim pode dar tudo certo, mas e se não der????

O que acontece em uma organização que aplica regularmente os CUs…

Hoje a cadência de release dos CUs é em torno de 2 meses, então vamos supor que sua equipe espera 1 mês do lançamento do CU, aplica em desenvolvimento, semana seguinte em teste integrado, depois em homologação, chegando finalmente em produção na quarta semana, que quase coincide com o lançamento do próximo CU (1 mês + 4 semanas de aplicação da correção).

O que vai acontecer na organização:

    • Seu DBA sênior vai trabalhar nas primeiras rotações da implementação, afinal é um profissional responsável, e vai cuidando das aplicações do fix. Só que isso não é viável para sua organização, que não quer ficar pagando hora extra para seus funcionários mais caros, e provavelmente seu sênior não quer ficar trabalhando todo fim de semana, mas sim investir seu tempo em algo mais útil e ter tempo com a família. Resultado:
  - Seu DBA sênior vai começar a trabalhar na documentação e automatização da rotina (powershell ou algum shell script), criando algo mais profissional e sólido, diminuindo o risco humano das operações (que normalmente é o que aumenta bem o IPM).
  - Com o tempo quem vai cuidar dessas aplicações é o DBA júnior, que está aprendendo e no início de carreira,  que consegue fazer a rotina sem dificuldade e não vai estar em apuros quando o DBA sênior estiver viajando.
  • Em algum momento uma aplicação de fix no fim de semana vai dar problema e sua equipe vai ter que trabalhar para contornar a situação.
  - É melhor que isso aconteça em um período controlado onde você se organizou, está descansado e potencialmente tem uma janela de manutenção maior ou menor impacto em produção, caso do serviço ficar fora do ar por mais tempo que o planejado.
  - Sua equipe vai investir mais tempo trabalhando em uma estratégia para contornar os potenciais problemas e ser mais eficiente em caso de desastre. Esse estímulo e aprendizado pode trazer um retorno imenso para a organização quando o problema atinge seu ambiente em horários críticos.
  • Sua equipe também vai pensar em alternativas de alta disponibilidade, que podem ter sido relegadas para segundo plano (por N motivos), ou vai ficando cada vez mais confortável com as operações, conhecendo tempos de movimentação de recursos, detalhes da rotina, análise de logs, etc.
    • Sua equipe cria a cultura de acompanhar os releases, revisar os fixes e, invariavelmente vai aprender alguma coisa só de ler as referências dos KBs.
  - Curiosamente nos últimos anos tive a experiência de acompanhar mais o fixes do DB2 do que tinha com o SQL Server, e aprendi muito com essa prática, então também estou adotando para o SQL Server.

E falo isso de experiência própria… Recentemente passei por isso com o DB2, pude aplicar os primeiros fixes como se fosse um júnior, criamos uma documentação madura e um passo a passo excelente, a equipe já sabia como lidar com problemas comuns e tempo médio das operações, deixei de trabalhar de madrugada para aplicar fix e estávamos caminhando para no futuro automatizar nossos processos. De quebra já sugerimos deixar uma infraestrutura mínima e ajustada, para subir rapidamente novos bancos de dados se necessário.
E se um fix der problema na madrugada de sábado? Ai pode me acordar e no papel de consultor ou DBA Sênior, vou lá ajudar a resolver a bagaça…


SEM PROBLEMA NO AMBIENTE

O argumento do "se não tem problema" não aplique o CU tem fundamento pelo aspecto de estabilidade.
Mas vamos a outras situações hipotéticas, usando como referência o Cumulative Update package 7 for SQL Server 2012 Service Pack 2: https://support.microsoft.com/en-us/kb/3072100.

    • FIX: Indexed view returns incorrect result after insert or delete operation on the base table in SQL Server 2012 (https://support.microsoft.com/en-us/kb/3068439)
        - Ok, correção importante, mas se ninguém reclamou então não deve estar acontecendo no nosso ambiente… Mas e se estiver? Você executou selects em todas as views indexadas e foi validar o resultado para saber que não está com o problema? Se existem relatórios que usam sua view indexada e está distribuindo valores incorretos, os usuários podem somente notar daqui a alguns dias ou quem sabe no próximo mês.
        - Ou então você implementa uma nova view indexada e o resultado começa a dar errado, o que fazer? Tirar a funcionalidade do ar até sua janela de manutenção ou aplicar o fix no meio da semana?

  • FIX: Hash or merge join hints may be ignored when you execute a query in SQL Server 2012 (https://support.microsoft.com/en-us/kb/3064454)
        - Você encontrou um plano ruim e o QO não está te ajudando. Usa um serviço de consultoria e o Fabiano diz: coloca essa hint que o plano vai brilhar. Você faz o ajuste e nada… bug no SQL Server. Resolução aplicar o fix… quando? Está preparado? Mesma ladainha.
  - Só que esse camarada ainda tem uma coisa muito importante, trace flag 4199, que muita gente não sabe da existência mas deve ser entendido e tratado com carinho, ainda mais que o comportamento padrão da engine vai mudar no SQL Server 2016 (https://support.microsoft.com/en-us/kb/974006). Aí você resolve ir na cara e na coragem e habilita o TF 4199 sem teste e no meio da semana… Olha o IPM aumentando aí!!!!
            - Esse trace flag é importante e merece um post dedicado! Estou escrevendo e em breve estará no blog.

• FIX: CMEMTHREAD waits occur when you execute many ad hoc queries in SQL Server 2012 (https://support.microsoft.com/en-us/kb/3074425)
  - Sua empresa comprou uma nova aplicação, que passou por homologação e funcionou tudo bem, pois não tinha massa crítica para ressaltar o problem. Chegou em produção e lambou tudo logo na manhã de segunda-feira.
  - Resolução é aplicar o fix… quando? Está preparado? (Isso está ficando repetitivo…).

A fragilidade do argumento de não aplicar o fix se não têm problema é que você não consegue efetivamente testar todas as condições (até porque alguns KBs podem ser bem superficiais), e lembrando que o CU é cumulativo, então se você vai aplicar o CU #5 tem que revisar todos os outros também.

Soma-se a evolução das aplicações e funcionalidades adotadas, pode ser que na próxima semana um novo recurso colida com um bug já documentado e corrigido 4 CUs atrás… Eu não gostaria de esbarrar com um bug de corrupção de dados que já foi corrigido em um CU anterior.

RISCOS

É claro que não sou um idiota para achar que não existem riscos, sim eles existem.
E pode ser que você vá enfrentá-lo hoje ou daqui a três meses quando precisar aplicar o CU por conta de outro problema, então você precisa estar preparado.

Em uma pesquisa rápida na internet encontrei um caso de um DBA onde um CU voltou um comportamento antigo do SQL Server, que havia sido corrigido por um SP antigo, e trouxe problemas para a equipe que acabou por reinstalar o SQL Server (só faltou ele dar mais detalhes do CU e SP, então comento aqui mesmo correndo o risco de ser uma análise errada do DBA). E é uma pena, talvez pudesse ter passado sem essa, ou quem sabe estar calejado e conseguido colocar o banco no ar com maior agilidade.

E isso leva ao próximo ponto que muitos argumentam: comparativo de "qualidade" do cumulative update e service pack.

CU vs. SP

Outro ponto contra os CUs é que a bateria de testes executadas contra eles são menores que os SP.
Mesmo existindo pequenas diferenças entre os testes de CU/SP, houve uma grande melhoria dos testes dos CUs e a infraestrutura atual suporta testes de regressão em CUs, da mesma forma que acontece com o SP, então no que toca os "grandes pontos" dos testes, CU e SP passam pela mesma bateria.

DESEJO 

Meu desejo real é que a Microsoft passasse a indicar formalmente a aplicação dos CUs, incluindo além de correção de bugs novas funcionalidades para a engine (o que já aconteceu!), permitindo que eu não tenha que esperar alguns anos ou uma nova versão por uma melhoria que poderia estar disponível hoje.
Acredito que esse modelo esteja muito mais alinhado com a tendência de releases constantes que estamos vendo acontecendo ao redor do mundo e, uma hora ou outra, teremos que nos ajustar.

A cultura de constante atualização também vai forçar que isso se espalhe pela organização, inclusive para os desenvolvedores que vão ter que acabar por melhorar seus testes (tenho outro "causo" que lembrei, mas esse post já está gigante :-) ).
Isso também pode te ajudar a evitar manter pequenos fantasmas no futuro, afinal tem gente administrando SQL 7.0 e 2000 em pleno ano de 2015. E uma vez que sua empresa está nesse modo de operação, também vai cobrar de seus fornecedores para acompanhar: "Tem uma aplicação de terceiro que exige modo de compatibilidade 2000, então não consigo migrar….".

SENDO REALISTA

Não são todas as equipes que estão preparadas para esse modelo, afinal ainda temos centenas de DBAs acidentais de SQL Server administrando (como podem) o seu ambiente. Então simplesmente sumir com o Service Pack não é algo viável, pois é um marco para muitas empresas.
Service packs e CUs podem ter bugs e trazer problemas, já vimos isso acontecer, então NÃO estou recomendando aplicar o fix no dia seguinte a sua liberação (a MS já tem um histórico sobre isso), por isso recomendo esperar pelo menos um mês para começar seu processo de atualização.

Com a cadência de release de 2 em 2 meses fica muito difícil acompanhar os CUs, então que tal começar de quatro em quatro meses?

IMPORTANTE: Sou um profissional e bancos de dados não devem ser tratados levianamente, e você deve fazer o mesmo. Estude, acompanhe, leia as alterações, entenda o que está sendo aplicado e trate com muito zelo o seu ambiente, pois um DBA despreparado pode causar a falência de uma empresa. Então TESTE, TESTE e TESTE, melhorando sempre todo seu ciclo de deployment.


CONCLUSÃO

Mesmo remando contra a maré, eu acredito que os benefícios de constantemente aplicar os CUs ultrapassam de longe os riscos de se ter uma cultura reativa.

Processos melhores, documentação e automatização, equipe mais preparada, datas controladas para fazer as atualizações, melhor integração com outras áreas, tudo isso faz com que sua equipe e organização amadureçam se tornem mais profissionais.

Claro que não é simples, você vai comprar brigas, vai ter que aprender a se dar bem com o desenvolvedor FDP, que também acha você um DBA FDP e babaca (quem sabe vocês não viram best friends!!) e isso não vai acontecer da noite para o dia. Mas sair da zona de conforto pode te fazer um bem danado e no longo prazo vai favorecer para que fique cada vez menor o IPM da sua equipe de DBAs e dos bancos de dados.

Agora se você prefere esperar o problema acontecer no meio da segunda feira após recebimento dos salários, com movimentações críticas acontecendo, fazer um processo que você não está acostumado, notar que no FDS o backup falhou e aplicar o fix torcendo para que tudo dê certo… É sua escolha. E prometo que vou acender uma vela por você!

PS: descobri também que não estou sozinho, lendo um thread vi que Aaron Bertrand e Glenn Berry também são a favor, inclusive o Glenn já escreveu sobre isso (http://sqlperformance.com/2013/03/system-configuration/sql-server-servicing).

PPS: já estou ouvindo piadinhas com o acrônimo "CU", mas em um post desse tamanho não tinha como deixar de usar as duas letras juntas...

====================== UPDATE 2016-03-29 =====================

A Microsoft agora recomenda que você proativamente aplique os CUs e não somente os Service Packs. Detalhes aqui: https://blogs.msdn.microsoft.com/sqlreleaseservices/announcing-updates-to-the-sql-server-incremental-servicing-model-ism/

============================================================

Abraços

Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br