Export expdp et droits

Bonjour,

J'ai une problématique sur Oracle 11G pour faire un DUMP de ma base.
Je souhaite le faire sur un répertoire réseau via un expdp.

Ce que j'ai fait :
- Comme je ne veux pas utiliser le répertoire datapump par défaut, j'ai créé un directory via la fonction CREATE
- J'ai allouer les droits à mon utilisateur sur ce directory via un GRANT (fait en sysDBA, j'ai vérifier dans all_object, les droits sont bien attribués)
- Je lance ma fonction expdp et j'ai les erreurs suivantes :
ORA-39002:opération non valide
ORA-39070:Ouverture du journal impossible
ORA-29283:Opération non valide sur le fichier
ORA-06512:"SYS.UTL_FILE", ligne 536
ORA-29283:opération non valide sur le fichier

Suite à ça, je vérifie tout (j'ai bien vu que c'était un problème d'accès au directory), tout est OK.
Donc je vais dans les droits Windows du répertoire réseau et je mets tout le monde en contrôle total sur le répertoire où doit arriver le DUMP et je relance l'export.
Là tout se passe bien et j'ai mon DUMP.

Mon problème comme vous l'aurez compris c'est que je ne peux pas accorder les droits à tout le monde sur un chemin réseau où il y a les sauvegardes.
Une précision : les identifications réseau se font via un Active Directory.

Y a t-il une solution pour réaliser cette sauvegarde sans attribuer les droits à tout le monde ?
Information : ce qui est bizarre c'est qu'avec un exp ça fonctionnait correctement et je n'avais pas de problématique de droits.

D'avance merci de vos réponses.

Bonjour,

Tu es sous Windows et c'est parce que les exécutables mis en jeu ne sont pas lancés par le même compte Windows que tu as ce pb.

Je m'explique.

Côté client, que tu fasses un export classique via exp.exe ou un export Datapump via expdp.exe, ces 2 utilitaires s'exécutent avec les droits de ta session Windows (je suppose par exemple que tu es connecté sous AD\USER, USER étant ton compte Windows et AD ton domaine).

Pour l'export classique, c'est bien exp.exe qui génère lui-même le fichier Dump, et si ça marche, c'est parce que sous AD\USER, tu as les droits d'écrire sur le répertoire réseau.



Par contre, pour expdp.exe, ce n'est pas cet exécutable qui génère le fichier Dump, mais la base de données Oracle au travers de l'un de ses très nombreux Background Process (c'est même le process d'arrière plan DWnn qui génère le fichier Dump).

Sous Windows, une base Oracle est démarrée via un service Windows qui lance l'exécutable ORACLE.EXE avec en paramètre le SID de la base.
Pour le compte d'exécution, c'est celui du service Windows, qui est par défaut le compte système local (NT AUTHORITY \ SYSTEM).

ORACLE.EXE est un exécutable multi-threadé, chaque thread représentant un des Background Process.

Et avec le compte système local, le thread DWnn n'a pas le droit d'écrire sur ton répertoire local. C'est cela l'origine de ton problème.

Tu t'en es sorti par un moyen pas propre : mettre tout le monde en contrôle total sur le répertoire réseau, et du coup le thread DWnn qui tourne avec les droits de NT AUTHORITY \ SYSTEM arrive alors à générer le Dump.



La façon propre de faire, c'est de te créer un compte de service dans l'Active Directory, par exemple AD\ORA11

Ce compte devra :
- avoir le droit d'écrire sur le répertoire réseau
- être défini dans le groupe local ora_dba
- je ne suis pas sur, mais je crois qu'il droit être aussi dans le groupe local des Administrateurs

Et il ne te reste plus qu'à démarrer ton service Windows avec ce compte.

Attention aussi : pour le bon fonctionnement d'Oracle, il ne faut pas que ce compte de l'AD se verrouille ou que quelqu'un change son mot de passe, sinon le service Windows ne redémarrera pas.

Bonjour,

Merci pour toutes ces explications rouardg, claires et précises.
Il y a juste une chose que j'ai oublié de préciser : je lance le programme .bat en administrateur de mon domaine (donc tous les droits). Par contre cet l'utilisateur n'est pas déclaré dans Oracle (contrairement à l'utilisateur qui est utilisé pour lancer la commande expdp).

Par rapport à ce que tu m'as indiqué rouardg, j'ai vérifié et l'administrateur du domaine fait bien parti du groupe local ora_dba et du groupe administrateur local.

Est-ce qu'il faut que l'utilisateur qui lance le .bat soit le même que celui déclaré pour lancer la commande expdp ?

Bonjour,

En fait, ce qu'il faut bien comprendre, c'est que Datapump ne fonctionne pas du tout comme l'ancien utilitaire d'export / import.

L'ancien utilitaire exp.exe, qui est donc le client, se connecte à la base Oracle. mais c'est bien lui qui récupère les structures de table et les données, et qui écrit tout cela en binaire dans le fichier Dump.

Le nouvel utilitaire Datapump expdp.exe fonctionne autrement. C'est aussi un client qui se connecte à la base Oracle, mais ce n'est pas lui qui récupère les structures de table et les données, et qui écrit tout cela en binaire dans le fichier Dump. C'est la base de données qui fait ce boulot.

Moralité : côté client, pour Datapump, que tu utilises un compte AD\USER ou le compte administrateur du domaine, que tu lances expdp.exe en direct ou via un .bat, cela ne change rien. Car les droits liés au compte utilisé ne s'appliquent qu'à expdp.exe, mais pas à oracle.exe



L'exécutable ORACLE.EXE qui génère le Dump est lancé par un service Windows, par défaut sous le compte système local (NT AUTHORITY \ SYSTEM).

C'est là où tu pourrais aller dans les propriétés du service, pour que le service se connecte avec le compte administrateur du domaine. Mais ne fais surtout pas cela, car ce compte est trop privilégié !

C'est juste pour que tu comprennes qu'il faut agir au niveau du service Windows et de l'Oracle.exe, et non pas au niveau du client expdp.exe comme tu le crois.

Est-ce plus clair ou pas ?


Après je me demande si il n'y a pas un autre moyen de résoudre cela autrement. Mais là je ne vois pas.