Planification d'une migration

Une migration d'une version SQL Server d'une version ancien vers une nouvelle version se fait peut-être facile une base de données avec une table ou deux, mais lorsque les systèmes sont complexes, on a nécessairement d'un plan. Dans l'éventualité contraire, vous aller avoir une application n'allant plus fonctionner. Voici le cheminement logique d'une migration de SQL Server vers une version plus récentes dans les systèmes complexes :

Pourquoi passer à SQL Server

Il peut y avoir de multiple raison pour vouloir migrer, en dehors du fait qu'on sent la chose nécessaire, les raisons les plus communes sont :

• Nouvelles fonctionnalités non disponibles dans les anciennes versions
• Nouvelles fonctionnalités de l'édition Standard.
• Limites de licence plus élevées
• Tirez parti du nouveau matériel et de l'entreposage
• L'ancienne version peut ne pas être prise en charge par le grand public
• Meilleure maniabilité

Importance de la planification de la mise à niveau

L'importance d'effectuer une bonne planification de la mise à niveau résultat des problématiques suivantes :

• Trouver des bloquants ou des problèmes de mise à niveau est extrêmement important
• Comprendre les différences de licence entre les versions et les éditions
• Avoir une meilleure compréhension des différences de fonctionnalités entre les versions et les éditions
• Sélection du matériel et de l'entreposage en fonction du choix de la version et de l'édition
• Choix du matériel pour minimiser les coûts de licence SQL Server

La raison la plus importante d'une bonne planification est sans aucun doute de ne pas avoir a recommencer la migration au complet car votre première migration s'était révèle un échec complet. Ainsi, il est naïf de croire que vous n'aurez qu'à cliquer NEXT, NEXT, NEXT et que tous sera correcte non pas parce que le produit SQL Server n'est pas correcte mais plutôt à cause que la base de données SQL Server évolue et les choix technologies fait par Microsoft ne correspondent pas nécessairement à vos besoins.

Importance de la planification de la migration

• Éviter la perte de données
• Minimiser les temps d'arrêt
• Réduction de l'impact sur les infrastructures
• Éviter les régressions de performance

Planification de la mise à niveau

• Édition Standard vs Édition Entreprise : La migration obligera peut-être a changer d'Édition pour une version plus puissante ou moins puissante à cause des nouvelles fonctionnalités quel propose. Il voudra donc réévaluer le choix de l'édition désiré :
• Édition SQL Server Enterprise
• Édition SQL Server Standard
• Édition SQL Server Web
• Édition SQL Server Developer
• Édition SQL Server Express
• Différences de licence : Dépendamment du choix de votre licence, vous serez confronté à certaines limitations, il vous bien évaluer les critères suivants :
• Limites de socket et de coeur
• Limites de mémoire
• Machine physique vs machine virtuelle (Très important pour la planification)
• Limites de licence - Édition Enterprise : L'édition Entreprise n'a aucune limite de puissance dans le mesure ou l'édition de Windows Server n'a aucune limitation :
• Système d'exploitation est au maximum pour la mémoire
• Système d'exploitation est au maximum pour les sockets/coeurs physiques
• Limites de licence - Édition Standard : Les limites de l'édition Standard sont pour des besoins normaux, avec des limités et un coût beaucoup moins élevé :
• 128 Go de mémoire pour le moteur de base de données pour SQL Server 2016
• Limité à moins de 4 sockets de 24 coeurs physiques (environnements non virtualisés)
• Limité à moins de 4 sockets de 4 sockets ou 24 coeurs logiques (environnements virtualisés)
• Différences de fonctionnalités utiles
• Opérations d'indexation en ligne
• Cryptage transparent de la base de données
• Prise en charge complète du groupe de disponibilité
• Gouverneur des ressources
• Page en ligne et restauration de fichiers
• Principales différences de performances
• Différences de performances clefs
• Enterprise Edition utilise le parallélisme pour de nombreuses tâches
• Enterprise Edition offre de meilleures performances d'entreposage
• Enterprise Edition utilise l'index columnstore et l'OLTP en mémoire sans limites
• Exemple de différences de performances
• Performances de l'index Columnstore
• Performance de création/reconstruction d'index
• Performances DBCC CHECKDB
• Avantages de performances de SQL Server Enterprise Edition
• Nouvelles fonctionnalités clefs de SQL Server
• Magasin de requêtes
• Améliorations de l'index Columnstore
• Configurations de portée de base de données
• Statistiques de requête en direct
• Améliorations de la sécurité
• Planification du matériel et de l'entreposage
• Entreprise vs Standard
• La sélection du microprocesseur est extrêmement importante !
• Coûts de licence
• Facteur de forme du serveur
• Capacité de performances
• Performances simple-processus léger

