importer un shema moins une table [Résolu]

aline · 01/10/2004, 14h39

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 · 01/10/2004, 14h46

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 · 01/10/2004, 14h47

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 · 01/10/2004, 14h58

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 · 01/10/2004, 15h03

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 · 01/10/2004, 15h19

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 · 01/10/2004, 15h24

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

:

orafrance · 01/10/2004, 15h34

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 · 01/10/2004, 15h39

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 · 01/10/2004, 15h43

oui, mais les données ????

aline · 01/10/2004, 15h47

Citation:

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

alors on touche au but, c'est exactement ce que j'atendais!

Je teste et vous tient au courant!

LeoAnderson · 01/10/2004, 15h50

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 · 04/10/2004, 11h43

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 · 04/10/2004, 12h02

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

CD · 04/10/2004, 12h15

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

aline · 04/10/2004, 13h46

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 · 04/10/2004, 14h17

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 · 04/10/2004, 14h33

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 · 04/10/2004, 14h45

Citation:

Envoyé par 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!

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 · 04/10/2004, 17h29

Citation:

Envoyé par Pomalaix

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!

01/10/2004, 14h39	#1
aline Membre éclairé Inscription : juin 2004 Messages : 487 Détails du profil Informations forums : Inscription : juin 2004 Messages : 487 Points : 373 Points : 373	importer un shema moins une table 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?
	00

01/10/2004, 15h03	#5
orafrance Rédacteur/Modérateur Inscription : janvier 2004 Messages : 15 861 Détails du profil Informations personnelles : Âge : 35 Informations forums : Inscription : janvier 2004 Messages : 15 861 Points : 16 212 Points : 16 212	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 __________________ Règles et liens du forum Oracle Guide Oracle Pense-bête du DBA Oracle : Exemple
	00

01/10/2004, 15h34	#8
orafrance Rédacteur/Modérateur Inscription : janvier 2004 Messages : 15 861 Détails du profil Informations personnelles : Âge : 35 Informations forums : Inscription : janvier 2004 Messages : 15 861 Points : 16 212 Points : 16 212	je rappelle aussi l'existence de la commande COPY sous SQLPlus 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 __________________ Règles et liens du forum Oracle Guide Oracle Pense-bête du DBA Oracle : Exemple
	00

04/10/2004, 12h02	#14
orafrance Rédacteur/Modérateur Inscription : janvier 2004 Messages : 15 861 Détails du profil Informations personnelles : Âge : 35 Informations forums : Inscription : janvier 2004 Messages : 15 861 Points : 16 212 Points : 16 212	oui, un import FULL de ton DUMP qui ne contient que tes tables utiles __________________ Règles et liens du forum Oracle Guide Oracle Pense-bête du DBA Oracle : Exemple
	00

01/10/2004, 14h46	#2
LeoAnderson Expert Confirmé Inscription : septembre 2004 Messages : 2 942 Détails du profil Informations forums : Inscription : septembre 2004 Messages : 2 942 Points : 2 972 Points : 2 972	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 ?
	00

01/10/2004, 14h47	#3
Pomalaix Rédacteur Inscription : décembre 2002 Messages : 2 396 Détails du profil Informations personnelles : Localisation : France, Var (Provence Alpes Côte d'Azur) Informations forums : Inscription : décembre 2002 Messages : 2 396 Points : 3 294 Points : 3 294	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...) ...
	00

01/10/2004, 14h58	#4
aline Membre éclairé Inscription : juin 2004 Messages : 487 Détails du profil Informations forums : Inscription : juin 2004 Messages : 487 Points : 373 Points : 373	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
	00

01/10/2004, 15h19	#6
aline Membre éclairé Inscription : juin 2004 Messages : 487 Détails du profil Informations forums : Inscription : juin 2004 Messages : 487 Points : 373 Points : 373	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....
	00

01/10/2004, 15h24	#7
LeoAnderson Expert Confirmé Inscription : septembre 2004 Messages : 2 942 Détails du profil Informations forums : Inscription : septembre 2004 Messages : 2 942 Points : 2 972 Points : 2 972	pourquoi donc la solution consistant à lister les tables à exporter/importer n'est pas satisfaisante ? :
	00

01/10/2004, 15h39	#9
thomasjcj Membre régulier Inscription : février 2004 Messages : 97 Détails du profil Informations forums : Inscription : février 2004 Messages : 97 Points : 91 Points : 91	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é.
	00

01/10/2004, 15h43	#10
LeoAnderson Expert Confirmé Inscription : septembre 2004 Messages : 2 942 Détails du profil Informations forums : Inscription : septembre 2004 Messages : 2 942 Points : 2 972 Points : 2 972	oui, mais les données ????
	00

01/10/2004, 15h50	#12
LeoAnderson Expert Confirmé Inscription : septembre 2004 Messages : 2 942 Détails du profil Informations forums : Inscription : septembre 2004 Messages : 2 942 Points : 2 972 Points : 2 972	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....
	00

04/10/2004, 11h43	#13
aline Membre éclairé Inscription : juin 2004 Messages : 487 Détails du profil Informations forums : Inscription : juin 2004 Messages : 487 Points : 373 Points : 373	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?
	00

04/10/2004, 12h15	#15
CD Membre habitué Inscription : septembre 2004 Messages : 127 Détails du profil Informations forums : Inscription : septembre 2004 Messages : 127 Points : 138 Points : 138	ou alors, un import avec la clause TABLE=(liste de tables à importer)
	00

04/10/2004, 13h46	#16
aline Membre éclairé Inscription : juin 2004 Messages : 487 Détails du profil Informations forums : Inscription : juin 2004 Messages : 487 Points : 373 Points : 373	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!
	00

04/10/2004, 14h17	#17
CD Membre habitué Inscription : septembre 2004 Messages : 127 Détails du profil Informations forums : Inscription : septembre 2004 Messages : 127 Points : 138 Points : 138	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"
	00

04/10/2004, 14h33	#18
thomasjcj Membre régulier Inscription : février 2004 Messages : 97 Détails du profil Informations forums : Inscription : février 2004 Messages : 97 Points : 91 Points : 91	Sous 10g, les utilitaires imp et exp ont enormement evolue et permette une bien plus grande selectivité des objets. Qu'on se le dise...
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email