Comment puis-je maintenir un schéma de base de données cohérent sur 18 bases de données (serveur SQL)?

Question

Nous avons 18 bases de données qui devraient avoir des schémas identiques, mais ce n’est pas le cas. Dans certains scénarios, un tableau a été ajouté à un, mais pas le reste. Ou, certaines procédures stockées étaient nécessaires dans une poignée de bases de données, mais pas les autres. Ou encore, notre administrateur de base de données a oublié de lancer un script pour ajouter des vues sur toutes les bases de données.

Quel est le meilleur moyen de synchroniser les schémas de base de données?

Answer 1

Pour les correctifs / nettoyages existants, il existe des outils, tels que SQLCompare , capable de générer des scripts pour la synchronisation des bases de données.

Pour les magasins .NET exécutant SQL Server, il existe également le Visual Studio Database Edition , qui permet de créer des scripts de modification des modifications de schéma pouvant être archivés dans le contrôle de source et générés automatiquement à l'aide de votre processus CI / build.

Answer 2

Comparaison SQL par Red Gate est un excellent outil pour cela. .

Answer 3

SQLCompare est le meilleur outil qui me soit utilisé pour trouver les différences entre les bases de données et les synchroniser.

Pour que les bases de données restent synchronisées, vous devez disposer de plusieurs éléments:

1) Vous avez besoin de politiques sur qui peut apporter des modifications à la production. Généralement, cela ne devrait être que le DBA (équipe DBA pour les grandes organisations) et 1 ou 2 backaps. Les sauvegardes ne doivent apporter des modifications que lorsque l'administrateur de base de données est absent ou en cas d'urgence. Les sauvegardes ne doivent PAS être déployées régulièrement. Définissez les droits de la base de données conformément à cette stratégie.

2) Un processus et des outils pour gérer les demandes de déploiement. Idéalement, vous aurez un environnement de développement, un environnement de test et un environnement de production. Les développeurs doivent effectuer le développement initial dans l'environnement de développement et faire en sorte que les modifications soient mises à l'essai et à la production, le cas échéant. Vous aurez besoin d'un moyen de laisser le DBA savoir quand pousser les modifications. Je ne recommanderais pas un processus où vous criez au prochain cube. Les grandes organisations peuvent avoir un comité de contrôle des modifications et les modifications ne sont apportées qu'une fois par mois. Les petites entreprises peuvent simplement demander aux développeurs de tester et, une fois les tests terminés, une demande de déploiement en production est transmise. Une petite entreprise pour laquelle j'ai travaillé utilisait suivi des problèmes pour ces demandes.

Utilisez tout ce qui fonctionne dans votre situation et votre budget, créez un processus et disposez d’outils adaptés à ce processus.

3) Vous avez dit que, parfois, les objets n'ont besoin que d'aller dans une poignée de bases de données. Avec seulement 18 bases de données, probablement sur un serveur, il est recommandé de faire en sorte que chaque objet Databse corresponde exactement aux objets. Seulement 5 bases de données ont besoin de usp_DoSchose? Et alors? Mettez-le dans chaque base de données. Ce sera beaucoup plus facile à gérer. Nous l'avons fait de cette manière sur un système à 6 serveurs avec environ 250 à 300 bases de données. Il y avait des exceptions, mais elles ont été regroupées. Les bases de données sur le serveur C ont cet ensemble d'objets supplémentaire. Les bases de données sur le serveur L ont cet autre ensemble.

4) Vous avez dit que parfois l'administrateur de la base de données oublie de déployer des scripts de modification sur tous les DB. Cela me dit qu'il a besoin d'outils pour déployer les changements. Il est probablement en train de prendre un script SQL, de l’ouvrir dans Query Analyzer ou Manegement Studio (ou ce que vous utilisez) et d’aller manuellement dans chaque base de données et d’exécuter le SQL. Ce n'est pas une bonne solution à long terme (ou à court terme). Les Red Gate (fabricants de SQLCompare ci-dessus) disposent de nombreux outils de qualité. Les MultiScript semblent pouvoir fonctionner à des fins de déploiement. J'ai travaillé avec un administrateur de base de données qui a écrit son propre outil dans SQL Server 2000 en utilisant O-SQl. Il faudrait un fichier SQL et l'exécuter sur chaque base de données sur le serveur. Il devait l'exécuter sur chaque serveur, mais il battait en cours d'exécution sur chaque base de données. J'ai également aidé à écrire un outil VB.net qui ferait la même chose, à la différence qu'il passerait également par une liste de serveurs, il ne devait donc être exécuté qu'une seule fois.

5) Contrôle de la source. Mon équipe actuelle n'utilise pas le contrôle de source et je n'ai pas assez de temps pour vous dire combien de problèmes cela cause. Si vous n'avez pas de système de contrôle de code source, procurez-vous-en un.

Answer 4

Je n'ai pas assez de réputation pour commenter la réponse ci-dessus, mais la version pro de SQL Compare dispose d'une API scriptable. Étant donné que vous devez répliquer du contenu dans toutes ces bases de données, vous pouvez l'utiliser pour créer un travail automatisé permettant de générer les scripts de modification ou de valider que toutes les bases de données sont synchronisées. De plus, il n’est pas beaucoup plus cher que la version standard.

Answer 5

Outre l'utilisation d'outils de comparaison de bases de données, vous devez disposer d'un administrateur de base de données avec 18 bases. Appliquez donc une stratégie selon laquelle seul l'administrateur de base de données peut modifier les tables au niveau de la base de données en limitant l'accès à CREATE et ALTER uniquement à l'administrateur de base de données. Sur votre base de données test et live. La base de données dev ne devrait pas en avoir, bien sûr! Assurez-vous que les développeurs qui ont créé ou modifié les schémas passent librement par le DBA.

Answer 6

Créez un seul script DDL / SQL contrôlé par la source pour chaque version et uniquement utilisez-le pour mettre à jour les bases de données. Les outils de diff peuvent être utiles, mais principalement pour vérifier que vous n'avez pas commis d'erreur et pour vous sortir du pétrin lorsque les stratégies échouent. Combinez les scripts DDL, SQL et de procédure stockée dans un seul script, de sorte qu'il n'est pas facile d'oublier & oublier; pour exécuter l'un des scripts.

Answer 7

Nous disposons d’un outil appelé DB Schema Difftective qui permet de comparer et de synchroniser les schémas de base de données. Avec notre autre outil, DB MultiRun, vous pouvez facilement déployer des scripts générés (synchronisation) sur plusieurs serveurs de base de données (sur la base de projets).

Answer 8

Je réalise que ce post est vieux, mais que TurnKey est correct. Si vous êtes un développeur travaillant dans un environnement d'équipe, le meilleur moyen de gérer un schéma de base de données pour une application volumineuse consiste à effectuer des mises à jour d'un schéma principal dans la source que vous utilisez. Écrivez simplement votre propre classe de script et votre base de données sera parfaite à chaque fois.