Estou tentando ter uma ideia de quais são as práticas recomendadas para as atualizações cumulativas do SQL Server .
Atualmente, seguimos a ideia de "não fazer nada a menos que um problema resolvido pela UC seja um problema que enfrentamos". Isso funciona a partir de uma abordagem "se não está quebrado, não conserte", mas estou me perguntando se isso é realmente uma boa ideia, já que muitas das CUs têm aprimoramentos de desempenho. Estamos pensando em talvez adicionar o CU aos patches aplicados durante nossos ciclos de manutenção periódica um ou dois meses após o lançamento do CU.
O que os outros fazem e por quê?
Como uma atualização para a pergunta que afeta as respostas abaixo, em 24 de março de 2016, a equipe do SQL Server da Microsoft anunciou que estava atualizando seu modelo de serviço . A Microsoft recomenda que todos os usuários instalem todas as CUs lançadas após janeiro de 2016:
A partir dos lançamentos de CU de janeiro, essas mensagens de cuidado foram atualizadas, agora recomendamos a instalação proativa e contínua de CUs à medida que se tornam disponíveis. Você deve planejar a instalação de um CU com o mesmo nível de confiança que planeja instalar SPs (Service Packs) à medida que são lançados. Isso ocorre porque as UCs são certificadas e testadas no nível de SPs. Além disso, os dados de CSS da Microsoft indicam que uma porcentagem significativa dos problemas do cliente costuma ser abordada anteriormente em uma CU lançada, mas não aplicada de forma proativa. Mais ainda, os CUs contêm valor agregado além dos hotfixes. Eles também podem conter atualizações de capacidade de suporte, registro e confiabilidade, aprimorando a experiência geral.
Além das atualizações de mensagens e orientações, fizemos atualizações no modelo de aquisição da UC.
Alterações na aquisição:
- As UCs, é claro, têm sido tradicionalmente disponibilizadas no servidor “Hotfix” (acompanhadas pela “linguagem de advertência” associada a um 'QFE' ou 'Hotfix'). A inconsistência aqui é que os CUs não são mais simples hotfixes rápidos. As atualizações abrangidas são bem testadas nos níveis de integração do sistema individual e completo hoje.
- Portanto, agora estamos colocando o CU mais recente por linha de base suportada mainstream (2012 SP2/SP3 e 2014 RTM/SP1 hoje) em microsoft.com/downloads, assim como é feito para Service Packs hoje
- Além disso, em breve lançaremos e manteremos todas as CUs no Catálogo do Windows Update para facilitar a aquisição e distribuição
- Somente correções temporárias de CU 'sob demanda' serão colocadas no servidor de hotfix daqui para frente
- Para reduzir o atrito, o download de CUs de microsoft.com/downloads não exigirá o fornecimento/recebimento de um e-mail e URL
- Também estamos avaliando a oferta do CU mais recente como uma atualização opcional no Microsoft Update, assim como os Service Packs atuais
Sou um grande defensor de manter-se atualizado com a atualização cumulativa mais recente, mas apenas se o seu ciclo de teste/QA puder garantir testes de regressão completos e adequados contra ele. Glenn Berry, da SQLskills , também é um defensor dessa abordagem .
A própria recomendação da Microsoft é aplicar apenas CUs que corrigem problemas que afetam você, embora eles tenham afrouxado essa postura recentemente . O problema é que você pode ser afetado por um ou mais desses problemas e não saber, ou pode ser afetado amanhã, mesmo que ainda não o tenha atingido. Você vai passar e tentar reproduzir o problema por trás de cada correção em cada CU de sua ramificação? Você vai fazer isso continuamente para garantir que ainda não seja afetado?
Vou ser bem honesto: nunca tive problemas para aplicar qualquer CU às minhas instâncias. E, de fato, o processo de lançamento do CU tem sido muito mais confiável do que o ciclo de lançamento do service pack e, em muitos casos (incluindo mais recentemente com o SQL Server 2012 Service Pack 2 ), você não deseja aplicar o service pack até o primeiro A CU para essa ramificação foi liberada de qualquer maneira. Nesse caso, há um hotfix provisório para resolver o problema que não foi corrigido a tempo de criar o código do Service Pack, mas isso nem sempre é verdade.
Costumávamos acompanhar os UCs. Aproximadamente 1 mês após o lançamento, nós os aplicaríamos, quer estivéssemos enfrentando um problema corrigido por eles ou não.
No entanto, depois que nos deparamos com um grande problema, paramos com essa prática. No nosso caso, um service pack que instalamos corrigiu um problema com a indexação de texto completo que estávamos enfrentando. Alguns meses depois, um dos CUs reverteu essa correção específica. Isso causou todos os tipos de problemas para nós que exigiram bastante pesquisa para descobrir o que aconteceu. Acabamos codificando um trabalho em torno do qual mais tarde foi estragado quando uma nova CU quebrou outra coisa ... Resultado líquido: o servidor foi reinstalado do zero até um determinado nível de SP/CU e congelado.
O desempenho de nosso aplicativo é tal que não estamos preocupados com nenhum novo aprimoramento de desempenho SQL que possa surgir, portanto, isso não é um problema. Além disso, os relatórios e outras consultas estão consistentemente recuperando resultados válidos, portanto, quaisquer novos ajustes são desnecessários. O que significa que deve haver um problema de segurança antes de considerarmos a aplicação de uma CU neste momento.
Eu concordo totalmente com Aaron: faça isso apenas se o seu ciclo de teste/QA puder testá-lo adequadamente. Caso contrário, eu diria para ficar longe, a menos que corrija um problema que você realmente enfrenta. E mesmo assim, teste cada pequena faceta com dados reais para garantir que eles não quebrem algo do qual você pode estar dependendo.