Mises à jour cumulatives de MS SQL Server - Meilleures pratiques

J'essaie de me faire une idée des meilleures pratiques recommandées pour les mises à jour cumulatives SQL Server .

Actuellement, nous courons sur l'idée de "ne rien faire sauf si un problème résolu par la CU est celui que nous rencontrons". Cela fonctionne à partir d'une approche «si ce n'est pas cassé, ne le corrige pas», mais je me demande si c'est vraiment une bonne idée car tant de CU ont des améliorations de performances. Nous envisageons peut-être d'ajouter l'UC aux correctifs appliqués au cours de nos cycles de maintenance périodique un mois ou deux après la publication de l'UC.

Que font les autres et pourquoi?

Pour mettre à jour la question qui affecte les réponses ci-dessous, le 24 mars 2016, l'équipe SQL Server de Microsoft a annoncé qu'elle mettait à jour son modèle de maintenance . Microsoft recommande à tous les utilisateurs d'installer toutes les UC publiées après janvier 2016:

Depuis les versions de CU de janvier, ces messages d'avertissement ont été mis à jour, nous recommandons maintenant une installation proactive et continue des CU dès qu'elles seront disponibles. Vous devez prévoir d'installer une CU avec le même niveau de confiance que vous prévoyez d'installer les SP (Service Packs) à mesure qu'ils sont publiés. En effet, les CU sont certifiées et testées au niveau des SP. De plus, les données Microsoft CSS indiquent qu'un pourcentage important des problèmes des clients sont souvent résolus auparavant dans une CU publiée, mais pas appliqués de manière proactive. Plus encore, les CU contiennent une valeur ajoutée au-delà des correctifs. Ceux-ci peuvent également contenir des mises à jour de prise en charge, de journalisation et de fiabilité améliorant l'expérience globale.

En plus des mises à jour de messagerie et d'orientation, nous avons mis à jour le modèle d'acquisition CU.

Modifications de l'acquisition:

• Bien entendu, les UC sont traditionnellement mises à disposition sur le serveur «Hotfix» (accompagné du «langage de mise en garde» associé à un «QFE» ou un «Hotfix»). L'incohérence ici est que les CU ne sont plus des correctifs rapides vraiment simples. Les mises à jour incluses sont bien testées aux niveaux d'intégration individuelle et complète du système aujourd'hui.
• Par conséquent, nous plaçons désormais la dernière version de base de référence par CU prise en charge (2012 SP2 / SP3 et 2014 RTM / SP1 aujourd'hui) sur microsoft.com/downloads, tout comme pour les Service Packs actuels.
• De plus, nous publierons et maintiendrons bientôt toutes les UC dans le catalogue Windows Update pour faciliter l'acquisition et la distribution.
• Seuls les correctifs provisoires CU à la demande seront placés sur le serveur de correctifs à l'avenir
• Pour réduire les frictions, le téléchargement des UC depuis microsoft.com/downloads ne nécessitera pas de fournir / recevoir un e-mail et une URL
• Nous évaluons également l'offre de la dernière CU en tant que mise à jour facultative sur Microsoft Update, tout comme les Service Packs d'aujourd'hui.

Je suis un ardent défenseur de se tenir à jour avec la mise à jour cumulative la plus récente, mais seulement si votre cycle de test / AQ peut garantir des tests de régression complets et appropriés contre elle. Glenn Berry de SQLskills est également un partisan de cette approche .

La propre recommandation de Microsoft est de n'appliquer que les UC qui résolvent les problèmes qui vous affectent, bien qu'elles aient récemment assoupli cette position . Le problème est que vous pouvez être affecté par un ou plusieurs de ces problèmes et ne pas le savoir, ou vous pouvez être affecté demain même si cela ne vous a pas encore frappé. Allez-vous passer en revue et essayer de reproduire le problème derrière chaque correctif dans chaque CU pour votre branche? Allez-vous le faire en continu pour vous assurer que vous n'êtes toujours pas affecté?

Je serai très honnête: je n'ai jamais eu de problème pour appliquer une UC à mes instances. Et en fait, leur processus de publication de CU a été beaucoup plus fiable que le cycle de publication du Service Pack, et dans de nombreux cas (y compris le plus récemment avec SQL Server 2012 Service Pack 2 ), vous ne voulez pas appliquer le Service Pack avant le premier CU pour cette branche a été libéré de toute façon. Dans ce cas, il existe un correctif temporaire pour résoudre le problème qui n'a pas été résolu à temps pour créer le code du Service Pack, mais ce n'est pas toujours vrai.

Nous avions l'habitude de suivre les CU. Environ un mois après la sortie, nous les appliquions, que nous rencontrions ou non un problème corrigé par eux.

Cependant, après avoir rencontré un énorme problème, nous avons arrêté cette pratique. Dans notre cas, un service pack que nous avions installé a résolu un problème d'indexation de texte intégral que nous rencontrions. Quelques mois plus tard, l'une des UC a annulé ce correctif particulier. Cela a provoqué toutes sortes de problèmes pour nous qui ont nécessité pas mal de recherches pour comprendre ce qui s'est passé. Nous avons fini par coder un travail qui a ensuite été vissé quand une nouvelle CU a cassé quelque chose d'autre ... Résultat net: le serveur est réinstallé de fond en comble à un niveau SP / CU particulier et gelé.

Les performances de nos applications sont telles que nous ne sommes pas concernés par les nouvelles améliorations des performances SQL qui pourraient sortir, donc ce n'est pas un problème. En outre, les rapports et autres requêtes retirent systématiquement des résultats valides, de sorte que de nouveaux ajustements ne sont pas nécessaires. Ce qui signifie qu'il doit s'agir d'un problème de sécurité avant d'envisager d'appliquer une CU à ce stade.

Je suis entièrement d'accord avec Aaron: ne faites cela que si votre cycle de test / AQ peut le tester correctement . Et même alors, testez chaque petite facette de celle-ci avec des données réelles pour vous assurer qu'elles ne cassent pas quelque chose dont vous pourriez dépendre.