Atualizações cumulativas do MS SQL Server - Práticas recomendadas

Estou tentando ter uma idéia de quais são as práticas recomendadas para as atualizações cumulativas do SQL Server .

Atualmente, corremos com a idéia de "não fazer nada, a menos que um problema corrigido pela UC seja um que experimentamos". Isso funciona com uma abordagem "se não está quebrado, não conserte", mas estou me perguntando se isso é realmente uma boa ideia, pois muitas das UCs ​​têm aprimoramentos de desempenho. Estamos pensando em adicionar a UC às correções aplicadas durante nossos ciclos de manutenção periódica um mês ou dois após o lançamento da UC.

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 UCs ​​lançadas após janeiro de 2016:

Desde as versões de CU de janeiro, essas mensagens de aviso foram atualizadas, agora recomendamos a instalação proativa e contínua de CUs assim que estiverem disponíveis. Você deve planejar instalar uma UC com o mesmo nível de confiança que planeja instalar SPs (Service Packs) quando eles forem lançados. Isso ocorre porque as UCs ​​são certificadas e testadas no nível de SPs. Além disso, os dados do CSS da Microsoft indicam que uma porcentagem significativa de problemas do cliente geralmente é tratada anteriormente em uma UC liberada, mas não é aplicada proativamente. Além disso, as UCs ​​agregam valor além dos hotfixes. Isso também pode conter atualizações de suporte, log e confiabilidade, melhorando 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, são tradicionalmente disponibilizadas no servidor “Hotfix” (acompanhado pelo “idioma de advertência” associado a um 'QFE' ou 'Hotfix'). A inconsistência aqui é que as UCs ​​não são mais simples hotfixes rápidos. As atualizações abrangidas são bem testadas nos níveis individual e de integração total do sistema atualmente.
• Portanto, agora estamos colocando a CU mais recente por linha de base suportada pelo mainstream (2012 SP2 / SP3 e 2014 RTM / SP1 hoje) em microsoft.com/downloads, assim como é feito nos 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 provisórias de CU 'On-Demand' serão colocadas no servidor de hotfix em frente
• Para reduzir o atrito, o download de CUs no site microsoft.com/downloads não exigirá o fornecimento / recebimento de um email e URL
• Também estamos avaliando a oferta da CU mais recente como uma atualização opcional no Microsoft Update, assim como os Service Packs hoje

Sou um grande defensor de manter a atualização cumulativa mais recente, mas apenas se o seu ciclo de teste / controle de qualidade puder garantir testes de regressão completos e adequados contra ele. Glenn Berry, da SQLskills, também é um defensor dessa abordagem .

A recomendação da própria Microsoft é aplicar apenas as UCs ​​que corrigem problemas que afetam você, embora elas tenham afrouxado essa postura recentemente . O problema é que você pode ser afetado por um ou mais desses problemas e não o conhece, ou pode ser afetado amanhã, mesmo que ainda não o tenha atingido. Você vai tentar reproduzir o problema por trás de cada correção em cada CU da sua filial? Você fará isso continuamente para garantir que ainda não seja afetado?

Serei sincero: nunca tive problemas ao aplicar CU às minhas instâncias. Na verdade, o processo de lançamento da CU tem sido muito mais confiável que o ciclo de lançamento do service pack e, em muitos casos (inclusive mais recentemente com o SQL Server 2012 Service Pack 2 ), você não deseja aplicar o service pack até o primeiro A UC para essa ramificação foi lançada 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 as UCs. Aproximadamente 1 mês após o lançamento, os aplicaríamos independentemente de estarmos enfrentando um problema corrigido por eles ou não.

No entanto, depois que tivemos um grande problema, paramos 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, uma das UCs reverteu essa correção específica. Isso causou todo tipo de problema para nós, que exigiu bastante pesquisa para descobrir o que aconteceu. Acabamos codificando um trabalho em torno do qual mais tarde foi danificado quando uma nova UC quebrou outra coisa ... Resultado líquido: o servidor foi instalado do zero até um determinado nível de SP / CU e congelado.

Nosso desempenho do aplicativo é tal que não estamos preocupados com novos aprimoramentos de desempenho do SQL que possam surgir, então isso não é problema. Além disso, os relatórios e outras consultas estão constantemente recuperando resultados válidos, portanto, novos ajustes são desnecessários. O que significa que deve ser um problema de segurança antes de considerarmos aplicar uma UC no momento.

Concordo plenamente com Aaron: só faça isso se o seu ciclo de teste / controle de qualidade puder testá-lo adequadamente. Caso contrário, diria ficar claro, a menos que corrija um problema que você realmente enfrenta. E mesmo assim, teste cada faceta dele com dados reais para garantir que eles não quebrem algo de que você possa estar dependendo.