Migration de données de SQL Server 2005 vers 2016
Je suis nouveau dans l'administration de SQL Server mais je suis à l'aise avec le langage SQL et la création de packages SSIS.
Je souhaite migrer les données de SQL Server 2005 vers 2016.
Ma question est de savoir si je dois me soucier des bases de données système et d'autres objets tels que les index, les procédures stockées, la vue, la sécurité et les autorisations. les connexions ou puis-je simplement migrer les données.
Quelle serait la procédure recommandée dans ce cas.
Max a donné une réponse décente que je voterai une fois que j'aurai fini de taper cette vue alternative.
Je ne suis pas un fan de la restauration des bases de données système lors d'une migration de mise à niveau et je préfère faire des migrations plutôt que des mises à niveau en place comme je l'ai expliqué dans cette longue réponse à une autre question.
En gros, j'aime recommencer "frais" quand je fais une migration. Je trouve que jouer avec les migrations et les mises à niveau de la base de données système par le biais de la restauration provoque parfois des frustrations avec les restaurations et peut entraîner des péchés potentiels.
Vous avez également posé des questions sur les index, les procédures stockées et les vues. Ces éléments au niveau de la base de données doivent tous vivre à l'intérieur d'une base de données utilisateur. Ainsi, lorsque vous restaurez la base de données X sur le nouveau serveur, tous les objets de la base de données (tables, utilisateurs, vues, processus, fonctions, etc.) seront également présents.
Ce qui existe dans les bases de données système sont les travaux, les connexions, les alertes, les serveurs liés, les clés de chiffrement, etc. Les éléments de niveau instance.
J'aime passer en revue ceux-ci et migrer sur ce dont j'ai besoin en utilisant divers scripts - dernièrement, ce sont les scripts DBATools.Io powershell. J'aime utiliser leur script pour copier les connexions SQL en particulier, car il gère les utilisateurs authentifiés SQL en gardant leurs mots de passe et identificateurs de sécurité de la même manière pour que les utilisateurs de la base de données de ces connexions fonctionnent. Ils ont également un commande de migration SQL Server qui exécute leurs sous-commandes pour copier les éléments que je recopierais généralement.
Je ne pense pas que Max ait tort avec cette réponse, d'où le vote positif. J'ai juste eu plus de succès et plus de chance et je me sens plus à l'aise de migrer vers de nouvelles au lieu d'essayer de restaurer des bases de données système entre les versions. Je dirais que je ne me souviens vraiment pas de la dernière fois que j'ai effectué une migration de mise à niveau de version et que je ne l'ai pas fait de cette façon au lieu de restaurer les bases de données système.
Vous voudrez peut-être envisager de migrer les bases de données système (maître, msdb et peut-être modèle), si vous avez besoin d'accéder aux métadonnées stockées dans ces bases de données.
Master stocke des éléments tels que les connexions, les certificats de sécurité, etc.
msdb contient des détails sur les sauvegardes et stocke, entre autres, les configurations de travail de l'Agent SQL Server.
Le modèle peut avoir été personnalisé par vous ou votre équipe pour permettre aux bases de données vides nouvellement créées de contenir un ensemble d'objets prédéfinis que vous utilisez dans chaque base de données.
La migration des bases de données système peut être effectuée assez facilement; des instructions détaillées sont disponibles sur MSDN à l'adresse Sauvegarde et restauration des bases de données système (SQL Server) .
Selon vos besoins, vous pouvez effectuer une BACKUP DATABASE opération sur les bases de données utilisateur sur l'instance 2005, puis RESTORE DATABASE sur l'instance 2016 pour apporter l'intégralité de la base de données, y compris toutes les données, index et autres objets.
Cela nécessitera, au moins initialement, la même quantité d'espace consommée par la base de données sur l'instance 2005. Cependant, une fois la base de données restaurée, vous pouvez profiter de la compression des données pour réduire considérablement l'empreinte requise.
Voir À propos de l'utilisation des sauvegardes SQL Server pour plus de détails sur l'exécution des sauvegardes et À propos des scénarios de restauration pour plus de détails sur les restaurations.
Est-ce jusqu'en 2012 ou 2016? Cela fait une différence en ce sens que l'IIRC 2012 est un chemin de migration testé tandis que 2016 ne l'est pas. En tant que tel, les problèmes connus sont documentés et/ou seront détectés par le Conseiller de mise à niveau pour 2012. Un chemin non testé peut toujours fonctionner sans aucun problème, il est juste inconnu. Cela dit, je vous recommande fortement d'aller en 2016. Je pense que l'effort sera presque le même.
Voir Mettez-vous à niveau à partir de SQL Server 2005? dans la documentation des options de mise à niveau 2005 et des liens vers un processus de mise à niveau très détaillé. Le processus de mise à niveau a été écrit pour 2014 mais est toujours applicable pour 2016.