Tem havido alguma controvérsia em curso na comunidade do SQL Server sobre a sabedoria de instalar Service Packs (SP) e atualizações cumulativas (CU) para SQL Server. Existem várias posições básicas diferentes que as organizações normalmente tendem a assumir sobre esse assunto, conforme listado abaixo:
- A organização instala Service Packs e atualizações cumulativas regularmente
- A organização instala Service Packs, mas não instala atualizações cumulativas
- A organização não instala Service Packs ou atualizações cumulativas
O primeiro caso é uma organização que tentará manter-se razoavelmente atualizada com os Service Packs do SQL Server e as Atualizações Cumulativas do SQL Server usando um procedimento completo de teste e implementação. Esta é a melhor política na minha opinião. Minha posição é que sua organização é muito melhor atendida mantendo-se atualizada com os Service Packs e as Atualizações Cumulativas (desde que você tenha os procedimentos de teste e implementação e a infraestrutura necessária para dar suporte a essa política).
O segundo caso é uma organização que irá (talvez após algum atraso) instalar os Service Packs do SQL Server, mas não instalará as atualizações cumulativas do SQL Server por qualquer motivo. Isso não é tão bom quanto o primeiro caso, mas é muito melhor que o terceiro caso.
No terceiro caso, algumas organizações nunca instalam SQL Server Service Packs ou Atualizações Cumulativas do SQL Server, por qualquer motivo. Em alguns casos, eles realmente permanecem na versão original para fabricação (RTM) da versão principal do SQL Server que estão executando, durante a vida útil da instância. Esta é a política menos desejável, por uma série de razões.
A Microsoft tem uma política de desativação de ramificações de código (seja a ramificação RTM ou uma ramificação subsequente do Service Pack) para uma versão específica do SQL Server quando ela tiver duas ramificações. Por exemplo, quando o SQL Server 2008 R2 Service Pack 2 foi lançado, a ramificação RTM original (independentemente do nível de CU) foi desativada e se tornou um “service pack sem suporte”. Isso significa que não haverá mais hotfixes ou atualizações cumulativas para essa ramificação e que você terá suporte limitado para solução de problemas do Microsoft CSS durante um caso de suporte até instalar um service pack com suporte em sua instância.
Motivos pelos quais a manutenção do SQL Server é adiada
Em alguns casos, uma organização pode não estar ciente de como o SQL Server é normalmente atendido com uma combinação de Service Packs, Atualizações Cumulativas e Hotfixes. Muitas organizações têm políticas rígidas e de cima para baixo em vigor sobre como mantêm e prestam serviços a produtos como o SQL Server, que impedem a instalação regular de SPs e/ou CUs por administradores de banco de dados. Eles também podem ser impedidos de atender suas instâncias do SQL Server pelo fato de estarem usando bancos de dados de terceiros que são suportados apenas pelo fornecedor com determinadas versões especificadas pelo fornecedor e níveis de Service Pack do SQL Server.
Muitas organizações também têm um medo compreensível de “quebrar” uma instância do SQL Server ou um aplicativo que dependa dessa instância. Eles também podem não ter tempo e recursos para fazer um nível apropriado de teste de aplicativo e sistema após instalar uma compilação atualizada do SQL Server em uma instância em um ambiente de teste. Em alguns casos, eles podem não ter um ambiente de teste dedicado (o que é um grande problema separado).
Algumas organizações podem não ter uma solução funcional de alta disponibilidade (como clustering de failover tradicional, espelhamento de banco de dados ou grupos de disponibilidade) em seu ambiente de produção, por isso hesitam muito mais em fazer qualquer tipo de serviço que possa causar uma reinicialização do servidor de banco de dados e causar uma interrupção relativamente longa. Eles podem realmente ter uma solução de alta disponibilidade, mas raramente a testam com um failover de produção e podem ter menos confiança em seu funcionamento e confiabilidade.
Motivos para manter regularmente o SQL Server
Depois de listar alguns dos motivos comuns pelos quais as organizações podem optar por não atender regularmente ao SQL Server, é hora de abordar alguns desses argumentos. Primeiro, a ignorância sobre como o SQL Server é normalmente atendido pela Microsoft não é mais uma desculpa válida. A Microsoft tem um SQL Release Services Blog, onde eles anunciam Service Packs e Atualizações Cumulativas para SQL Server. Matthias Bernt explicou a estratégia geral de serviço para o SQL Server em sua postagem:Uma abordagem alterada para Service Packs, com mais detalhes sobre a abordagem do modelo de serviço incremental do SQL Server disponível neste artigo da base de conhecimento da Micosoft.
A versão condensada do modelo de serviço é que os problemas individuais do SQL Server são corrigidos com hotfixes. Você deve entrar em contato com o Microsoft CSS e abrir um caso de suporte para obter acesso a um hotfix individual (a menos que seja um hotfix relacionado à segurança, que é enviado pelo Microsoft Update). Dependendo do seu nível de suporte pago com a Microsoft, esse pode ser um processo relativamente tedioso e demorado. Há também o problema de que é muito improvável que a maioria dos clientes do SQL Server esteja ciente dos hotfixes existentes que não foram lançados como parte de uma atualização cumulativa do SQL Server. Isso significa que é improvável que a maioria dos clientes obtenha e implante hotfixes individuais regularmente.
Atualizações cumulativas são cumulativos de vários hotfixes (normalmente entre 10 e 50 hotfixes) que são lançados a cada oito semanas. Essas atualizações cumulativas são, na verdade, cumulativas (como o nome indica), portanto, você obterá todos os hotfixes lançados anteriormente para sua versão e ramificação (RTM, SP1, SP2 etc.) do código ao instalar uma atualização cumulativa. Isso significa que a declaração comum sobre as organizações “aplicando apenas atualizações cumulativas para corrigir problemas específicos que estão enfrentando” não é particularmente válida na vida real.
Por exemplo, se você estava executando a compilação RTM do SQL Server 2012 Service Pack 1 (11.0.3000) e decidiu instalar a atualização cumulativa 3 do SQL Server 2012 Service Pack 1 (11.0.3349) porque incluiu um hotfix para um problema que você estava realmente encontrando, você realmente estaria recebendo todos os hotfixes para SP1 CU1, SP1 CU2 e SP1 CU3, o que equivaleria a mais de 100 hotfixes.
Como a Microsoft afirma sobre atualizações cumulativas:“Como as compilações são cumulativas, cada nova versão de correção contém todos os hotfixes e todas as correções de segurança que foram incluídas na versão de correção anterior do SQL Server 2012 SP 1. Recomendamos que você considere aplicar a versão de correção mais recente que contém esse hotfix.” Basicamente, isso significa que, se você identificar um problema específico e relevante que foi corrigido em uma CU anterior, deverá seguir em frente e implantar a CU relevante mais recente no sistema (que também incluirá esse hotfix).
Um argumento que ouço com frequência sobre por que as organizações não implantam atualizações cumulativas é que "elas não são totalmente testadas por regressão como os Service Packs, portanto, não as implantamos". Há alguma validade nesse ponto de vista, mas também há um equívoco comum de que as atualizações cumulativas são apenas testadas por unidade, sem nenhum teste de regressão. Este não é o caso.
A documentação da Microsoft sobre atualizações cumulativas indica que, como elas “aplicam testes de regressão incremental durante todo o ciclo de desenvolvimento, seguidos por 2 semanas de testes focados dentro da janela de lançamento de 8 semanas, os processos de garantia de qualidade associados a CUs excedem os de hotfixes individuais”. Isso significa que, na verdade, você está assumindo menos riscos ao implantar uma CU que foi testada de regressão incremental e também teve duas semanas de testes focados do que se você implantasse um único hotfix que foi testado apenas por unidade.
Nos últimos seis a sete anos, implantei pessoalmente muitas, muitas atualizações cumulativas e Service Packs em um grande número de sistemas que executam o SQL Server 2005 até o SQL Server 2012, e ainda não encontrei nenhum problema importante. Também não ouvi falar de nenhum problema generalizado fazendo esse tipo de trabalho relatado em blogs, no Twitter etc. Pode ser que eu (e todos que conheço) tenhamos tido sorte, ou talvez Atualizações cumulativas e Service Packs não sejam exatamente tão arriscado quanto algumas pessoas acreditam (desde que você os teste e implante corretamente).
A importância de um plano de teste e implementação
A menos que você nunca planeje fazer qualquer tipo de manutenção do servidor ou atualizações de aplicativos durante a vida útil do seu sistema (o que parece uma proposta improvável), você realmente precisa desenvolver algum tipo de procedimento e plano de teste e implementação que você seguiria como parte de fazer qualquer tipo de alteração no servidor.
Esse plano pode começar relativamente simples, mas se tornará mais complexo e completo à medida que você se tornar mais experiente em atender regularmente suas instâncias do SQL Server e aplicar as lições aprendidas em cada implantação. Idealmente, você seguiria esse plano sempre que fizer uma alteração no sistema, mas isso pode não ser possível em todos os casos.
Aqui estão alguns passos iniciais e testes que devem ser incluídos neste tipo de plano.
- Instale o CU em uma máquina virtual de teste
- O CU é instalado sem problemas ou erros?
- A instalação do CU requer uma reinicialização do sistema?
- Todos os serviços relevantes do SQL Server são reiniciados após a instalação?
- O SQL Server parece funcionar corretamente após a instalação?
- Instale o CU em vários sistemas de desenvolvimento
- O CU é instalado sem problemas ou erros?
- A aparência do SQL Server funciona corretamente durante o uso diário normal?
- Seus aplicativos parecem funcionar corretamente durante o teste de unidade?
- Instale a UC em um ambiente de integração ou controle de qualidade compartilhado
- Você seguiu um plano de implementação específico e uma lista de verificação para a instalação?
- Todos os aplicativos que usam o SQL Server passam no teste de fumaça?
- Todos os aplicativos passam em algum teste automatizado disponível?
- Todos os aplicativos passam por testes funcionais manuais mais detalhados?
- Instale o CU em seu ambiente de produção
- Use uma estratégia de upgrade contínuo sempre que possível
- Use uma lista de verificação detalhada e passo a passo durante a implantação
- Atualize sua lista de verificação com itens perdidos e lições aprendidas
Conclusão
O que espero conseguir aqui é fazer com que mais profissionais de banco de dados comecem a adotar uma mentalidade em que realmente desejam manter regularmente suas instâncias do SQL Server, em vez de hesitar ou ter medo de fazê-lo. Isso pode envolver uma quantidade significativa de trabalho extra no início, pois você pode ter que convencer outras pessoas em sua organização a embarcar em seus planos. Você pode ter que pressionar outras partes da organização para desenvolver melhores planos de teste, e você terá que construir uma lista de verificação de implementação. Você também terá que obter autorização da empresa para janelas de manutenção (que devem ser relativamente curtas com atualizações contínuas), para que você possa realmente obter atualizações implantadas em seus sistemas de produção regularmente.
Em troca desse trabalho extra, você terá um sistema com melhor manutenção e menos probabilidade de ter problemas no futuro. Você estará em uma configuração totalmente compatível com a Microsoft e terá mais confiança em sua(s) tecnologia(s) de alta disponibilidade, já que você as exercitará regularmente. Você também ganhará uma experiência valiosa ao planejar e implementar tudo isso, o que melhorará suas habilidades de solução de problemas no futuro.
