Discussion :

[xavierDebecq]

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

[Heaven93]

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.

[xavierDebecq]

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.

[xavierDebecq]

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.

[xavierDebecq]

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.

[Heaven93]

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)

[Pomalaix]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Heaven93]

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?

[Pomalaix]

... 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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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à.