Quel est le meilleur moyen de mettre à niveau SQL 7 vers SQL 2008?

Vous ne pouvez pas passer directement de SQL Server 7 à SQL Server 2008. Ce document liste les options possibles prises en charge. [http://msdn.microsoft.com/en-us/library/ms143393.aspx]

Votre meilleure option est de passer de SQL Server 7 à SQL Server 2000, puis de SQL Server 2000 à SQL Server 2008. Et ne faites pas plus de sauts que nécessaire. C'est votre meilleure option pour obtenir des informations fiables. http://www.microsoft.com/downloads/details.aspx?FamilyID=66d3e6f5-6902-4fdd-af75-9975aea5bea7&displaylang=en

Après la mise à niveau

1. Soyez prêt à rencontrer des problèmes de performance, car l'optimiseur de requête est réécrit à partir de zéro et vous obtiendrez des plans complètement différents, soyez prêt à réécrire une partie du code. Ne vous attendez pas à ce que le passage à SQL Server 2008 résolve les problèmes (du moins) au début.
2. Assurez-vous de reconstruire tous les index ou de mettre à jour les statistiques avec un balayage complet
3. Exécutez un DBCC UPDATEUSAGE et cela aidera les vues système (DMVs) à corriger les comptages de lignes.
4. ALTER DATABASE SET PAGE_VERIFY CHECKSUM et cela vous aidera à détecter les corruptions IO tôt. Idéalement, vous voulez définir cette option avant de reconstruire les index.

Il existe de nombreux autres pièges dans lesquels vous pourriez tomber, donc la planification et les devoirs sont la clé d'une mise à niveau réussie.

Personnellement, je choisirais la méthode de la restauration sur un serveur intermédiaire. Copier la structure et les données devrait également fonctionner, mais cela pourrait en fait prendre plus de temps que deux opérations de détachement + copie + attache.

Si vous choisissez l'approche de copie de structure et de données BCP, assurez-vous de définir correctement le niveau de compatibilité de la base de données de destination pour réduire les problèmes dus aux changements dans SQL lui-même. Voir http://msdn.microsoft.com/en-us/library/ms178653(SQL.90).aspx pour plus de détails sur ces différences.

Même avec un niveau de compatibilité défini en conséquence, vous devriez planifier un test de régression complet de toute application utilisant la base de données car il peut encore y avoir de légères différences là où votre code repose sur un comportement "non défini" qui était constant dans SQL7 mais qui n'est pas garanti de l'être dans des versions ultérieures.