Discussion :

[Francky8]

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

[SQLpro]

Le mieux serait de faire tout simplement un sp_detach_db côté 2000, copier les fichiers de données (pas les journaux) vers la destination puis réattacher de l'autre avec CREATE DATABASE ... FOR ATTACH WITH REBUILD LOG.

Le problème est que la migration de 2000 vers 2019 n'est pas supportée. Il faut impérativement passer par une étape intermédiaire 2008/2008R2.

Après DBCC UPDATEUSAGE (0) va mettre beaucoup de temps... et c'est inutile....
Et EXEC sp_updatestats le fait par échantillon, ce qui peut être cata dans certains cas.
et faite un dbcc checkdb au niveau physique cela suffit

Si vous êtes en édition enterprise, je vous conseille un recalcul des stats en mode FULLSCAN

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
DECLARE @SQL NVARCHAR(max) = N'';
SELECT @SQL = @SQL + N'UPDATE STATISTICS [' + s.name + '].[' + o.name + '] ( [' + st.name   + ']) WITH FULLSCAN;' 
FROM   sys.stats AS st
       JOIN sys.objects AS o ON st.object_id = o.object_id
	   JOIN sys.schemas AS s ON o.schema_id = s.schema_id
	   CROSS APPLY sys.dm_db_stats_properties(st.object_id, st.stats_id) AS sp
WHERE  is_ms_shipped = 0;
EXEC (@SQL);

A +

[Francky8]

Bonjour Frédéric,

Quand je parlais de 2019 c'était pour Windows.
On reste en SQL Server 2000 car l'application "plus supportée" ne permet pas de faire évoluer la version de SQL Server (à cause de l'utilisation notamment de tables system à l'ancien format).
J'ai fait une étude complète pour faire évoluer SQL Server mais pas possible. Pas d'évolution possible sur l'application qui reste "figée" jusqu'au remplacement (en cours).
Le fait de passer de Windows 2003 à Windows 2019 au niveau OS sur nos VM Azure va nous permettre de bénéficier de capacités dans Azure notamment pour les backups Azure des disques.

Si je ne fais pas le detach des bases mais si l'instance SQL Server est arrêtée avant la copie des fichiers data, est-ce que c'est ok ?
Normalement l'arrêt de SQL Server devrait permettre la cohérence des fichiers de chaque base et permettre un attach après sur l'autre instance.

Vous allez me demander pourquoi je ne veux pas faire le detach sur l'ancien serveur ?
Si pb lors de la migration, je conserve l'instance SQL Server actuelle à l'identique au cas où j'aurais besoin de faire marche arrière.
Il me suffit de la rédémarrer et tout est comme avant. Pas besoin de refaire les attachs.

Ok pour me limiter au dbcc checkdb après l'attach.
C'est une édition Standard pour SQL Server donc moins pratique pour avoir des opérations moins pénalisantes.

Merci pour votre retour

Franck

[SQLpro]

Il vaut mieux quand même faire le detach et conserver les fichiers sur l'ancien serveur afin d'éviter la dualité des bases.

A +

[mikedavem]

Si tu veux un minimum de downtime, pourquoi ne pas passer par du log shipping entre tes 2 VM ? Sur SQL 2000 ca marche plutôt bien.

++

[Francky8]

Bonjour,

Merci Frédéric pour la précision.

Merci Mikedavem pour l'idée du log shipping. L'instance actuelle est très critique et on va éviter de la "toucher". De plus, on a négocié un arrêt pendant un week-end nous permettant de faire l'opération "snapshot disques actuels / link des snapshots sur nouvelle VM / copie data et log files sur disques nouvelle VM / attach des bases / check des bases".
Je suis en train de tester l'opération afin de voir le temps à prévoir.

Merci à vous 2

Franck