Nous avons une base de données Oracle Enterprise en production et une autre instance que nous utilisons à la fois comme base de données QA et de développement. L'assurance qualité a demandé que des schémas distincts leur soient fournis dans la base de données afin qu'ils puissent tester les applications isolées des modifications apportées par les développeurs. Pour un exemple, disons le schéma utilisé en développement et celui qui sera utilisé en production s'appelle APP_OWNER et APP_OWNER pourrait contenir des tables qui ont des références FK aux tables d'autres schémas, disons dans BASE_OWNER. L'idée serait de créer un schéma QA_APP_OWNER et de récupérer les données de production dans ce schéma ainsi que d'extraire les tables BASE_OWNER référencées dans le schéma QA_APP_OWNER. Une illustration simplifiée serait:Outils pour créer un environnement de type "test" sur une base de données de développement
Prod Setup:
----------------
BASE_OWNER.users
APP_OWNER.users (synonym to BASE_OWNER.users)
APP_OWNER.audit_users with FK to BASE_OWNER.users
QA Setup:
----------------
QA_APP_OWNER.users (copied data from prod)
QA_APP_OWNER.audit_users (FK to APP_OWNER.users)
Cela devrait être possible car nous n'écrivons pas de code/SQL, y compris les schémas. (c'est-à-dire que nous créons des synonymes basés sur des schémas pour des tables en dehors du schéma dans lequel s'exécute l'application)
Ma question est, existe-t-il de bons outils pour créer facilement un tel schéma QA_APP_OWNER? Je suis conscient des options d'exportation de FROMUSER TOUSER, mais si je me souviens bien, cela va déplacer un schéma entier vers un autre schéma, mais il ne me permettra pas de me rendre à l'endroit où je veux être. références sur les FK. Je ne suis pas au courant d'un moyen d'exporter le DDL, de le changer manuellement, puis d'importer les données manuellement. Ce n'est pas une option attrayante car de nombreuses références concernent des tables qui référencent également d'autres tables et le schéma APP_OWNER possède lui-même une pléthore de tables. Ma peur est la plus manuelle, le plus probable d'une erreur qui permettra à quelque chose d'être testé à se casser lorsqu'il est déplacé vers l'environnement de production. Une bonne solution serait d'avoir des licences pour une instance de développement et de développement d'Oracle, mais on m'a dit "ce n'est pas dans le budget" de le faire.
Vérifiez auprès de votre représentant Oracle. Avec les licences de processeur, vous devriez être en mesure d'exécuter autant d'instances sur votre serveur sous licence que vous le souhaitez. – DCookie
Nous n'avons pas la possibilité d'exécuter une autre instance. –
'isolé des modifications apportées par les développeurs' au schéma, peut-être, mais pas à partir de changements de base de données (patches, paramètres d'initialisation, etc.). Avoir un environnement d'assurance qualité distinct est une bonne idée, sinon essentielle, mais le faire comme ça ne semble pas vous apporter beaucoup. Il serait peut-être préférable de dupliquer exactement les schémas de production et les synonymes dans le contrôle qualité pour repérer les problèmes potentiels avec de nouveaux objets avant la mise en production. (Et si vous ne pouvez pas avoir une nouvelle instance de QA, pouvez-vous avoir une nouvelle instance de dev à la place? * 8-) –