Meilleur moyen de créer un script d'annulation SQL Server?

Question

Je travaille sur certaines modifications de schéma d'une base de données existante.

J'ai sauvegardé la base de données pour obtenir une copie du développeur, et apporté mes modifications. Je créerai un script unique permettant de migrer les modifications sur la machine de production en une seule transaction.

Existe-t-il une bonne pratique pour créer un script d'annulation en cas de problème de déploiement? Avant, j’écrivais ensuite à la main selon le modèle suivant:

• Supprimer les nouvelles contraintes et index
• Modifiez les tables pour supprimer les nouvelles colonnes
• Supprimer les tables ajoutées
• transaction validée

Existe-t-il une meilleure approche?

Answer 1

En gros, je pense qu'il n'y a pas grand chose à ajouter, mis à part votre approche. C’est comme cela que nous procédons dans notre entreprise. Nous, les développeurs, sommes responsables de la création du script et du script d’annulation, et de laisser la base de données dans le même état qu’avant l’application des modifications initiales. Ensuite, les administrateurs de base de données l'exécutent en production. S'il y a un problème, ils exécutent le script d'annulation et tout est rentré dans l'ordre. Il suffit de garder à l’esprit les dépendances et l’ordre dans lequel vous modifiez vos objets, puis de créer le script de restauration en arrière.

Answer 2

Il vous manque la cinquième étape

• Supprimer les nouvelles contraintes et index
• Modifiez les tables pour supprimer les nouvelles colonnes
• Supprimer les tables ajoutées
• transaction validée
• Testez le script avant de l'exécuter en production

Une approche plus efficace consiste à enregistrer les modifications au fur et à mesure, comme RoR < a href = "http://wiki.rubyonrails.org/rails/pages/UsingMigrations" rel = "nofollow noreferrer"> migrations do . Pour chaque modification de base de données, vous créez un script qui applique et modifie la modification (à votre choix, bien sûr). Vous pouvez ensuite avoir ces scripts sous contrôle de version, tout comme votre code.

De plus, si vous conservez un numéro de version dans la base de données, vous pouvez l’automatiser un peu plus, en identifiant chaque script avec un numéro de version et en l’augmentant ou le diminuant en fonction de l’action effectuée.

Answer 3

S'il s'agit d'une base de données relativement petite, effectuez une sauvegarde avant d'appliquer la mise à niveau. Si tout se passe mal, vous effectuez une restauration.

Une fois la mise en ligne et les nouvelles données saisies, vous ne pouvez plus les restaurer. Vous devez juste résoudre les problèmes.

Answer 4

Si vous utilisez un outil tel que SQL Compare de Redgate, vous pouvez effectuer la comparaison entre les deux bases de données dans les deux sens et les utiliser pour créer les scripts dont vous avez besoin. le script dev to prod aurait les modifications que vous apportez et le script prd to dev reviendrait à l'état de la base de données de production d'origine. Cela vous permet de ne rien oublier dans les deux scripts.

Answer 5

Avec SQL Server 2005 ou une version plus récente, vous pouvez également créer un instantané de base de données, qui vous permet de revenir à cet état à tout moment. Consultez cette page pour plus d'informations:

http://msdn.microsoft.com/en-us/library /ms175158.aspx