Procédure de Rollback Migration SQL 2008 R2 depuis SQL 2000 [Résolu]

[phg_dev]

Bonjour,

Je suis chargé dans mon entreprise de procéder aux taches suivantes dans un process de migration d'un ensemble de base de SQL serveur 2000 vers SQL serveur 2008 R2
- Modification des scripts ( Ps , Fonction, vue, trigger ) pour assurer la compatibilité SQL Serveur 2008. Ce point-là ne présente pas de difficulté pour moi, et est en cours. ( Les types de données restent les mêmes, on n'utilise pas les nouveaux type de données de SQL serveur 2008 R2. )

- Élaboration d'un processus de retour en arrière à l'issue de la migration, si des problème de performance viendrait se déclarer sur le tard. ( donc revenir de SQL server 2008 R2 vers SQL serveur 2000 )
Bien entendu, une longue période de recette et de test de montée en charge est prévue, mais ce script de Rollback général est une contrainte du projet.

Et c'est sur ce point que je rencontre des difficultés :
- Ma première contraintes est la volumétrie : toute bases additionnées, on arrive environ à 0,5 To de données.
- Ma seconde contrainte est que cette volumétrie est essentiellement due a des colonnes blob...

La migration elle-même sera faite avec un backup des base en SQL 2000 et un restore en SQL 2008 R2, pour chaque base, puis compilation de tous les script des objets non compatible.

Pour le retour arrière, la stratégie que j'envisage pour le moment est de faire une grosse mécanique à base de bcp, ( générée automatiquement à l'aide des infos dispos dans les vues de INFORMATION_SCHEMA ) dans le style suivant :

Pour chaque base :
Export des data en différentiel.
- Génération d'une liste des enregistrement a deleter, pour chaque table.
- Export des données en différentiel avec bcp, pour chaque table.
Import des data
Dans l'ordre montant des intégrités référentielles, pour chaque table :
- delete from openrowset ( la liste des enregistrement à deleter )
Dans l'ordre descendant des intégrités référentielles, pour chaque table :
- bulk insert des données en différentiel ( avec KEEPIDENTITY ) ( et utilisation du script de sqlpro pour détruire/reconstruire les index automatiquement )

Mes Questions :
1- les blob : Comment les blob sont gérés par bcp en export et import ?
2- Ma démarche : Vous sembles-t-elle valide ? Suis en train de réinventer la roue ? Des outils sur le marché font-ils ce genre de chose ?

Je vous remercie d'avance pour toute aide que vous pourrez m'apporter.

phg_dev

[dbaffaleuf]

Normalement, l'upgrade side by side doit te permettre un retour arrière confortable. Les problèmes de performance sur le tard dont tu parles doivent être minimisés par des tests poussés sur la 2008R2, en utilisant le replay dans profiler par exemple.

Maintenant s'il faut vraiment blinder la migration, je testerai la solution de faire une réplication snapshot en publiant de 2008R2 vers 2000 (contrainte il faudra que la distribution soit sur l'instance 2008R2). L'agent de snapshot prend ensuite en charge tout le déplacement de données de l'instance 2008R2 vers l'instance 2000 en automatisant la partie BCP + structure des objets. Il faut valider que tu as bien des clés primaires sur toutes tes tables.

Ca vaut peut être le coup d'essayer pour éviter d'avoir à gérer tous les BCP et les scripts à réappliquer ensuite sur l'instance 2000. (je viens de faire un petit test entre une 2008SP1 et une 2000SP4, et qq tables avec des champs text, cela fonctionne bien).

Sinon, une autre solution, SSIS et l'export / import de données.

[phg_dev]

