10g : pb import datapump et tablespaces

Bonjour.
J'ai une base Oracle en version 10.2.0.1.0.
je dois faire des transferts réguliers de données d'une machine à une autre (les 2 machines ont la même version d'Oracle).
Dans ma base, j'ai des tablespaces "dynamiques", c'est-à-dire au fur et à mesure de l'alimentation de ma base, je créé des tablespaces spécifiques à certaines données (tout ça pour dire que je ne connais pas d'avance la liste de mes tablespaces).
Mon problème est le suivant:
Quand j'importe mes données sur ma 2ème machine (j'importe à chaque fois que le delta des nouvelles données, delta pouvant contenir plusieurs tablespaces), les tablespaces n'existent pas forcément sur ma machine cible. Du coup la commande d'import (avec le datapump) échoue dans le cas ou le tablespace n'existe pas.
Existe-t-il un moyen de faire un import en créant les tablespaces, les tables et les lignes des tables?
Et dans un 1er temps, comment fait-on pour importer des tables (avec les lignes) même dans un autre tablespace quand celui-ci n'existe pas sur la machine cible? Avec l'export classique, pas de soucis, mais avec le datapump je n'arrive pas à le faire.
Merci d'avance

Citation:

---

Envoyé par Bonnie38

Dans ma base, j'ai des tablespaces "dynamiques", c'est-à-dire au fur et à mesure de l'alimentation de ma base, je créé des tablespaces spécifiques à certaines données

---

Quelle drole d'idée... on peut savoir pourquoi tu fais ça ? :koi:

Sinon, bah avant de lancer l'import tu compares DBA_DATA_FILES des 2 bases pour voir si tu as un nouveau tablespace à créer

Merci pour la rapidité.

Pour les tablespaces "dynamiques", j'ai repris un projet déjà fait comme ça.
En gros, sur la machine source, il y a une base dite "en ligne" recevant pleins de données, qui alimente une base dite "d'archivage", découpée en archives de x jours. Et toutes les tables de détails appartenant à une archive sont dans un tablespace dont le nom comporte le numéro de l'archive. Comme ça quand on veut sauvegarder une archive (ou la transférer sur l'autre machine) on sauvegarde toutes les tables du tablespace ts_arch-<num_archive>.

Sinon pas possible de faire comme tu dis. La 2ème machine n'a aucun moyen de voir la 1ère. Et la 1ère je crois qu'elle peut juste transférer des fichiers à la 2ème (enfin c'est ce qu'on m'a dit car les réseaux et moi ça fait 4!!).

Il devrait quand même y avoir la possibilité de créer les tables dans le tablespace par défaut quand le tablespace d'origine n'existe pas, comme c'est le cas pour l'import standard. Mais avec le datapump, je n'y arrive pas.

bah tu peux améliorer le truc en utilisant les tables partitionnées déjà ;)

Citation:

---

Et la 1ère je crois qu'elle peut juste transférer des fichiers à la 2ème

---

bah qu'elle envoie le script de création des tablespaces ;)

Le code en amont est déjà fait et tourne depuis un moment. Donc je ne peux pas changer. C'est seulement la 2ème machine qui est nouvelle.
Donc problème non résolu.
Je fais des tests avec le paramètre REMAP_TABLESPACE. Quand je connais le nom du tablespace d'origine, ça marche. Je fais:
impdp .... remap_tablespace=tbs1:tbs2
Sauf que là je ne connais pas d'avance le nom de tbs1.
Peut-on mettre un caractère spécifique (style % ou *) pour dire que tous les tablespaces seront changés en tbs2? Pour l'instant je trouve rien.

bien sûr que non, tu dois donner les noms en dur... mais l'idée du script envoyé par la machine ça ne te plait pas ?

Je trouve ça quand même bizarre qu'il soit impossible de récupérer des données d'un fichier d'export sans connaitre le nom des tablespaces.
Ca veut dire que pour la sauvegarde de ma machine, il faut que je fasse un export de ma base PLUS un fichier avec la liste des tablespaces de la base, sinon en cas de perte du disque il sera impossible de récupérer les données.
Ca fait une regression par rapport à l'import/export classique.
Je continue à chercher une solution. Si je la trouve tant mieux (je mettrais la solution sur le forum bien sur), sinon ben je ferais comme tu dis, un fichier d'export ET un fichier annexe avec liste des tablespaces (ou script de création des tablespaces).

