Quel est votre flux de travail pour planifier une migration de données?

Tellement de fois j'ai été amené à la fin d'un effort de développement logiciel et on m'a dit quelque chose comme "ok, nous avons tout ce nouveau code et cela nécessite des tables pour changer et des données pour migrer".

Il semble que chaque fois qu'il s'agit d'un scénario unique, tiré à partir de la hanche et de la meilleure estimation. J'ai l'impression que c'est mon ensemble de compétences le plus faible en tant que DBA.

Je voudrais entrer dans certains modèles pour approcher, gérer et tester les migrations de données .

Veuillez m'indiquer certaines des meilleures pratiques et / ou où je peux obtenir du matériel d'apprentissage pour m'aider à m'améliorer dans ce domaine.

Chaque fois que je l'ai fait, nous avons fait deux passes ...

1. prenez un instantané et, en travaillant sur un autre serveur, utilisez-le pour déterminer ce qui doit être fait pour la migration et créez un script.
2. une fois qu'ils ont le script en main, le snapshop est restauré sur le système de test, et il est chronométré pour voir s'il fonctionnera dans le temps requis, ou il est réglé et modifié jusqu'à ce qu'il le puisse.
3. faire signer aux parties prenantes que rien ne semble mal avec les données du système de test.

Ensuite, sur un week-end, vous avez une panne programmée:

1. Vendredi soir, les systèmes qui utilisent la base de données sont arrêtés, une sauvegarde complète à froid est effectuée et les scripts sont exécutés pour migrer / modifier / quoi que ce soit vers les données
2. Les systèmes sont ramenés sous une adresse privée ou configurés de manière à ce qu'ils ne soient ouverts à personne d'autre qu'aux parties prenantes pour les tests d'acceptation
3. Si les parties prenantes l'approuvent, le système est mis en ligne et rendu public; sinon, la base de données est restaurée à partir de la sauvegarde effectuée le vendredi soir et vous recommencez le processus.

Avec notre calendrier, les gens de la base de données disposaient généralement de 18 h le vendredi à 10 h le samedi pour exécuter les scripts de sauvegarde et de migration, notre objectif était donc qu'ils s'exécutent en moins de 8 heures (dont 6 étaient des sauvegardes), donc nous '' J'ai un peu de temps pour nos tests et corrections avant qu'ils ne soient communiqués aux parties prenantes.

Les intervenants ont reçu leurs fenêtres horaires à l'avance, ils ont donc su laisser leur week-end ouvert pour les tests au début de la fenêtre. On leur dirait également la fin de leur fenêtre, généralement le dimanche après-midi, où si tout le monde ne s'était pas déconnecté, nous devions commencer à reculer.

Oh, et bien sûr ... si quelqu'un a changé pendant l'un ou l'autre des tests d'acceptation, et que nous avons fait un changement, cela signifiait que toutes les approbations des parties prenantes étaient annulées, et ils devaient refaire le test ... alors nous essayons de leur donner un certain temps pour rechercher les problèmes et exécuter les corrections en tant que lot, plutôt que de les appliquer un par un.