Test de mise à niveau

• Préparation du nouvel environnement :
• Préparer correctement le serveur :
• Mises à jour du BIOS/UEFI, du firmware et des pilotes
• Paramètres de configuration matérielle du serveur
• Provisionner et tester l'entreposage et les disques logiques
• Utiliser un schéma de nommage standardisé pour les disques
• Installer et corriger le serveur Windows Server
• Doit-on choisir l'Édition Standard Windows Server ?
• Installer le système d'exploitation sur une matrice RAID 1
• Préférez l'entreposage SSD ou flash au disque dur (HDD)
• Installer et configurer Microsoft Update
• Vérifiez les mises à jour disponibles et installez-les
• Installer correctement SQL Server
• Installez SQL Server dans votre nouvel environnement
• Mettre à jour SQL Server vers le dernier Service Pack et la mise à jour cumulative
• Apporter toutes les modifications de configuration de bonnes pratiques à l'instance
• Pourquoi configurer correctement SQL Server
• De nombreux paramètres par défaut sont incorrects
• Paramètres du système d'exploitation
• Paramètres de configuration au niveau de l'instance
• Paramètres de configuration au niveau de la base de données
• Le passage aux valeurs des meilleures pratiques présente de nombreux avantages
• Sélection des fonctionnalités à installer
• Installez uniquement les fonctionnalités dont vous avez réellement besoin
• Réduit l'attaque et la surface de réparation
• Réduit l'utilisation des ressources
• D'autres fonctionnalités peuvent facilement être installées ultérieurement
• Utiliser une instance de développement pour expérimenter
• Édition Developer : gratuit et possède toutes les fonctionnalités
• Recherche de problèmes de mise à niveau
• Vérificateur de configuration système
• Consulter la documentation Microsoft concernant les changements de rupture de compatibilité
• Assistant de migration de données
• Requête pour les fonctionnalités obsolètes SQL Server dans PerfMon
• Test d'application
• Test préliminaire (Smoke-test)
• Les tests de régression
• Test fonctionnel
• Test de performance
• Travail avec les développeurs et les testeurs

Planification de la migration

