Problème avec Datapump (oracle 10g)

Bonjour.
Je suis en Oracle 10.2.0.1.0 (sur Windows XP et aussi sur RedHat).
J'ai 2 questions sur Datapump.

Tout d'abord, je n'arrive pas à trouver la commande pour voir à quel répertoire est affecté le directory datapump. Pour créer le répertoire, ok, c'est "create directory datapump as 'xxx'", mais si on a oublié ce que l'on a mis comme répertoire et que l'on veut savoir à quel répertoire physique on a fait correspondre le répertoire logique datapump, comment on fait?

Ensuite, j'essaye d'importer une table à partir d'un fichier d'export (fait avec datapump et même version). Je n'arrive pas à trouver pourquoi ça ne marche pas.
J'arrive à faire des export et import sans problème sur Windows XP, mais sur RedHat ça ne marche pas (la différence c'est que sous Windows c'est moi qui ai installé la base, sur Linux non).
Ma commande est la suivante:

Code:

---

impdp user/mdp directory=datapump dumpfile=monexport.dmp tables=matable

---

Le résultat est le suivant:

Code:

---

1 2 3 4 5 6 7 8

ORA-31626 : la tâche n'existe pas ORA-31637 : impossible de créer la tâche SYS_IMPORT_TABLE_01 pour l'utilisateur user ORA-06512 : à "SYS.DBMS_SYS_ERROR", ligne 95 ORA-06512 : à "SYS.KUPV$FT_INT", ligne 600 ORA-39080 : echec de création des files d'attente "" et "" pour la tâche data pump ORA-06512 : à "SYS.DBMS_SYS_ERROR", ligne 95 ORA-06512 : à "SYS.KUPC$QUE_INT", ligne 1555 ORA-01403: aucune donnée trouvée

---

Quand j'essaye un import sans préciser la table, même style d'erreur.
Quand je fais un export (full ou d'une table) pareil.

Merci d'avance si vous avez une idée.

Pour voir la définition de ton driectory :

select * from dba_directories;

Plus exactement dans ton cas :

select * from dba_directories
where directory_name='DATAPUMP'
/

Merci pour ta réponse.
Ca m'a permis de voir que le répertoire datapump pointait sur un répertoire physique inexistant.

Par contre, même en créant ce répertoire, j'ai toujours les mêmes erreurs.
Mon user a bien les droits exp_full_database, imp_full_database. Il a bien les droits de lecture et d'écriture dans le répertoire datapump.
J'ai repassé le script ORACLE_HOME/rdbms/admin/catqueue.sql (réponse vu sur un forum ou une personne avait à peu près les mêmes erreurs que moi).
Rien n'y fait.

est-ce que ton fichier monexport.dmp existe bien ?
Parce que si le répertoire n'existait pas, le fichier non plus, j'imagine...
Donc il te faut le mettre dans le directory.

Oui il existe. Il était dans un autre répertoire (celui que je croyais être le "datapump"). Maintenant bien sur je l'ai copié dans le bon répertoire.
Mais je savais que ce n'était pas ça le problème vu que j'ai le même style d'erreur quand j'essaye de faire un export avec la commande suivante:

Code:

---

expdp user/mdp directory=datapump dumpfile=monexport2.dmp full=yes

---

A la différence près bien sur que la 2ème erreur porte sur la tâche SYS_EXPORT_FULL_01 à la place de SYS_IMPORT_TABLE_01.
Je pense que c'est un problème de config pour utiliser le datapump, mais je n'arrive pas à trouver lequel.

Ne pas oublier le grant read,write on directory DATAPUMP to ton_utilisateur;
A faire en tant que SYS.
Sinon créé une nouvelle directory (en SYS) a laquelle du donnes les droits R,W.

Est-ce qu'un compte DBA peux utiliser datapump ?
Si c'est le cas, la solution doit être :
Grant select on ALL_USERS to PUBLIC;

Voir note 438236.1 : Expdp Fails With ORA-31637 ORA-00942
Il doit manqué un privilège.
select * from dba_tab_privs where table_name='ALL_USERS';
=> pas bon si 0 ligne.

existe-t-il sur la base des objets nommés SYSTEM appartenant à un autre propriétaire que SYSTEM? c'est un mot réservé qui peut invalider des objets d'advanced queuing et aussi certains composants de la table de queue SYS.KUPC$DATAPUMP_QUETAB qu'utilise datapump.

Avec le compte SYSTEM, ça ne marche pas non plus (même erreur).
Les privilèges sont bons dans dba_tab_privs: j'ai une ligne, et surtout la même chose sur ma machine Windows (ou ça marche) et sur ma machine Linux.
Sinon aucun objet avec le mot clé SYSTEM (j'ai vérifié dans all_objects).

Je viens de voir que j'ai plus de 500 objets invalid dans la table all_objects. Donc c'est mon instance de base de données qui est mal créée.
Surtout que sur une autre instance sur la même machine, ça marche (et là aucun objet invalide).
Donc je reconstruis ma base et ça devrait mieux marcher.
Merci à tous.

Je viens de recréer mon instance de base de données.
Je n'ai plus d'objets invalides dans all_objects, et ça marche.
Je ne sais pas d'où venait le problème, surtout que j'ai utilisé les mêmes scripts pour construire mon instance. Mais l'important c'est que ça marche.