export/import j'y arrive pas

Version imprimable

25/05/2007, 18h47
lecharcutierdelinux

export/import j'y arrive pas

Bonjour à tous,
j'arrive pas à faire fonctionner l'export/import entre mes 2 bases. Voici la situation.

-La base DEV de production est rempli par un utilisateur "sapr3", composé de 24.000 tables, vues ....

-La base DEV cobaille que je veux utiliser pour test doit récuppérer les données de celle de prod. Elle a elle aussi un utilisateur sapr3 avec un schéma mais moins à jours.

J'ai donc fait un "drop user sapr3 cascade" pour tout effacer le schema de sapr3 de la base test avant l'import. j'ai ensuite recréer l'utilisateur et importer les 24.000 tables mais y'a pas les vues!! (j'avait fait un export de sapr3). Après vérif, j'ai vu que l'export en mode user ne prennait pas les vues (c'est nul?!?).

Je me lance donc dans un export de la database complète sauf que je me pose qqes questions. Que se passe t'il si les tablespace et datafile existent déja sur la base de destination? Dois-je dropper les tablespaces? en effet je drop l'user sapr3 en vidant son schéma mais je ne pense pas que ça ne supprime pas les tablespaces... Enfin, que se passe t'il pour les tablespaces systeme genre "system"... Il existe aussi dansles deux bases et sauf erreur de ma part ils contienent le nom des tablespaces etc....

C'est super abstrait l'import/export, la doc de oracle est beaucoup trop complexe car elle n'explique pas de manière précise les cas où les datafiles existent déja... Ne serait-ce que pour une table, si elle existe déja comment ça se passe?

Pas mal de question parceque faut pas que je me loupe encore.. Sorry et merci d'avance
25/05/2007, 21h09
pifor

Citation:

Que se passe t'il si les tablespace et datafile existent déja sur la base de destination?

Citation:

A full import creates any undefined tablespaces using the same datafile names as the exported database.

Citation:

Dois-je dropper les tablespaces?

Probablement non, sauf si vous voulez et pouvez avoir exactement les mêmes noms absolus de datafiles pour la base source et la base cible.

Citation:

Enfin, que se passe t'il pour les tablespaces systeme genre "system"

Le tablespace system n'est pas recrée. Pour le contenu: les objets appartenant à SYS et les privilèges sur les objets appartenant à SYS ne sont par exportés (mais SYSTEM oui).

Citation:

Ne serait-ce que pour une table, si elle existe déja comment ça se passe?

Citation:

When tables are manually created before data is imported, the CREATE TABLE statement in the export dump file will fail because the table already exists. To avoid this failure and continue loading data into the table, set the import parameter IGNORE=y. Otherwise, no data will be loaded into the table because of the table creation error.

Pour tester rapidement l'export/import, vous pouvez créer 2 petites bases qui représentent la base source et la base cible. Pour la base source: créez les même tablespaces, les même nom de schémas, les mêmes droits des utilisateurs à exporter et créer dans chaque schéma 1 objet représentant chaque type d'objet utilisé dans chaque schéma et inserez quelque lignes dans chaque table. Créez la base cible avec ce que vous voulez et tester l'export/import que vous voulez réaliser: comme le nombre d'objets et le volume de données sera minimal vous aurez le résultat très rapidement.

Ceci dit, s'il s'agit de copier rapidement une base de production à priori volumineuse dans une base de test, vous pouvez éviter les problèmes de suppression et création d'objet en utilisant:
- les tablespaces transportables
- la copie physique de la base à partir du backup (très utile pour tester le backup)
- la duplication par RMAN si vous utilisez RMAN pour faire les sauvegardes

PS: n'oubliez pas de préciser quelle version d'Oracle vous utilisez.
31/05/2007, 17h25
lecharcutierdelinux

Merci pour ces réponses mais je plante toujours.

En effet j'ai fait un export database d'une base sous Unix pour windows.

Lorsque je l'importe dans Windows, il plante au niveau des "create tablespace" puisqu'il fait des "create datafile" avec des "/" (slash).

Or, malheureusement sous windows c'est des anti-slashs donc ça plante dès le début.

j'ai essayé d'ouvrir le fichier dumpé mais c'est du binaire, peux pas modifier les chemin des fichiers pour les adapter à windows.

Qqun a déja eu ce problème?

merci
31/05/2007, 18h33
dyvim

Je pense que tu as tout interêt à ce que TOUS tes tablespace soient déjà définis sous ta base windows...
Ainsi lors de ton import ils ne devraient pas être recréés (car pas besoin) et donc tu n'auras pas d'erreur avec ton "/".
En théorie l'import ne recrée pas les tablespaces s'ils existent (quoi qu'il y ait peut être une option pour)
31/05/2007, 19h08
louping

Citation:

Envoyé par lecharcutierdelinux

J'ai donc fait un "drop user sapr3 cascade" pour tout effacer le schema de sapr3 de la base test avant l'import. j'ai ensuite recréer l'utilisateur et importer les 24.000 tables mais y'a pas les vues!! (j'avait fait un export de sapr3). Après vérif, j'ai vu que l'export en mode user ne prennait pas les vues (c'est nul?!?).

Faire un export full (sans constraints=n ;-) )
$ exp system/passwd file=full_exp.dmp log=fulll_exp.log full=y compress=y buffer=10000000

Recréer le compte en laissant les tablespaces
SQL> drop user sapr3 cascade ;
SQL> create user sapr3 ; quota ; role ; resource ; grant etc....

Faire l'import
$ imp system/passwd file=full_exp.dmp log=sapr3_imp.log fromuser=sapr3 touser=sapr3 commit=y ignore=y buffer=10000000
Normalement, tu dois avoir aucune erreurs sauf s'il y a des trucs public (synonyms, dblink). Là faudra recommencer le drop, create puis creation des trucs public...

A+
31/05/2007, 19h53
lecharcutierdelinux

Merci à vous deux, cependant:

>Louping
Si je fais un export/import full database comme tu me le conseille, je n'ai pas besoin de re-créé l'user sapr3 puisque l'import le re-créera? J'aurais les vues avec l'option full?

>Dyvim
Faut-il que j'utilise l'option ignore=Y pour pas qu'il bloque sur la création des Tablespace déja existant?

Dire que Oracle vend l'export/import comme simple.
31/05/2007, 21h33
louping

Citation:

Envoyé par lecharcutierdelinux

Merci à vous deux, cependant:

>Louping
Si je fais un export/import full database comme tu me le conseille, je n'ai pas besoin de re-créé l'user sapr3 puisque l'import le re-créera? J'aurais les vues avec l'option full?

>Dyvim
Faut-il que j'utilise l'option ignore=Y pour pas qu'il bloque sur la création des Tablespace déja existant?

Dire que Oracle vend l'export/import comme simple.

C'est un export full et un import user que je t'ai décris donc il faut que les TS et le compte existent.... Tu auras les vues car tu avais dû faire ton export avec CONSTRAINTS=N et de mémoire cela contient les index, les contraintes mais aussi les vues...
A+