Merci pour la réponse,
J'avais cru que la réplication n'était pas possible de SQL Server 2008 R2 vers SQL Server 2000 SP4 ( j'avais oublié de préciser le service pack ).

Sinon, pour répondre à votre question : oui, je dois vraiment blinder la migration.

Je vais soumettre cela aux admin systeme. merci pour le test en tout cas.
J'attends la réponse de mes admin pour vous confirmer la résolution du cas.

( Cela dit, juste pour ma culture perso, si vous savez comment réagit bcp avec les colonne blob... )

Merci beaucoup,

phg_dev

[dbaffaleuf]

L'agent de snapshot utilise l'équivalent de bcp pour effectuer les sorties et les injections de données. Sur le mini-poc que j'ai fait hier, il n'y a pas eu de problème de chargement de BLOB, mais je n'avais pas 500GB de données non plus. Il faut faire des tests plus poussés avec du maquettage et davantage de données. Si tu as déjà ton instance en 2008R2 et une instance de test par exemple en 2000SP4, tu peux déjà commencer à évaluer les différentes solutions.

[phg_dev]

Merci pour la réponse... mais pour des raisons internes, l'utilisation de la réplication par snapshot n'est pas possible...

J'ai vu une fonctionnalité de synchronisation de donnée entre deux bases présentes dans Toad for SQL server. Que pensez-vous de cette solution ?

Sinon, je vais être obligé de faire "à la main" ce rollback de migration...

Je vous remercie d'avance.

phg_dev

[dbaffaleuf]

Je ne connais pas Toad. Les interfaces graphiques me donnent des boutons, surtout si elles portent un nom de batracien

[SQLpro]

Je me permet d'attirer votre attention sur différents points de votre demande :

Envoyé par phg_dev

...( Les types de données restent les mêmes, on n'utilise pas les nouveaux type de données de SQL serveur 2008 R2. )

ATTENTION de nombreux types 2000 sont considérés comme obsolètes et vont être retirés dans la futur. Cela a été annoncé dans 2005 et nous en somme à 3 version (2005, 2008 et 2008 R2), en attendant 2012 (Denali). Vous prenez donc un gros risque de pérennité en sus de problèmes de performances.
Types concernés : TEXT, NTEXT, IMAGE, TIMESTAMP.
Extrait de l'aide en ligne :
"
Les types de données ntext, text et image seront retirés dans une prochaine version de Microsoft SQL Server. Évitez par conséquent d'utiliser ces types de données dans tout nouveau travail de développement et prévoyez la modification des applications qui les utilisent actuellement. Utilisez à la place les types nvarchar(max), varchar(max) et varbinary(max).
...
La syntaxe timestamp est abandonnée. Cette fonctionnalité sera supprimée dans une prochaine version de Microsoft SQL Server. Évitez d'utiliser cette fonctionnalité dans de nouveaux travaux de développement et prévoyez de modifier les applications qui utilisent actuellement cette fonctionnalité.
"

Envoyé par phg_dev

- Ma seconde contrainte est que cette volumétrie est essentiellement due a des colonnes blob...

C'est là que vous auriez peut être intérêt d'utiliser le stockage de fichiers à l'aide du FILESTREAM ! (nouveau dans 2008)

La migration elle-même sera faite avec un backup des base en SQL 2000 et un restore en SQL 2008 R2, pour chaque base, puis compilation de tous les script des objets non compatible.

Pourquoi pas un detach, copie, attach et conservation de la base ancienne en RFEAD ONLY ??? C'est encore plus simple, plus rapide et plus synchrone ! Le danger de la sauvegarde est que des applications peuvent produire des données pendant et après la sauvegarde !

Pour le retour arrière, la stratégie que j'envisage pour le moment est de faire une grosse mécanique à base de bcp, ( générée automatiquement à l'aide des infos dispos dans les vues de INFORMATION_SCHEMA ) dans le style suivant :

Pour chaque base :
Export des data en différentiel.
- Génération d'une liste des enregistrement a deleter, pour chaque table.
- Export des données en différentiel avec bcp, pour chaque table.
Import des data
Dans l'ordre montant des intégrités référentielles, pour chaque table :
- delete from openrowset ( la liste des enregistrement à deleter )
Dans l'ordre descendant des intégrités référentielles, pour chaque table :
- bulk insert des données en différentiel ( avec KEEPIDENTITY ) ( et utilisation du script de sqlpro pour détruire/reconstruire les index automatiquement )

Mes Questions :
1- les blob : Comment les blob sont gérés par bcp en export et import ?
2- Ma démarche : Vous sembles-t-elle valide ? Suis en train de réinventer la roue ? Des outils sur le marché font-ils ce genre de chose ?

1) pas terrible ! Lire : http://support.microsoft.com/kb/317016, voyez aussi du côté de Textcopy.exe
2) non, pas génial : long, lent et complex => chance de se tromper très haute et après...

Effectivement la réplication snapshot me parait idéale. Pourquoi ne voulez vous pas le faire et voulez-vous recourir à une usine à gaz beaucoup plus complexe alors que vous avez déjà la solution ?

A +

[mikedavem]

Une question bête :

N'avez vous pas un environnement de recette chez vous ?
Ce qui vous permettrait de tester votre migration en condition réel avec une charge réelle avant la mise en production ...

++

[phg_dev]

Bonjour,

Juste pour vous remercier tous de vos indications.
Sachez que la technique retenue est une mélange de réplication transactionnelle ( afin de pouvoir gérer nos gros volume de données, impossible à gérer avec une solution entièrement en réplication Snapshot ) et de réplication SnapShot pour tous les objets a faible volumétrie.

MErci !

phg_dev