• Conseils pour faciliter la migration :
• Assurez-vous que toutes les applications ont été soigneusement testées dans le nouvel environnement (environnement de développement, de test, de Staging, de production,...).
• Assurez-vous que tous les objets au niveau de l'instance ont été migrés (n'oublié par exemple les configurations spécifiés sp_configure, les travaux de SQL Server Agent,...).
• Élaborer un plan détaillé et une liste de contrôle pour le processus de migration
• Effectuer une migration de test dans le cadre du processus de test global de l'application
• Astuces pour accélérer la migration
• Migrez les données à l'avance si possible (conditionnel au fait qu'il faut prendre en note toutes les éléments ayant migré à l'avance, car sinon vous serez probablement dans l'obligation de recommencé).
• Nettoyez la base de données héritée à l'avance
• Pensez à archiver ou supprimer les anciennes données si possible
• Assurez-vous que la fragmentation des index est sous contrôle
• Supprimer les index inutilisé ou en double
• Rechercher des opportunités de compression de données
• Réduisez vos fichiers journaux de transactions
• Utilisez la compression de sauvegarde
• Réduit considérablement la taille des fichiers de sauvegarde
• Réduit le temps écoulé pour la sauvegarde et la restauration
• Soulage le stress sur le sous-système d'entreposage
• Utilisez des sauvegardes par bandes
• Utilise plusieurs fichiers de sauvegarde au lieu d'un seul fichier
• Peut accélérer les sauvegardes et les restaurations
• Des fichiers de sauvegarde séparés doivent être situés sur des LUN (numéro d'unité logique) séparés.
• Utilisez l'initialisation instantanée des fichiers
• Évite l'initialisation zéro des fichiers de données SQL Server
• Ne fonctionne pas pour les fichiers journaux SQL Server
• Peut réduire considérablement le temps de restauration de la base de données
• Initialisation instantanée du fichier
• Méthodes de copie de fichiers : Prévoyez une méthode pour copier les données parmi les suivantes :
• Windows Explorer
• Microsoft XCopy
• Microsoft Robocopy : Cette commande peut être préférable pour de gros fichiers.
• Utilitaires de copie de fichiers tiers
• Considérations relatives à la copie de fichiers
• Différentes méthodes peuvent être plus performantes ou plus robustes.
• Testez différentes méthodes pour voir laquelle fonctionne le mieux dans votre environnement.
• Le plus souvent utilisé pour copier les fichiers de sauvegarde de la base de données sur un nouveau serveur.
• Envisagez la sauvegarde de la base de données sur le réseau vers un partage de fichiers sur un nouveau serveur.
• La meilleure méthode à utiliser dépend de votre infrastructure.

Test de migration

• Assistant d'expérimentation de base de données Microsoft DEA (Microsoft Database Experimentation Assistant)
• Solution de test de performance A/B pour les mises à niveau de SQL Server
• Vous permet de comparer les performances entre deux versions de SQL Server
• Peut comparer SQL Server 2005 et plus récent à n'importe quelle version plus récente de SQL Server
• Capture les mesures de charge de travail réelles et vous permet de rejouer sur deux systèmes cibles
• Utilise la relecture distribuée pour capturer et rejouer la charge de travail de production
• Étapes standard de post-migration
• Sauvegarde complète de la base de données pour chaque base de données
• Exécutez sp_updatestats sur chaque base de données
• Activer Query Store pour chaque base de données
• Changer le niveau de compatibilité de la base de données
• Remplir tous les catalogues en texte intégral
• Exécuter DBCC CHECKBD sur chaque base de données
• Vérification des régressions de performance
• Utilisez des requêtes DMV pour comparer les performances
• Utilisez le Query Store pour comparer les performances
• Utiliser l'analyse DEA pour comparer les performances
• Utiliser les tests d'application pour comparer les performances
• Atténuer les régressions de performance
• Configuration à l'échelle de la base de données
• Estimation de cardinalité
• Forçage du plan Query Store
• Optimisation des requêtes et des index
• Autres problèmes de configuration clefs
• Modifier la configuration de la portée des bases de données
• Activer/désactiver l'estimation de la caradinalité héritée
• Activer/désactiver le reniflage des paramètres
• Activer/désactiver les correctifs de l'optimiseur de requêtes
• Définir le degré maximum de parallélisme au niveau de la base de données
• Vider le cache du plan pour une seule base de données
• Autres problèmes clefs de configuration
• Gestion de l'alimentation
• Seuil de coût pour le parallélisme
• Degré maximum de parallélisme
• Mémoire maximale du serveur
• Niveau de compatibilité de la base de données
• Configuration Tempdb

Migration en production

• Installation côte à côte
• Installer une instance nommée sur un serveur de base de données existant
• Moins de risques que la mise à niveau en place, mais présente toujours des inconvénients
• Faites attention aux problèmes de conflit de ressources avec plusieurs instances
• Réduit le temps de migration des données
• Détacher/attacher
• Détacher les bases de données utilisateur, copier des fichiers, attacher à une nouvelle instance
• La copie des fichiers de la base de données peut prendre un certain temps
• Certains risques que l'opération d'attachement échoue.
• Sauvegarde/Restauration
• C'est la méthode la plus sûre pour la migration
• Beaucoup moins de risques que détacher/attacher
• Peut nécessiter une longue panne en raison de la taille et de l'infrastructure de la base de données
• Utilisation de l'envoi de journaux
• L'envoi de journaux est facile à configurer et à utiliser
• Ne nécessite pas que les serveurs soient dans le même domaine
• Ne nécessite pas de certificats
• Ne met pas de charge supplémentaire sur l'instance héritée
• Créer la copie d'expédition du journal de bord à l'avance
• Temps d'arrêt relativement court pour la migration
• Utilisation de la mise en miroir de bases de données
• La mise en miroir de la base de données est plus compliquée à mettre en place
• Nécessite que les serveurs soient dans le même domaine ou vous pouvez utiliser des certificats
• Place une charge supplémentaire sur l'instance héritée
• Créer un miroir de base de données à l'avance
• Vous pouvez automatiser le basculement
• Temps d'arrêt très court pour la migration réelle
• Tâches post-migration
• Effectuer des sauvegardes complètes sur toutes les bases de données
• Mettre à jour les statistiques sur toutes les bases de données utilisateurs
• Changer le niveau de compatibilité sur les bases de données utilisateurs
• Exécutez DBCC CHECKDB sur toutes les bases de données
• Surveiller la santé et les performances des instances