Heureusement, les seules fois où j'ai eu une de ces situations où nous ne pouvions pas avoir de temps d'arrêt significatif, les systèmes que je migrais étaient alimentés à partir de scripts, pas de saisie utilisateur, donc je pouvais simplement avoir deux systèmes parallèles et les échanger quand les choses ont été approuvées. (Une seule fois, il y a eu un problème, lorsque mon patron a insisté pour que nous prenions une sauvegarde complète, ne comprenant pas que le tout allait toujours être en ligne sur une IP différente ... alors qu'est-ce qui aurait dû être une interruption de 5 minutes sur un mauvaise journée est devenue une panne de 5 heures.)

Tout dépend du volume de données par rapport à la puissance du matériel supportant la base de données et des accords sur la disponibilité du système. Avez-vous un temps d'arrêt ou faut-il que tout se fasse en ligne? Commencez à nettoyer les données, en effaçant autant que possible les lignes obsolètes. C'est un projet sur lui-même. Si les données sont propres et précieuses, demandez à l'utilisateur de décider du temps d'arrêt. Si un temps d'arrêt est disponible, il est assez simple, s'il s'agit d'une transformation connue qui doit être appliquée aux données existantes pour former la collection mise à jour. S'il n'y a pas - ou très peu - de temps d'arrêt autorisé, le défi commence. Oracle prend cela en charge de plusieurs façons, comme la redéfinition de table en ligne et - nouveau dans la redéfinition basée sur l'édition 11g. Avec la redéfinition des tableaux en ligne, vous pouvez préparer les tableaux à prendre leur nouvelle forme. Cela peut être fait pendant que l'application s'exécute sur l'ancienne forme de la table [s]. S'ils sont tous prêts, vous pouvez passer à la nouvelle forme des tableaux. Ce sera aussi le moment d'introduire le nouveau code d'application et en même temps marque le début du temps d'arrêt requis pour mettre la nouvelle application en place. Les données historiques plus anciennes peuvent être préparées avant la migration des données en direct et synchronisées à l'aide d'outils comme Oracle Golden Gate. Dans un tel scénario, vous créez efficacement une nouvelle base de données qui reprend le rôle de l'ancienne base de données. La redéfinition basée sur l'édition est mieux adaptée si aucune modification de table n'est nécessaire. Il y a des tonnes d'options à considérer et je pense qu'il est difficile de donner une bonne règle qui fonctionne toujours. Ce sera aussi le moment d'introduire le nouveau code d'application et en même temps marque le début du temps d'arrêt requis pour mettre la nouvelle application en place. Les anciennes données historiques peuvent être préparées avant la migration des données en temps réel et synchronisées à l'aide d'outils comme Oracle Golden Gate. Dans un tel scénario, vous créez efficacement une nouvelle base de données qui reprend le rôle de l'ancienne base de données. La redéfinition basée sur l'édition est mieux adaptée si aucune modification de table n'est nécessaire. Il y a des tonnes d'options à considérer et je pense qu'il est difficile de donner une bonne règle qui fonctionne toujours. Ce sera également le moment d'introduire le nouveau code d'application et marquera en même temps le début du temps d'arrêt nécessaire à la mise en place de la nouvelle application. Les données historiques plus anciennes peuvent être préparées avant la migration des données en direct et synchronisées à l'aide d'outils comme Oracle Golden Gate. Dans un tel scénario, vous créez efficacement une nouvelle base de données qui reprend le rôle de l'ancienne base de données. La redéfinition basée sur l'édition est mieux adaptée si aucune modification de table n'est nécessaire. Il y a des tonnes d'options à considérer et je pense qu'il est difficile de donner une bonne règle qui fonctionne toujours. Les données historiques plus anciennes peuvent être préparées avant la migration des données en direct et synchronisées à l'aide d'outils comme Oracle Golden Gate. Dans un tel scénario, vous créez efficacement une nouvelle base de données qui reprend le rôle de l'ancienne base de données. La redéfinition basée sur l'édition est mieux adaptée si aucune modification de table n'est nécessaire. Il y a des tonnes d'options à considérer et je pense qu'il est difficile de donner une bonne règle qui fonctionne toujours. Les données historiques plus anciennes peuvent être préparées avant la migration des données en direct et synchronisées à l'aide d'outils comme Oracle Golden Gate. Dans un tel scénario, vous créez efficacement une nouvelle base de données qui reprend le rôle de l'ancienne base de données. La redéfinition basée sur l'édition est mieux adaptée si aucune modification de table n'est nécessaire. Il y a des tonnes d'options à considérer et je pense qu'il est difficile de donner une bonne règle qui fonctionne toujours.

C'est un sujet intéressant, Ronald.

Bonnes réponses jusqu'à présent. J'ajouterai quelques points supplémentaires pour examen.

Premièrement, lorsque vous pouvez effectuer vos migrations avec du langage DML SQL simple, vous pouvez largement compter sur votre moteur SQL pour vous assurer que toutes les lignes sont correctement traitées. J'ai été impliqué dans des migrations, cependant, où une partie de la migration était un peu plus compliquée - il y a eu des transformations de données réelles lorsque les données ont été déplacées dans une nouvelle structure. Dans ces cas, il est important que vous disposiez d'un processus capable de gérer les éléments suivants:

• Comptez les enregistrements par rapport aux enregistrements traités.
• Détectez les erreurs pendant la transformation et traitez-les de manière à permettre à la transformation de se poursuivre et au retraitement des "mauvais" enregistrements une fois que vous avez identifié un correctif.
• Le nombre d'enregistrements doit inclure les «mauvais» enregistrements, c'est-à-dire les enregistrements entrants = les enregistrements sortants bons + les mauvais enregistrements
• Si votre transformation modifie le nombre d'enregistrements (un enregistrement d'entrée devient plus d'un enregistrement de sortie, par exemple), vous pouvez prédire le nombre d'enregistrements de sortie avec lesquels vous vous retrouverez, puis tester vos résultats par rapport à ce nombre.

L'autre point que j'ajouterais est qu'il est important d'avoir un plan pour ce que vous allez faire si / quand les choses ne se passent pas comme prévu. C'est vraiment une fonction du déploiement dans son ensemble, mais c'est celui qui semble être passé sous silence assez fréquemment pour que je pense qu'il valait la peine d'être mentionné.

Un aperçu de la façon de le faire

Commencer avec

• Vous avez la base de données "after" dans test / UAT / quel que soit "DB de travail"
• Vous avez la base de données "avant" en production. Utilisez-le donc pour créer une copie de la production quelque part = "DB de référence". Et un autre comme "DB de test de script"
• J'espère également que vous avez un tas de scripts de développement avec vos ALTER, etc.

Ensuite, téléchargez les outils Red Gate Compare ou quelque chose comme Embarcadero SQL Change Manager . Vous ne pouvez pas facilement migrer sans lui. Le coût est insignifiant pour le temps gagné. Et surtout, les scripts générés apportent des modifications en une seule transaction, ce qui signifie un déploiement propre

À présent,

• générer des scripts de modification et de restauration à l'aide des outils de comparaison entre la "référence" et la "modification"
• appliquer le script de changement à "test de script" et comparer à "DB de travail"
• appliquer le script de restauration à "test de script" et comparer à "et comparer à" DB de travail "

Maintenant, vous avez des scripts de modification et de restauration sûrs et testés à appliquer à tout moment.

Et bien sûr, vous sauvegardez la base de données avant tout changement car statistiquement, la merde finira toujours par arriver.

Les outils Red Gate peuvent également se comparer à un dossier sous contrôle de source. Nous capturons ensuite les ALTERs, etc. dans notre contrôle de source séparément pour les scripts de changement réels.