Comment mettez-vous à jour vos modifications de base de données Oracle?
Je suis intéressé de savoir quelles méthodes d'autres personnes utilisent pour suivre les modifications apportées à la base de données, y compris les modifications de définition de table, les nouveaux objets, les modifications de packages, etc. Utilisez-vous des fichiers plats avec un système de contrôle de version externe? Des déclencheurs? D'autres logiciels?
Sur les sites sur lesquels j'ai travaillé, toutes les modifications qui doivent être apportées aux instances de production doivent être scriptées en tant que scripts de modification qui s'exécuteront dans SQL * Plus; en outre, les scripts nécessaires pour recréer tous les objets de schéma à partir de zéro doivent être mis à jour. Tous ces scripts sont archivés dans le contrôle des modifications et migrés à partir de là.
Vous pouvez auditer les modifications DDL ou utiliser des déclencheurs DDL pour détecter les modifications, ou même utiliser un logiciel de comparaison pour comparer deux instances, mais ces méthodes sont aveugles; souvent, un développeur apportera et annulera un certain nombre de modifications à un schéma (par exemple, de petites modifications de test, la création de tables factices pour tester des concepts, etc.) avant de déterminer ce qui doit être changé exactement.
J'ai beaucoup réfléchi et lu sur ce sujet. Il s'agit d'un vaste sujet de contrôle de configuration et de stratégie de gestion des changements. CMMI a un domaine dans cette rubrique. Même dans les entreprises qui ont une accréditation CMMI 3-5, elles ne contrôlent parfois pas la version de leurs bases de données.
Il convient de répondre à cette question tout en gardant à l'esprit les contraintes .
- Vous avez un gardien et chaque DDL est exécuté par ce gardien.
- D'autres personnes peuvent exécuter des instructions DDL.
- Il vous suffit de consigner les modifications apportées, mais vous n'avez pas besoin de comparer de grandes différences.
- La conception de votre base de données se fait via un outil externe puis est publiée dans la base de données. Cet outil externe peut même être des scripts DDL dans le contrôle de code source. Mais le point clé est que vous le contrôlez à la source puis le publiez dans la base de données.
- Vous n'avez pas besoin de connaître les changements instantanés mais de temps en temps: c'est-à-dire toutes les heures, tous les jours.
- Vous avez une structure de serveur définie: Développement, Test, Production. Et une bonne stratégie de test.
Réponse 1
- si 1, 4,6 est vrai, vous pouvez utiliser un contrôle de source externe. Par exemple
- Embercadero dispose d'un outil de gestion des modifications de base de données ( http://www.embarcadero.com/products/db-change-manager-xe ). Qui a la capacité de désosser une base de données (Oracle) et de la mettre dans leur contrôle de source. Ensuite, n'importe quel nombre de développeurs, dba peut accéder à ce schéma et y apporter des modifications.
- Oracle SQL Designer est similaire à cette approche.
- Mettre vous créez des scripts de table pour le contrôle de source (svn, Mercurial, etc.) et les maintenir également la même chose.
- http://www.liquibase.org est l'approche automatisée ci-dessus.
- J'ai écrit un générateur de code qui a généré des instructions DAL (Data Access Layer), DDL (Create Table). Nous leur avons mis le contrôle des sources et y avons maintenu. Je pense qu'une solution dédiée comme liquibase pourrait mieux fonctionner.
Cette approche fonctionne bien si vous en avez 6. Vous mettez des instructions DDL, qui est également un code, dans le contrôle de code source et le maintenez. Personne ne changera les serveurs de test et de production sans considération.
Les inconvénients sont que si vous apportez des modifications aux serveurs de production ou de test pour une raison quelconque, une correction rapide de bogue, un changement de clé primaire, etc. Vous devez également appliquer ces modifications au serveur de développement. Puisqu'en fait, le serveur de développement est votre VÉRITÉ À LA TERRE. Pas l'inverse.
Il s'agit d'une approche très orientée développeur. Mais lorsque vous développez un nouveau module pour la première fois, cela fonctionne plutôt bien.
Réponse 2 - si 1 et 6 vrai:
Une approche similaire à la réponse 1 consiste à maintenir un serveur de développement. Tout le monde l'utilise le change. Que le moment de la mise à jour. Vous utilisez un outil de comparaison de base de données. Obtenez-les en tant que scripts, mettez-les sous contrôle de source.
- Red Gate Schema Compare supports Oracle
- Embercadero has similar tool
- https://github.com/carbonfive/db-migration
- http://www.sumsoftsolutions.com/svco/ (I have not used this product but I believe it belongs to this category.)
- Rails Active Migration (http://www.Oracle.com/technetwork/articles/kern-Rails-migrations-100756.html)
La différence entre la réponse 1 et la réponse 2 est que, dans la réponse 1, vous collectez des instructions DDL pour la base de données entière et vous les stockez. Dans la réponse 2, vous devez stocker chaque version du changement.
- Début
- V1
- V2
- V3
- ...
Si vous mettez une colonne dans une table et décidez plus tard de la supprimer. Vos scripts le montreront dans la réponse2 tandis que dans la réponse1, vous ne verrez que la dernière version. Et vous devez comparer V2 et V1 pour voir les différences. Personnellement, j'aime mieux la réponse 1 car je peux facilement comparer Start et V3, V1 et V3. Dans la réponse 2, je dois rechercher toutes les modifications. Également dans la réponse 2, le script dans le contrôle des sources a tendance à être un script complexe et complexe. Difficile de trouver des informations.
Réponse 3 Si 3 est vrai. Notez que dans cette situation, vous n'avez pas de contrainte 6, c'est-à-dire que vous n'avez pas de serveurs de développement, de test et de produit. Seul serveur de production. Vous pouvez utiliser des déclencheurs DDL pour consigner les modifications apportées. Ceci est principalement utilisé pour décourager les gens d'abuser de leurs subventions DDL. En cas de problème, vous pouvez trouver responsable. Pour que cela fonctionne, chaque personne doit se connecter avec son compte d'utilisateur et le compte d'application ne doit pas avoir de droits DDL. Étant donné que chaque développeur connaît le compte d'application et peut l'utiliser.
Réponse 4 Si vous avez 3 et 5. Notez que dans cette situation vous n'avez pas de contrainte 6, c'est-à-dire: vous n'avez pas Développement, Test, Serveurs de produits. Seul serveur de production. Au lieu de déclencheur pour stocker les modifications. Vous utilisez un outil externe pour rechercher des modifications et stocker des scripts DDL dans le contrôle de code source.
Si ces outils ont la capacité d'enregistrer qui a fait des changements, ce serait utile. Notez que dans cette solution, vous perdez des DDL supplémentaires qui sont effectués à intervalles.
Je viens de trouver un tutoriel intéressant sur l'utilisation de Liquibase pour la version Oracle.
Sur certaines de nos bases de données, nous utilisons des déclencheurs DDL pour intercepter les modifications et les enregistrer dans une table. Nous avons ensuite une interface Web pour récupérer ces versions précédentes. Il présente de graves inconvénients, c'est pourquoi je recherche des alternatives, mais c'est facile et c'est mieux qu'aucun contrôle de version.
Nous avons utilisé Schema Version Control pour nos bases de données 11g, mais nous avons eu quelques problèmes avec le logiciel sur 11.2. Sans ces problèmes sur lesquels nous travaillons toujours, ce serait un excellent produit.
Nous avions l'habitude de travailler avec Oracle SQL Designer, qui (je suppose) a été remplacé par SQL Developer Data Modeler maintenant. http://www.Oracle.com/technetwork/developer-tools/datamodeler/overview/index.html
C'était assez sympa, surtout. la possibilité de définir des DOMAINES pour les colonnes et de gagner beaucoup de temps en créant des colonnes communes (mtime, ctime etc.).
Nous utilisons Oracle-ddl2svn ensemble d'outils (dont je suis l'auteur) pour automatiser le stockage du schéma Oracle DDL dans SVN.
Jetez un oeil sur DBmaestro TeamWork dont son approche gestion de changement imposée par la base de données .
divulgation: je travaille pour dbMaestro
Je ne l'ai jamais utilisé, mais http://blog.gitora.com/ est une autre option.