il n'y a rien de bizarre, export permet de copier les DONNEES, il prendrait aussi les tablespaces tu ferais pas un export de données mais de tablespace via les tablespaces transportables.

Justement je demande à récupérer seulement les données et qu'il me les mette dans le tablespace qui l'arrange lors de l'import, alors que là il garde en mémoire le tablespace et il ne veut pas les mettre ailleurs que dans ce tablespace.
Ce qui m'étonne surtout c'est la régression par rapport à l'ancien import/export. Enfin en tout cas dans ce cas précis, parce que sinon c'est vrai qu'on arrive à faire beaucoup plus de choses avec le datapump. Mais forcément moi je tombe dans un cas qui n'a pas été prévu. C'est la loi!
Donc je cherche encore des pistes (je suis tétue!), et sinon je me résignerais.
Merci quand même pour tes réponses.

Citation:

---

Envoyé par Bonnie38

Ce qui m'étonne surtout c'est la régression par rapport à l'ancien import/export.

---

il n'y a pas de régression :koi:

Ce que j'appelle régression c'est qu'en export/import classique je pouvais faire ce que je voulais, c'est-à-dire:
export de mes tables par:

Code:

---

exp user/mdp@sid file=C:\exp.dmp tables=test1,test2

---

Mes 2 tables test1 et test2 étant par exemple dans les tablespaces TBS1 et TBS2.
Lors de l'import sur l'autre machine, mes tablespaces TBS1 et TBS2 n'existent pas. Mais en utilisant la commande:

Code:

---

imp user/mdp@sid file=C:\exp.dmp full=y ignore=y

---

mes données sont quand même importées, dans le tablespace par défault de l'utilisateur user.
Donc là j'ai réussi à récupérer mes données sans connaitre l'existence de TBS1 et TBS2 et uniquement à partir de mon fichier d'export oracle.

Par contre avec le datapump je peux pas. Il me faut un 2ème fichier avec la liste des tablespaces à créer avant de faire l'import.

A la main encore je pourrais me débrouiller en faisant d'abord un import datapump avec le paramètre SQLFILE pour avoir le script de création de mes tables, et récupérer le nom des tablespaces dans ce script, mais par programmation il va me falloir une petite usine à gaz pour extraire le nom des tablespaces dans ce script pour créer mes tablespaces.

bah et REMAP_TABLESPACE ?

Le problème reste quand même, il faudra extraire le nom des tablespaces dans le script.
Pour l'instant la solution qu'on peut envisager c'est de faire un fichier d'export par tablespace, avec un fichier dump nom le nom serait celui du tablespace. Comme ça je pourrais créer mon tablespace avant de lancer la commande d'import.
Par contre au niveau performance je ne sais pas si faire x export pour x tablespaces ça prendra beaucoup plus de temps que de faire un seul export pour les x tablespaces.

Citation:

---

Envoyé par Bonnie38

Le problème reste quand même, il faudra extraire le nom des tablespaces dans le script.

---

bah oui mais tu retrouves le fonctionnement de l'import "classique" ;)

En devant extraire le nom des tablespaces dans le script, je retrouve le comportement de l'export/import "classique" en écrivant une procédure d'une 50aine de ligne environ au lieu d'une ligne de commande avant!

Bon, sinon je conclus que ce n'est pas possible avec datapump d'importer des données quand les tablespaces d'origine ne sont pas créés et que l'on n'en connait pas la liste.

Pour mon problème, j'ai trouvé une solution qui me permet de ne transférer qu'un fichier d'export entre mes 2 machines:
sur la 1ère machine, je créé une table LISTE_TBS dans un tablespace bien défini au départ (qui sera créé sur les 2 machines à l'installation de l'appli). Dès que l'application crée un nouveau tablespace, elle insère une ligne dans cette table.
J'ajoute cette table à mon export.
Sur la 2ème machine, je fais d'abord un import uniquement de cette table.
Selon les données de cette table je crée mes tablespaces.
Puis je lance l'import des autres tables.
Cette solution me plait mieux que de lire un fichier texte envoyé en parallèle de mon fichier export.

Encore merci du temps passé sur ce problème.