import export sous oracle 8i

Bonjour,

Je suis débutant sous Oracle 8i et je dois recréer une base de données pour un environnement de test. Je n'ai pas les droits pour faire moi même l'export et je reçois le dump d'une collègue. J'ai réussi a importer son dump sans fautes avec un import full et un import partiel (fromuser touser) malheureusement il manque tout ou une partie des tables dans les schemas des utilisateurs, ce qui fait que rien ne vas plus quand on utilise les applis sur la nouvelle base. Je pense donc que meme si je récupère toute les tables, je dois soit avoir un problème dans la manipulation que je fais, soit avoir un problème avec le dump. Pour plus de clarté voici ce que je fais exactement et ce que j'ai constaté comme effets :

• Je crée une instance de base vierge.
• Je crée un user temporaire avec tout les droits que je peux lui donner
• je réalise l'import du dump avec imp system/manager@prdsiswi file=prdsisui.dmp log=imp_prdsisui.log buffer=10000000 ignore=y commit=y full=y
• Après le succès de l'import, mon compte SYSTEM n'est plus utilisable, je le récupère a l'aide de mon user temporaire

Après cette procédure, je me retrouve avec une base complète parce que les tables ont bien importées.
Il y a une table d'index qui a un problème de clé unique. Ces records ne sont apparemment pas importés.

Donc ma question est la suivante : quelle ligne de commande je dois demander de passer a ma collègue si je veux être certain que quelque soit sa structure et ses objets, TOUT soit exporté ?
Et est ce que ma ligne d'import doit préciser quelque chose pour que les objets de tout les types soient importés ?

Merci a ceux qui me liront

sans doute à cause du ignore=y. Oracle va sauter les tables qui existent déjà, d'où le fait qu'il manque des choses dedans.
Si tu as importé le dump avec succès et qu'il ne te manque rien sur une base vierge, c'est que le problème n'est pas du côté de l'export mais du côté de l'import.
Si tu veux remplacer toutes les données du schéma, pourquoi ne pas le dropper (option CASCADE, mais au préalable sauver tout ce qui est nécessaire à sa reconstruction dans un fichier), le recréer à l'identique et importer fromuser touser? Sinon (moins propre), dropper toutes les tables du schema avant l'import.

Par importer avec succès, j'entends que la commande se termine normallement et sans message d'erreur.
Je rappelle que je part d'une base qui était vierge au départ et que j'ai créé des tablespaces avec le meme nom que dans la base d'orgine. Si je ne fait pas cela j'ai des messages d'erreur.
Une fois que l'import s'est déroulé sans me faire de message d'erreur, je suis quand même incapable de lui reconnecter des users, vu qu'ils n'ont plus la propriété sur l'entièreté des tables qu'ils avaient.
Je vais essayer ton idée pour le ignore = y et le reste.

Citation:

---

Envoyé par xavierDebecq

... Il y a une table d'index qui a un problème de clé unique. Ces records ne sont apparemment pas importés.

---

Bonjour
Pouvez-vous être plus précis sur ce point ?
Qu'entendez-vous par une table d'index ?
Quel est ce problème de clé unique ? Quel est le message d'erreur ?

Les paramètres importants pour l'intégrité de l'export sont

Code:

---

1 2	FULL=YES CONSISTENT=YES

---

Concernant l'import, je rappelle le vrai sens de IGNORE :
IGNORE=YES : "ne pas réagir si une table existe déjà, et importer les données à la suite de l'existant"
IGNORE=NO : "si la table existe déjà, ne rien importer et passer à la suivante"

IGNORE=YES n'a de réel intérêt que si vos tables cibles existent déjà.

Je viens de faire un essai avec ignore = y et je récupère une base absolument inutilisable parce que j'ai perdu l'accès a mon compte SYSTEM (ce malgré un orapwd avant l import)... et aussi les autres comptes user.

j'ai quelques interrogations :
tu as fait un import full et un import fromuser touser à la suite? (cf ton premier post). quel est l'intérêt? quand tu crées une base tu as déjà sys et system dans celle-ci.
pourquoi un user temporaire? ce qui est important c'est de créer des users à l'identique de la base source (des privileges, des quotas) et dans ce cas, il n'y aura aucun problème.
je ne comprends pas lorsque tu écris "je suis incapable de lui reconnecter des users". il manque des grants entre schémas?

Pour Pommalaix,

En ce qui concerne le message c'est le message ORA 01. probleme de contrainte d'integrité.
Je dis que c'est un index parceque la table a IDX dans son nom.

En ce qui concerne l'export maintenant, tout mon problème est que je n'ai pas les droits pour faire l'export et que aussi triste que ca puisse paraitre, je n'ai jamais vu les paramètres passé a la commande EXP. Je les ai demandé a ma collègue et elle n'a pas pu me les donner, elle m'a répondu que c'était un export full.
Je vais lui expédier un email en lui redemandant la ligne de commande et en lui précisant les paramètres utiles. J'avais déja exploré la documentation sur FULL et CONSISTENT mais j'aimerais pouvoir lui donner une commande EXP avec les bonnes options qu'elle n'aie plus qu'a passer dans un interpréteur et être sur d'avoir un dump cohérent et utilisable pour recréer mon environnement de développement.
Elle me fait faire une procédure qui a mon sens doit servir a rafraichir une base de test déja existante.

