Lorsque ces versions de SQL Server ont été publiées, elles étaient accompagnées de 10 ans de support; 5 ans d'assistance standard et 5 ans d'assistance étendue. Si votre organisation a toujours SQL Server 2008/2008 R2 en production, comment votre organisation prévoit-elle de gérer le risque ? Pour les organisations fortement réglementées, c'est une grande préoccupation.

Vous devez choisir comment vous allez migrer et où vous allez migrer, puis vous assurer que vous ne rencontrerez aucun obstacle en cours de route.

Outils d'évaluation de la migration

Si vous prévoyez une mise à niveau à partir de SQL Server 2008/2008 R2, Microsoft a rendu les choses beaucoup plus faciles pour tester et valider votre environnement. Il existe de nombreux outils qui peuvent aider aux évaluations de migration et même gérer les tâches de migration, et ils sont tous légèrement différents. Ces outils incluent :

• Assistant de migration de données
• Kit d'outils d'évaluation et de planification Microsoft
• Service de migration de base de données Azure
• Assistant d'expérimentation de base de données

L'assistant de migration de données vous aide à passer à une plate-forme de données moderne. Pour ce faire, il détecte les problèmes de compatibilité qui peuvent avoir un impact sur les fonctionnalités de la nouvelle version de SQL Server et formule des recommandations pour améliorer les performances et la fiabilité du nouvel environnement. Votre source peut être SQL Server 2005+ avec une cible SQL 2012+ et Azure SQL Database.

