Bonjour,
J'aurais aimé une confirmation.
J'ai récupéré l'administration d'une instance SQL Server 2000. Et oui on a encore du sql server 2000 pour une application qui n'est plus supportée mais qui va être remplacée... migration en cours.
En attendant, nous devons maintenir et assurer la fiabilité du serveur SGBD SQL Server 2000 concerné.
Pour ce faire, nous allons migrer la VM Azure concernée avec un OS Windows Server 2003 sur une VM Azure avec un OS Windows Server 2019.
Ceci a été fait pour les environnements DEV et ACC. Après qq "réglages" par notre homme système sur Windows 2019, SQL Server 2000 fonctionne bien.
Nous devons migrer maintenant les bases de PROD relativement volumineuses (application critique EAI).
Notre contrainte : limiter au maximum la "fenêtre" de downtime.
Ce qui est prévu :
. arrêter la VM actuelle / SQL Server sera donc arrêté
. snapshot des disques sur lesquels il y a les fichiers data et log des bases
. connexion du snapshot sur la nouvelle VM et copie sur les disques de ce nouveau serveur
. attach des bases à partir des fichiers data et log présents
Backups des bases + copie des backups + restore des bases = durée très importante
Arrêt VM + snapshot + lien et copie snapshot sur disques nouvelle VM + attach --> beaucoup moins de temps
D'habitude, pour une migration je fais cela par backup/restore (ce qui a été fait pour DEV et ACC).
Dans notre plan d'action,
→ est-ce que le fait de ne pas faire de detach des bases avant l'arrêt de SQL Server peut être préjudiciable sur l'attach à venir sur le nouveau serveur ?
→ est-ce que l'arrêt de SQL Server "suffit" pour assurer une cohérence des bases après l'attach à venir sur le nouveau serveur ?
Pour résumer, est-ce que faire un arrêt de sql server et ensuite utiliser les fichiers data et log des bases utilisateurs pour faire des attach sur une autre instance fonctionne et est sans risque pour la cohérence des bases ?
Après l'attach, je prévois de faire les opérations suivantes :
→ dbcc checkdb
→ DBCC UPDATEUSAGE (0)
→ EXEC sp_updatestats
et eventuellement reconstruire les index les plus volumineux si la "fenêtre temps" le permet.
Votre avis ?
Par avance, merci pour vos réponses.
Franck
Partager