duplication par restauration, ce serait peut-être pas mal... sinon, pour la commande d'export, full=y, consistent=y (en effet, si jamais il y a des mises à jour de tables pendant l'export), le reste est déjà par défaut sans qu'on n'ait à préciser (constraints=y, rows=y, etc).
on s'est mal compris, je ne conseillais pas l'import avec ignore=y (tout à fait dans le sens de Pomalaix), au contraire. si les tables existent déjà, il y a un risque de doublons.
une base de test déjà existante???? ça veut dire qu'elle n'est pas vide ?
il vaut mieux partir d'un schéma vide si j'ai bien compris ta problématique (pas sûr)

Citation:

---

Envoyé par xavierDebecq

En ce qui concerne le message c'est le message ORA 01. probleme de contrainte d'integrité.
Je dis que c'est un index parceque la table a IDX dans son nom.

---

Si vous nous donnez des informations tronquées et approximatives, on perd notre temps. Un tel message d'erreur n'existe pas !

Je mets les paramètres sur des lignes séparées pour la lisibilité :

Pour l'export

Code:

---

1 2 3 4 5 6 7

exp system/mdp1@base_source buffer=1000000 full=yes file=... log=... consistent=yes compress=no

---

Pour l'import dans une base vide

Code:

---

1 2 3 4 5

imp system/mdp2@base_cible buffer=1000000 full=yes file=... log=...

---

Si vous faites un import FULL, tout est là, vous n'avez pas besoin de bricoler en plus avec FROMUSER / TOUSER.

A l'issue de l'import FULL, tous les comptes (y compris SYS et SYSTEM) se retrouvent avec le mot de passe qu'ils avaient dans la base source.

Pour Heaven93,

La situation est la suivante : avant que j'arrive, il y avait un serveur de test qui permettait d'importer et de rafraichir des données. Ce serveur a été détruit.
Il faudrait donc que a partir d'une base vierge je puisse restituer le même environnement. Le problème c'est que la procédure que j'ai sous la main, même si elle permet de rafraichir des données dans une base de test, ne permet pas de recréer une base de données from scratch.
D'ou ma question : a partir d'un dump dont on ne connais pas les conditions d'extractions (a part le fait qu'il soit full), existe t il une quelconque solution
pour le restaurer ?

Pour Pommalaix,

Je sais déjà cela, j'ai lu les options et la doc d'oracle qui est d'ailleurs très bien fichue. Le problème c'est que je ne peux pas le faire moi même. Et quand j'ai demandé a ma superviseuse de passer cette ligne de commande, elle a pas voulu. Ni me donner le mot de passe system (c'est pas si indispensable vu que je peux contourner le problème en creant un TEMPUSER dba)
Pour couronner le tout, je suis débutant sur oracle donc je ne sais pas ce qui est possible et normal ou pas.
Mais je garde le moral et je continue de creuser.
Apparemment il n y a pas d'utilitaires de rétro ingénierie pour les dumps.

si on te demande de faire des choses sans te donner les droits nécessaires, évidemment, c'est compliqué. la seule solution comme le disait Pomalaix, c'est bien évidemment l'import full. ou bien que la personne qui a fait l'export se débrouille pour l'import. et pour savoir ce qui s'est passé pendant l'export, la log de l'export te donnera des indications. tu pourrais la faire rapatrier en même temps que le dump. d'ailleurs, il n'y a rien d'extraordinaire à y découvrir (la ligne de commandes passée, les tables exportées et d'éventuelles erreurs lors de l'export...). Je reste convaincue que tu ne devrais pas te focaliser sur l'export mais bien sur l'import.

Je suis d'accord avec toi,
dans le log je ne trouve pas la fameuse ligne de commande.
je vois les tables qui ont été exportées et que je ne retrouve pas dans le log la fameuse ligne de commande qui pourrait m'aider.
Se focaliser sur l'import c'est déja ce que je fais mais le problème c'est que je ne peux pas travailler de manière méthodique. Ma superviseuse m'a donné une ligne de commande, j'ai fait ce qu'elle m'a dit de faire et ca a foiré. Je suis persuadé qu'il manquait quelque chose puisque j'ai du créer les tablespaces a la main pour que l'import ne plante pas dès le début. je vais tenter un import en précisant le nom de toute les tables mais je suis sur que c'est pas la bonne manière... Il y a forcément une voie normale d'y arriver. Je suis persuadé que j y arriverais très bien si je pouvais faire l'export et l'import moi même.

stp poste la log d'export et la log d'import.
je ne comprends pas que tu aies eu à recréer des tablespaces car l'import construit les objets dans le default tablespace du owner (il doit avoir un quota dessus bien évidemment). aurais-tu des objets partitionnés dans de multiples tablespaces?

Bonjour,

Le problème est apparament résolu. J'ai repéré une erreur ORA 1658 dans le log d'import : impossible de créer l'extent suivant. J'ai fait varier la taille des extents a la création des tablespaces.
Il va de soi que ca n'est pas du tout optimal de faire des tablespaces a l'arrache. Je ne sais pas dire quelles conséquences cela peut avoir sur la stabilité et les performances d'une base (surement rien de bon).
Pour répondre a ta question, j'avais deux tablespace. Je vois vraiment pas a qui je pourrais poser la question quant a la répartition des objets sur les tablespaces. Il me faudrait un outil de rétro ingéniérie pour savoir cela si il en existe un qui le fasse.
Je viens de débarquer et je découvre des trucs tout les jours. J'avais jamais touché oracle avant maintenant et j'ai bouffé une bonne partie de la doc tout seul.
Mais c'est certainement très utile de pouvoir savoir ce qui est possible et ce qui ne l'est pas en face d'un énorme produit comme Oracle.
Merci pour votre aide qui me fut précieuse en éliminant des cause possible de problèmes (et aussi a pas sombrer dans la dépression).
Je vais tester la base dans tout les sens et si apparemment j'ai bien résolu le problème, je fermerais la discussion.