Bonjour à tous,
voila ma question du jour.
Peux-t'on importer un shema d'un utilisateur (qui possede divers tables, packages etc) moins quelques tables?
Quelqu'un dispose d'une idée brillantissime?
Bonjour à tous,
voila ma question du jour.
Peux-t'on importer un shema d'un utilisateur (qui possede divers tables, packages etc) moins quelques tables?
Quelqu'un dispose d'une idée brillantissime?
pourquoi ne pas la dropper après import ?
ou encore, créer une table du nom de celle dont tu ne veux pas et ne pas bloquer l'import en cas d'erreurs ?
ou encore exporter toutes les autres tables nommément ?
Moins quelques tables qui existent déjà côté cible et qu'il ne faut pas modifier ?
Ou qui n'existent pas côté cible, et dont on n'a pas besoin ?
Parce que dans ce dernier cas, il suffit de transférer le schéma complet et de virer les tables inutiles après coup...
Pour l'export, il est toujours loisible de spécifier la liste des tables à transférer dans le fichier de paramètres :
...
TABLES=(table1, table2...)
...
Consultant / formateur Oracle indépendant
Certifié OCP 12c, 11g, 10g ; sécurité 11g
Ma dernière formation Oracle 19c publiée sur Linkedin : https://fr.linkedin.com/learning/oracle-19c-l-administration
Il s'agit de tables qui existe déjà et auquel il ne faut pas toucher, donc c'est bien un import moins quelques tables
A part lister les tables je vois pas... sinon, un import FULL dans un autre shéma et déplacer les tables intéressantes dans le shéma souhaité pour finalement droper le shéma temporaire... mais là il faut de l'espace
et pour couronner le tout, les deux bases ne peuvent être arretées et les tables à ne pas importer ou exporter sont énormes. Donc la solution d'un shema buffer n'est pas acceptable.
bon cela confirme mon idée qu'il n"y a pas de solution acceptable.
Je pense qu'Il va faloir reformuler le probleme plus en amont....
pourquoi donc la solution consistant à lister les tables à exporter/importer n'est pas satisfaisante ? :
je rappelle aussi l'existence de la commande COPY sous SQL*Plus qui pourrait bien être utile ici
Exemple :
Le top étant de générer les n COPY avec un SELECT qui va bien
Code : Sélectionner tout - Visualiser dans une fenêtre à part COPY from user/passwf@base_src to from user/passwf@base_src CREATE matable (col1,col2,...,coln) USING select * from matable;
Si le probleme c'est de ne pas importer dans des tables deja existantes, il suffit de mettre l'option IGNORE=N. Les tables non presentes dans le schema seront importées, pour celles qui sont deja là, seul un message d'erreur sera generé.
alors on touche au but, c'est exactement ce que j'atendais!Envoyé par thomasjcj
Je teste et vous tient au courant!
Si dans la base dans laquelle tu importes, la table à laquelle tu ne dois pas toucher à les même colonnes que celle du dump, en important, certes, la table ne sera pas recréée, mais les données du dump seront intégrées dans la table....
bon dejà merci à tous, j'ai bien avancé dans mon problème. Maintenant je peux exporter mon schéma moins une table.
Un tout petit peut plus complexe maintenant.
Peux-t'on importer un schéma moins une table?
oui, un import FULL de ton DUMP qui ne contient que tes tables utiles
ou alors, un import avec la clause TABLE=(liste de tables à importer)
evidement, mais il ne faut pas oublier que dans un export ou un import, il n'y a pas que des tables.
Il y a aussi des roles, des autorisations dessus, des liens bd, des séquences, des snapshots, des contraintes d'integrité, des synonymes, des triggers des procédures et j'en oublie peut être.
Donc, moi je cherche à exporter tout un svhéma (donc tout ce que je viens de citer) moins une table ou deux.
Je ne suis pas sûre qu'un script dynamique puisse être utile ici car on peut peut être choisir ces tables mais c'est tout.
Quand au reste....
D'ou ma question!
Et en renommant ta table avant d'importer dans ta base cible, puis en faisant un drop de la table faussement importée et en renommant une nouvelle fois la sauvegarde ?
Comme cela, tu fais un import du schema et tu conserves les données de ta table "protégée"
Sous 10g, les utilitaires imp et exp ont enormement evolue et permette une bien plus grande selectivité des objets.
Qu'on se le dise...
Moi je m'y prendrais comme suit :Envoyé par aline
- extraction du script de recréation de tous les objets (sauf les tables) via TOAD (menu DBA --> Generate schema script) ou autre outil possédant la même fonctionnalité
- export en mode TABLE en spécifiant la liste des tables, sauf celle à rejeter. Noter qu'en 9i on peut utiliser des caractères génériques (%) dans le nom des tables
- import desdites tables
- exécution des scripts obtenus à la première étape
Consultant / formateur Oracle indépendant
Certifié OCP 12c, 11g, 10g ; sécurité 11g
Ma dernière formation Oracle 19c publiée sur Linkedin : https://fr.linkedin.com/learning/oracle-19c-l-administration
oui en effet sauf que il y a un ordre de création des objets et les tables sont à peut près au milieu. Donc il faut segmenter.Envoyé par Pomalaix
Je ne dispose pas de Toad (je ne l'ai d'ailleurs jamais utilisé!) mais j'ai déjà fait ce genre de chose avec le package dbms_metadata.
J'esperai justement ne pas passer par la mais j'ai bien l'impression que je ne vais pas ycouper..
merci quand même!
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager