Approche recommandée pour modifier le schéma d'une base de données SQL de production?

Question

Supposons qu'il existe une base de données contenant plus de 100 tables et qu'une fonctionnalité majeure soit ajoutée, ce qui nécessite la modification de 20 tables existantes et l'ajout de 30 autres. Les modifications ont été effectuées sur une longue période (6 mois) par plusieurs développeurs sur la base de données de développement. Supposons que les modifications ne rendent pas les données de production existantes invalides (par exemple, il existe des valeurs par défaut/des valeurs nulles autorisées sur les colonnes ajoutées, il n'y a pas de nouvelles relations ou contraintes qui n'ont pas pu être satisfaites).

Quelle est la manière la plus simple de publier ces modifications dans le schéma dans la base de données de production? De préférence, sans fermer la base de données pendant un laps de temps prolongé.

Answer 1

Il n'y a pas de réponse générique sur la façon de faire des 'changements' sans temps d'arrêt. La réponse dépend vraiment d'un cas à l'autre, en fonction de ce que sont exactement les changements. Certaines modifications ont un impact minime (par exemple, l'ajout de colonnes aux tables existantes sans modification de la taille des données, comme une nouvelle colonne nullable qui augmente la taille du bit nul) et D'autres changements vont détruire le temps d'arrêt (toute opération qui va changer la taille des données forcera et indexera reconstruire et verrouiller la table pour la durée). Certains changements sont impossibles à appliquer sans temps d'arrêt * significatif *. Je connais des cas où les modifications étaient appliquées en parallèle: une copie de la base de données est créée, la réplication est configurée pour la garder à jour, puis la copie est changée et synchronisée, enfin les opérations sont déplacées vers la copie modifiée qui devient la base de données master. Il ya une présentation au PASS 2009 given by Michelle Ufford qui mentionne comment godaddy a traversé un tel changement qui a duré semaines.

Mais, à une échelle inférieure, doit appliquer les modifications via un script bien testé et mesurer l'impact sur l'évaluation du test.

Mais la vraie question est: est-ce que cela va être le dernier changements que vous faites jamais au schéma? Enfin, vous avez découvert le schéma parfait pour l'application et la base de données de production ne changera jamais? Félicitations, une fois que vous aurez réussi, vous pourrez vous reposer. Mais de façon réaliste, vous allez faire face au même problème en 6 mois. le vrai problème est votre processus de développement, avec les développeurs et apporter des modifications à partir de SSMS ou de VS Server Explored directement dans la base de données.Votre processus de développement doit faire un effort conscient pour adopter une stratégie de changement de schéma basée sur des versions et des scripts T-SQL, comme celui décrit dans Version Control and your Database.

Answer 2

Ecrivez un script T-SQL qui effectue les modifications nécessaires. Testez-le sur une copie de votre base de données de production (restauration à partir d'une sauvegarde récente pour obtenir la copie). Corrigez les erreurs inévitables que le test va découvrir. Répétez jusqu'à ce que le script fonctionne parfaitement.

Ensuite, quand il est temps pour la migration réelle: verrouiller le DB afin que seuls les administrateurs puissent se connecter. Faites une sauvegarde. Exécutez le script. Vérifiez les résultats. Remettez DB en ligne.

La partie la plus longue sera la sauvegarde, mais vous seriez fou de ne pas le faire. Vous devez savoir combien de temps les sauvegardes prennent, le processus global ne prendra pas beaucoup plus de temps que cela, donc c'est combien de temps votre temps d'arrêt devra être. Le milieu de la nuit fonctionne bien pour la plupart des entreprises.

Answer 3

J'ai utilisé dbdeploy avec succès pendant quelques années maintenant. Il permet à vos développeurs de créer de petits deltas de changement de sql qui peuvent ensuite être appliqués à votre base de données. Les changements sont suivis par une table changelog dans la base de données afin qu'il sache quoi appliquer.

Answer 4

Utilisez un outil pour créer un script diff et l'exécuter au cours d'une fenêtre de maintenance. J'utilise RedGate SQL Compare pour cela et en ai été très content.