Mettre à niveau SQL Server 2000 vers 2008 R2 avec la réplication

J'ai examiné ce projet pour une solution de mise à niveau côte à côte. La solution la plus largement suggérée / utilisée est de faire une sauvegarde complète de la database SQL Server 2000 et de restaurer sur SQL Server 2008 avec norecovery. Ensuite, restaurez les sauvegardes du journal des transactions suivantes avec norecovery. Lorsque nous sums prêts à basculer, modifiez SQL Server 2000 en mode lecture seule, sauvegardez le journal de fin et restaurez-le sur SQL Server 2008 avec récupération. Ensuite, apportez SQL Server 2008 en ligne.

Mais, la mise à niveau ne peut pas être effectuée avec la réplication transactionnelle où SQL Server 2000 est l'éditeur et SQL Server 2008 est l'abonné. Script tous les objects tels que les connections, les index, etc et s'appliquent à SQL Server 2008. Lorsque nous sums prêts à basculer, nous allons arrêter la réplication, supprimer tous les travaux de réplication et basculer toutes les applications pour se connecter à SQL Server 2008. Je n'ai pas trouvé quelqu'un qui suggère cette méthode. Y a-t-il quelque chose qui ne va pas?

La méthode de migration de données que vous décrivez est possible à l'aide de la réplication SQL Server.

Il n'y a rien de mal à cette méthode ou à toute autre méthode de migration de données, aussi longtime que le choix que vous décidez répond aux exigences spécifiques de votre projet / plate-forme d'application.

Cela dit la méthode que vous décrivez est certainement plus impliquée techniquement dans la configuration et la mise en œuvre des étapes de migration réelles. Si vous pouvez accepter les time d'arrêt, un simple process de sauvegarde et de restauration sera certainement beaucoup plus simple. L'envoi de journaux serait également une autre méthode de migration plus simple.

Jusqu'à présent, vous savez que la méthode de réplication pourrait fonctionner en théorie. Il est maintenant time de build une solution de travail en test afin de valider votre stratégie de migration de données et de pratiquer le process de mise en œuvre.

Si vous ne répliquez pas autrement, la création d'un abonnement de réplication modifiera votre schéma et quelques parameters. Par exemple, vous pouvez vous refind avec des GUIDs générés pour toutes vos lignes simplement pour faciliter la réplication.

Attention – la réplication transactionnelle désactivera toutes les colonnes IDENTITY sur l'abonné (les SP de réplication transactionnelle en dépendent en réalité, car elles s'insèrent dans les colonnes IDENTITY sans spécifier d'abord IDENTITY_INSERT ON). Je peux seulement confirmer que c'est le cas lorsque l'abonné est également SQL 2000 – peut-être que l'abonné sur 2008 se comportera différemment.

Pour cette raison, la réplication transactionnelle avec SQL 2K ne vous donne pas vraiment de réserve. Nous avons dû faire un peu de peaufinage SQL (ré-installer les colonnes IDENTITY et réécrire les SP de réplication avec les wrappers IDENTITY_INSERT) pour get une situation où l'abonné fonctionne réellement en mode veille, prêt à avoir des applications pointées dessus . Mais cela ne fonctionnerait certainement pas hors de la boîte =)

Oui, cela fonctionnera, à condition de transférer les autres objects.