Il y a eu une controverse en cours dans la communauté SQL Server sur la sagesse d'installer les Service Packs (SP) et les mises à jour cumulatives (CU) pour SQL Server. Il existe plusieurs positions de base différentes que les organisations ont généralement tendance à adopter sur ce sujet, comme indiqué ci-dessous :
- L'organisation installe régulièrement des Service Packs et des mises à jour cumulatives
- L'organisation installe les Service Packs, mais n'installe pas les mises à jour cumulatives
- L'organisation n'installe pas de Service Packs ni de mises à jour cumulatives
Le premier cas est une organisation qui essaiera de rester raisonnablement à jour avec les Service Packs SQL Server et les mises à jour cumulatives SQL Server en utilisant une procédure de test et de mise en œuvre approfondie. C'est la meilleure politique à mon avis. Ma position est que votre organisation est bien mieux servie en restant à jour avec les Service Packs et les mises à jour cumulatives (tant que vous avez les procédures de test et de mise en œuvre et l'infrastructure requise en place pour prendre en charge cette politique).
Le deuxième cas est une organisation qui installera (peut-être après un certain délai) les Service Packs SQL Server, mais n'installera pas les mises à jour cumulatives SQL Server pour une raison quelconque. Ce n'est pas aussi bon que le premier cas, mais c'est bien mieux que le troisième cas.
Dans le troisième cas, certaines organisations n'installent jamais de Service Packs SQL Server ou de mises à jour cumulatives SQL Server, pour quelque raison que ce soit. Dans certains cas, ils restent en fait sur la version d'origine de la version de fabrication (RTM) de la version majeure de SQL Server qu'ils exécutent, pendant toute la durée de vie de l'instance. C'est la politique la moins souhaitable, pour un certain nombre de raisons.
Microsoft a pour politique de supprimer des branches de code (soit la branche RTM, soit une branche Service Pack ultérieure) pour une version particulière de SQL Server lorsqu'elle a deux branches. Par exemple, lorsque SQL Server 2008 R2 Service Pack 2 a été publié, la branche RTM d'origine (quel que soit le niveau CU) a été retirée et est devenue un « service pack non pris en charge ». Cela signifie qu'il n'y aura plus de correctifs ou de mises à jour cumulatives pour cette branche, et que vous n'obtiendrez qu'un support de dépannage limité de Microsoft CSS pendant un cas de support jusqu'à ce que vous installiez un service pack pris en charge sur votre instance.
Raisons pour lesquelles la maintenance de SQL Server est différée
Dans certains cas, une organisation peut ne pas savoir comment SQL Server est normalement entretenu avec une combinaison de Service Packs, de mises à jour cumulatives et de correctifs. De nombreuses organisations ont mis en place des politiques rigides et descendantes sur la façon dont elles entretiennent et entretiennent des produits comme SQL Server, ce qui empêche l'installation régulière de SP et/ou de CU par les administrateurs de base de données. Ils peuvent également être empêchés de desservir leurs instances SQL Server par le fait qu'ils utilisent des bases de données tierces qui ne sont prises en charge que par certains fournisseurs et niveaux de Service Pack de SQL Server.
De nombreuses organisations ont également une peur compréhensible de "casser" soit une instance SQL Server, soit une application qui dépend de cette instance. Ils peuvent également manquer de temps et de ressources pour effectuer un niveau approprié de test des applications et du système après l'installation d'une version mise à jour de SQL Server sur une instance dans un environnement de test. Dans certains cas, ils peuvent ne pas disposer d'un environnement de test dédié (ce qui est un problème majeur distinct).
Certaines organisations peuvent ne pas disposer d'une solution de haute disponibilité fonctionnelle (telle que le clustering de basculement traditionnel, la mise en miroir de bases de données ou les groupes de disponibilité) en place dans leur environnement de production. Elles hésitent donc beaucoup plus à effectuer tout type de maintenance susceptible de causer un redémarrage du serveur de base de données, et provoquer une indisponibilité relativement longue. Ils peuvent en fait disposer d'une solution à haute disponibilité, mais ils la testent rarement avec un basculement de production, et ils peuvent avoir moins confiance dans son fonctionnement et sa fiabilité.
Raisons de maintenir régulièrement SQL Server
Après avoir énuméré certaines des raisons courantes pour lesquelles les organisations peuvent choisir de ne pas entretenir régulièrement SQL Server, il est temps d'aborder certains de ces arguments. Tout d'abord, l'ignorance de la façon dont SQL Server est normalement géré par Microsoft n'est plus vraiment une excuse valable. Microsoft a un blog SQL Release Services, où ils annoncent à la fois les Service Packs et les mises à jour cumulatives pour SQL Server. Matthias Bernt a expliqué la stratégie de maintenance générale pour SQL Server dans son article :Une approche modifiée des Service Packs, avec plus de détails sur l'approche du modèle de maintenance incrémentielle de SQL Server disponible dans cet article de la base de connaissances Micosoft.
La version condensée du modèle de maintenance est que les problèmes individuels de SQL Server sont corrigés avec des correctifs. Vous devez contacter Microsoft CSS et ouvrir un dossier de support afin d'accéder à un correctif individuel (sauf s'il s'agit d'un correctif lié à la sécurité, qui est diffusé par Microsoft Update). Selon votre niveau de support payant avec Microsoft, cela peut être un processus relativement fastidieux et chronophage. Il y a aussi le problème que la plupart des clients SQL Server sont très peu susceptibles d'être au courant des correctifs existants qui n'ont pas été publiés dans le cadre d'une mise à jour cumulative de SQL Server. Cela signifie qu'il est peu probable que la plupart des clients obtiennent et déploient des correctifs individuels de manière régulière.
Les mises à jour cumulatives sont des cumuls d'un certain nombre de correctifs (généralement entre 10 et 50 correctifs environ) qui sont publiés toutes les huit semaines. Ces mises à jour cumulatives sont en fait cumulatives (comme leur nom l'indique), vous obtiendrez donc tous les correctifs précédemment publiés pour votre version et votre branche (RTM, SP1, SP2, etc.) du code lorsque vous installez une mise à jour cumulative. Cela signifie que la déclaration commune selon laquelle les organisations "n'appliquent les mises à jour cumulatives que pour corriger les problèmes spécifiques qu'elles rencontrent" n'est en fait pas particulièrement valable dans la vraie vie.
Par exemple, si vous exécutiez la version RTM de SQL Server 2012 Service Pack 1 (11.0.3000) et que vous décidiez d'installer la mise à jour cumulative 3 de SQL Server 2012 Service Pack 1 (11.0.3349) car elle incluait un correctif pour un problème que vous rencontriez réellement, vous obtiendriez en fait tous les correctifs pour SP1 CU1, SP1 CU2 et SP1 CU3, ce qui représenterait bien plus de 100 correctifs.
Comme l'indique Microsoft à propos des mises à jour cumulatives :"Parce que les versions sont cumulatives, chaque nouvelle version de correctif contient tous les correctifs et tous les correctifs de sécurité inclus dans la précédente version de correctif de SQL Server 2012 SP 1. Nous vous recommandons d'envisager d'appliquer la version de correctif la plus récente contenant ce correctif. En gros, cela signifie que si vous repérez un problème particulier et pertinent qui a été résolu dans une CU antérieure, vous devez continuer et déployer la dernière CU pertinente sur le système (qui inclura également ce correctif).
L'un des arguments que j'entends fréquemment sur la raison pour laquelle les organisations ne déploient pas de mises à jour cumulatives est qu'"elles ne sont pas entièrement testées en régression comme le sont les Service Packs, nous ne les déployons donc pas". Il y a une certaine validité dans ce point de vue, mais il y a aussi une idée fausse commune selon laquelle les mises à jour cumulatives sont simplement des tests unitaires, sans aucun test de régression. Ce n'est pas le cas.
La documentation Microsoft sur les mises à jour cumulatives indique qu'étant donné qu'elles "appliquent des tests de régression incrémentiels tout au long du cycle de développement suivis de 2 semaines de tests ciblés dans la fenêtre de publication de 8 semaines, les processus d'assurance qualité associés aux UC dépassent ceux des correctifs individuels". Cela signifie que vous prenez en fait moins de risques en déployant une CU qui a été testée par régression incrémentielle et a également subi deux semaines de tests ciblés que si vous deviez déployer un seul correctif qui n'a été testé qu'à l'unité.
Au cours des six à sept dernières années, j'ai personnellement déployé de très nombreuses mises à jour cumulatives et Service Packs sur un grand nombre de systèmes exécutant SQL Server 2005 à SQL Server 2012, et je n'ai pas encore rencontré de problèmes majeurs. Je n'ai pas non plus entendu parler de problèmes répandus faisant ce type de travail signalés dans les blogs, sur Twitter, etc. aussi risqué que certaines personnes le croient (tant que vous les testez et les déployez correctement).
L'importance d'un plan de test et de mise en œuvre
À moins que vous ne prévoyiez jamais de faire une sorte de maintenance de serveur ou de mise à jour d'application pendant la durée de vie de votre système (ce qui semble être une proposition peu probable), vous devez vraiment développer une sorte de procédure de test et de mise en œuvre et un plan que vous suivrez en tant que partie de faire toute sorte de changement sur le serveur.
Ce plan peut commencer relativement simple, mais il deviendra plus complexe et complet au fur et à mesure que vous acquérez de l'expérience dans la maintenance régulière de vos instances SQL Server et que vous appliquez les leçons que vous apprenez à chaque déploiement. Idéalement, vous devriez suivre ce plan chaque fois que vous apportez une modification au système, mais cela peut ne pas être possible dans tous les cas.
Voici quelques étapes et tests initiaux qui devraient être inclus dans ce type de plan.
- Installer le CU sur une machine virtuelle de test
- L'UC s'installe-t-elle sans problème ni erreur ?
- L'installation de la CU nécessite-t-elle un redémarrage du système ?
- Tous les services SQL Server concernés redémarrent-ils après l'installation ?
- SQL Server semble-t-il fonctionner correctement après l'installation ?
- Installer le CU sur plusieurs systèmes de développement
- L'UC s'installe-t-elle sans problème ni erreur ?
- SQL Server semble-t-il fonctionner correctement lors d'une utilisation quotidienne normale ?
- Vos applications semblent-elles fonctionner correctement lors des tests unitaires ?
- Installer la CU dans un environnement d'assurance qualité ou d'intégration partagé
- Avez-vous suivi un plan de mise en œuvre spécifique et une liste de contrôle pour l'installation ?
- Est-ce que toutes les applications qui utilisent SQL Server réussissent les tests de fumée ?
- Est-ce que toutes les applications réussissent les tests automatisés dont vous disposez ?
- Toutes les applications passent-elles des tests fonctionnels manuels plus détaillés ?
- Installer la CU dans votre environnement de production
- Utilisez une stratégie de mise à niveau progressive dans la mesure du possible
- Utilisez une liste de contrôle détaillée étape par étape pendant le déploiement
- Mettez à jour votre liste de contrôle avec les éléments manqués et les leçons apprises
Conclusion
Ce que j'espère accomplir ici, c'est amener davantage de professionnels des bases de données à adopter un état d'esprit dans lequel ils souhaitent réellement maintenir régulièrement leurs instances SQL Server, plutôt que d'hésiter ou d'avoir peur de le faire. Cela peut impliquer une quantité importante de travail supplémentaire au début, car vous devrez peut-être convaincre d'autres personnes de votre organisation de se joindre à vos plans. Vous devrez peut-être pousser d'autres parties de l'organisation à développer de meilleurs plans de test, et vous devrez créer une liste de contrôle de mise en œuvre. Vous devrez également obtenir l'autorisation de l'entreprise pour les fenêtres de maintenance (qui devraient être relativement courtes avec des mises à niveau progressives), afin que vous puissiez réellement déployer régulièrement des mises à jour sur vos systèmes de production.
En échange de ce travail supplémentaire, vous disposerez d'un système mieux entretenu et moins susceptible de rencontrer des problèmes à l'avenir. Vous serez dans une configuration entièrement prise en charge par Microsoft, et vous aurez plus confiance dans votre ou vos technologies à haute disponibilité, puisque vous les exercerez effectivement de manière régulière. Vous acquerrez également une expérience précieuse lors de la planification et de la mise en œuvre de tout cela, ce qui améliorera vos compétences en matière de dépannage à l'avenir.
