Discussion :

[aline]

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?

[LeoAnderson]

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 ?

[Pomalaix]

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...)
...

[aline]

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

[orafrance]

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

[aline]

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....

[LeoAnderson]

pourquoi donc la solution consistant à lister les tables à exporter/importer n'est pas satisfaisante ? :

[orafrance]

je rappelle aussi l'existence de la commande COPY sous SQL*Plus qui pourrait bien être utile ici

Exemple :

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;

Le top étant de générer les n COPY avec un SELECT qui va bien

[thomasjcj]

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é.

[LeoAnderson]

oui, mais les données ????

[aline]

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!

Je teste et vous tient au courant!

[LeoAnderson]

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....

[aline]

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?

[orafrance]

oui, un import FULL de ton DUMP qui ne contient que tes tables utiles

[CD]

ou alors, un import avec la clause TABLE=(liste de tables à importer)

[aline]

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!

[CD]

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"

[thomasjcj]

Sous 10g, les utilitaires imp et exp ont enormement evolue et permette une bien plus grande selectivité des objets.
Qu'on se le dise...

[Pomalaix]

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!

Moi je m'y prendrais comme suit :
- 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

[aline]

Moi je m'y prendrais comme suit :
- 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

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.
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!