La boîte à outils d'évaluation et de planification Microsoft existe depuis de nombreuses années et est souvent appelée outil MAP. C'est idéal pour faire un inventaire de votre environnement actuel pour trouver où SQL Server (et d'autres applications) existent.

Le service de migration de base de données Azure intègre certaines des fonctionnalités des outils et services existants pour fournir aux clients une solution complète de migration vers Azure. L'outil génère des rapports d'évaluation qui fournissent des recommandations pour vous guider dans les modifications requises avant d'effectuer une migration. Ce service nécessite actuellement un VPN ou Express Route.

Enfin, l'assistant d'expérimentation de base de données est une nouvelle solution de test A/B pour les mises à niveau de SQL Server et c'est un outil avec lequel vous devriez vous familiariser. Il exploite Distributed Replay pour capturer une charge de travail et la rejouer sur un serveur SQL cible. Cela peut être utilisé pour tester les modifications matérielles ou les différences de version de SQL Server. Vous pouvez capturer des charges de travail à partir de SQL Server 2005 et versions ultérieures.

Options de migration

Mise à niveau sur site : L'une des méthodes de migration les plus simples consiste à effectuer une mise à niveau vers une version plus récente de SQL Server. Dans ce cas, vous avez le choix entre SQL Server 2012, 2014, 2016 ou 2017. J'encourage les clients à mettre à niveau vers la dernière version qu'ils peuvent. SQL Server 2012 est déjà hors du support général et SQL Server 2014 sort du support général le 9 juillet 2019. La mise à niveau peut être très longue et coûteuse pour les organisations en raison de toute la planification et des tests impliqués, donc le passage à la dernière version peut augmenter le temps avant la prochaine mise à jour. Il existe également de nombreuses améliorations de performances et de fonctionnalités dans SQL Server 2016 et 2017 qui font de la migration vers SQL Server 2012 ou 2014 un très mauvais choix pour le moment.

Une approche courante pour les mises à niveau sur site consiste à en créer de nouvelles et à les migrer, quel que soit l'environnement physique ou virtuel. En créant de nouvelles bases de données, vous pouvez restaurer vos bases de données et effectuer de nombreuses séries de tests et de validation pour vous assurer que tout fonctionne comme prévu avant de passer à la production.

Mettre à niveau et migrer vers une machine virtuelle Azure : Pour les organisations qui cherchent à migrer vers le cloud, Azure Infrastructure as a Service (IaaS) est une excellente option. L'exécution de SQL Server sur une machine virtuelle Azure ressemble beaucoup à une utilisation sur site. Vous spécifiez la taille de la machine virtuelle (nombre de vCPU et de mémoire) et configurez votre stockage en fonction de vos exigences d'E/S et de taille. Vous êtes toujours responsable de la prise en charge du système d'exploitation et de SQL Server pour la configuration et les correctifs. Azure IaaS vous permet de faire évoluer facilement vos charges de travail en augmentant ou en réduisant la taille de votre machine virtuelle en fonction de l'évolution de vos besoins de charge de travail, ainsi que de tirer parti de l'intégration d'Azure Active Directory, de la détection des menaces et de nombreux autres avantages d'Azure.

Migrer vers Azure SQL Database : Une autre option que vous avez est de migrer vers Azure SQL Database. Azure SQL Database peut être considéré comme une base de données en tant que service et fait partie de la plate-forme en tant que service (PaaS) de Microsoft. La fonctionnalité Azure SQL Database est étendue à la base de données, ce qui signifie que certaines choses telles que les requêtes inter-bases de données, l'agent SQL Server, la messagerie de base de données, etc. ne sont pas disponibles. Cependant, de nombreux clients qui ont des applications qui utilisent une seule base de données ont pu migrer vers Azure SQL Database avec un minimum d'effort. Vous pouvez tester rapidement la compatibilité avec Azure SQL Database à l'aide de l'assistant de migration de données. Avec Azure SQL Database, vous pouvez dimensionner vos bases de données par DTU (Database Transaction Units) ou vCores individuellement, ou regrouper des bases de données dans un pool élastique. Azure SQL Database vous permet d'augmenter et de réduire vos ressources avec un minimum d'efforts et de temps d'arrêt.

Migration vers Azure SQL Managed Instance : Une nouvelle option (à partir de 2018) consiste à migrer vers Azure SQL Managed Instance. Il s'agit d'un nouveau produit actuellement généralement disponible à partir du 1er octobre pour le niveau Usage général. Managed Instance a été créé à l'aide du modèle de programmation au niveau de l'instance. Cela signifie que les fonctionnalités auxquelles nous sommes habitués avec la version complète de SQL Server sont prises en charge. L'objectif de Managed Instance est d'avoir une compatibilité de surface à 100 % avec le local. Toutes les bases de données de l'instance se trouvent sur le même serveur, de sorte que les requêtes entre bases de données sont prises en charge, tout comme la messagerie de base de données, l'agent SQL Server, Service Broker et bien plus encore. Il existe deux niveaux de tarification ; Usage général, qui comprend un secondaire non lisible pour HA, et Business Critical, qui a deux secondaires non lisibles et un secondaire lisible. Managed Instance fait partie de l'offre PaaS de Microsoft, vous bénéficiez donc de toutes les fonctionnalités et fonctionnalités intégrées de PaaS.

Déplacer tel quel vers les machines virtuelles Azure : Microsoft offre trois ans de mises à jour de sécurité étendues sans frais supplémentaires si vous déplacez vos instances SQL 2008/SQL 2008 R2 vers une machine virtuelle Azure. L'objectif est de vous donner un peu plus de temps pour mettre à niveau vers une version plus récente de SQL Server lorsque vous êtes prêt.

Payer pour rester : Il ne s'agit pas d'une option de migration, mais vous avez la possibilité d'acheter jusqu'à trois ans de mises à jour de sécurité étendues. Il existe des restrictions autour de cette option. Vous devez disposer d'une Software Assurance active pour ces instances ou licences d'abonnement dans le cadre d'un Contrat Entreprise. Si cela s'applique à vous, cette option peut vous faire gagner plus de temps pour planifier et migrer depuis SQL Server 2008/2008 R2.

Meilleures pratiques de migration

Lorsque vous effectuez une migration ou une mise à niveau, vous devez être conscient de certaines choses. Tout d'abord, vous avez besoin de lignes de base et je ne saurais trop insister là-dessus. Chaque fois que vous modifiez un environnement, vous devez être en mesure de mesurer l'impact de ce changement sur l'environnement. Connaître les mesures de performances clés de votre environnement peut vous aider lors du dépannage de tout impact perçu. Vous pouvez collecter manuellement ces métriques à l'aide de perfmon et de DMV ou investir dans une plateforme de surveillance des performances. J'ai écrit sur les deux techniques plus en détail dans un article précédent, et maintenant vous pouvez obtenir une évaluation étendue de 45 jours de SentryOne . Disposer de métriques de base pour des éléments tels que l'utilisation du processeur, la consommation de mémoire, les métriques de disque, etc. peut vous permettre de savoir rapidement si les choses s'améliorent ou s'aggravent après une mise à niveau ou une migration.

Vous devez également noter vos options de configuration dans votre instance. Plusieurs fois, on m'a demandé d'examiner une instance SQL Server après une mise à niveau ou une migration et j'ai constaté que la plupart des paramètres par défaut étaient utilisés. Si l'ancien système est toujours disponible, je peux l'interroger et obtenir les valeurs précédentes non par défaut qui étaient en place et les appliquer au nouvel environnement pour les ramener à une configuration connue. Il est toujours bon de revoir sys.configurations sur votre serveur de production pour envisager d'apporter des modifications similaires à votre nouvel environnement (seuil de coût pour le parallélisme, degré maximal de parallélisme, optimisation pour les charges de travail ad hoc, etc.) Remarquez que j'ai écrit «considérer». Si votre nombre de cœurs ou votre mémoire est différent sur le nouveau serveur, vous devez configurer les paramètres en tenant compte de la taille du nouveau serveur.

Quel est votre plan de secours si les choses tournent mal ? Avez-vous des sauvegardes appropriées sur lesquelles vous pouvez revenir ? Dans la plupart des cas, avec une mise à niveau ou une migration, vous passez à une nouvelle machine virtuelle ou à un nouveau serveur physique. Votre rétablissement peut consister à revenir à l'ancien serveur. Si vous avez eu des modifications de données dans la nouvelle version de SQL Server, votre restauration est beaucoup plus compliquée. Vous ne pouvez pas restaurer une sauvegarde de base de données SQL Server à partir d'une version plus récente de SQL Server vers une version plus ancienne.

Conclusion

Si vous utilisez toujours SQL Server 2008 ou SQL Server 2008 R2, vous disposez de quelques options pour rester en conformité après le 9 juillet 2019. Pour rester sur SQL Server 2008 ou SQL Server 2008 R2, vous pouvez acheter des mises à jour de sécurité étendues. ou passez à une machine virtuelle Azure si vous êtes éligible. Si vous pouvez effectuer une mise à niveau, vous pouvez migrer vers une version prise en charge de SQL Server sur site ou sur une machine virtuelle Azure ou envisager de migrer vers une solution gérée telle qu'Azure SQL Database ou Azure SQL Managed Instance.