Discussion :

[lbgl]

Bonjour,

Je fais un import de type "fromuser=... touser=..." dans un SGBD ORACLE 9i.
Les tables contenant des champs BLOB ne passent pas et renvoient une "erreur ORACLE 959: le tablespace XXXX n'existe pas".

Or:

1. Le tablespace en question provient de la base originale mais aucun tablespace n'est exporté lors de l'export
2. Aucun tablespace n'est importé lors de l'import dans la base destination
3. toutes les autres tables possèdent le même tablespace XXXX d'origine et passent sans problème lors de l'import

quelquun a til déjà eut cela ?
quelqu'un connait il une solution ?

Merci d'avance !

lblg

[lbgl]

Bonjour,

Après recherche sur internet il semble que le problème énoncé soit connu: les tables contenant des BLOB ne seraient pas importées automatiquement dans le tablespace par défaut de l'utilisateur de destination.

Cependant les 2 solutions que j'ai pu trouver ne sont pas très claires pour moi.

Pourriez vous me donner votre avis sur ces solutions ?

• solution 1: créer le tablespace XXXX dans ma base destination et fixer un quota à Zero sur ce TBS pour l'utilisateur destinataire (Rappel: l'imp est un fromuser=... touser=)
• solution 2: faire un import avec l'option ignore=y

Le problème de la solution 1 est que mon utilisateur destinataire a le rôle ressource et donc que ses quota sont illimités.

Le problème de la solution 2: l'argument "imp... ignore=y" va t il vraiment créer les tables qui posent problème dans le TBS par défaut de mon utilisateur destintaire ??

Avez-vous un avis sur ces questions ?

Merci d'avance,
lbgl

[orafrance]

la solution 1 est la seule possible... là 2 te provoquera la même erreur

[lbgl]

Merci de la réponse !

Si la solution1 est la seule réelle solution reste un sous-problème: mon utilisateur destinataire a le rôle RESOURCE (et DBA), aussi comment lui fixer un quota zéro sur un TBS donné ?

(y'a pas mieux que lui retirer les droits en question puis lui remettre ?...)

Merci par avance !

lbgl

[orafrance]

l'utilisateur n'a pas besoin des droits, c'est le userid qui doit avoir les droits sur le tablespace

[lbgl]

Merci de la réponse une fois encore !!
mais je ne la comprends pas vraiment

Mon userid dans la ligne "imp userid=.." a aussi les droits RESOURCE et DBA, comment lui donner un quota zéro sur un TBS ?
(désolé si c'est évident je suis loin d'être DBA...)

merci par avance !

lbgl

[orafrance]

mais pourquoi quota 0 ?

[lbgl]

Hé bien la solution que vous avez conseillée était celle ci (cf. mon premier msg)

solution 1: créer le tablespace XXXX dans ma base destination et fixer un quota à Zero sur ce TBS pour l'utilisateur destinataire (Rappel: l'imp est un fromuser=... touser=)

J'ai vu sur internet que cette manip obligeait en quelque sorte ORACLE a importer des tables avec des champs BLOB dans le TBS par défaut de l'utilisateur destinataire (sinon ces tables cherchent à se créer dans le même TBS qu'à l'origine alors que dans mon cas il n'existe pas dans la base destination)

Donc :
Si cette solution fonctionne (être vous toujours d'accord ?) comment gèrer le quota quand l'utilisateur a un rôle RESOURCE (et DBA accésoirement) ?

Merci beaucoup si vous pouvez m'éclairer !

lbgl

[orafrance]

pourquoi ne pas créer le tablespace à l'identique de celui de la base source... tout simplement

[lbgl]

Merci de la réponse.

L'idée c'est de ne pas "encombrer" la base destinataire d'un TBS supplémentaire ...
Je souhaiterais simplement que l'import (y compris des tables avec BLOB) stoque ce qui doit l'être dans le TBS par défaut de l'utilisateur destinataire.

Y'a t il une solution ?...

Merci par avance !
lblgl

[orafrance]

le plus simple c'est d'importer dans le tablespace créé pour l'import et de déplacer les objets dans le tablespace de ton choix pour finir par dropper le tablespace rendu inutile

[lbgl]

Meric de votre suggestion.

et si je fais ainsi cela marcherait t il ?

1. Je crée un TBS YYYY dans ma base source avec le même nom que celui du destinataire
2. Je change les tables qui posent pb dans la base d'origine et je les met dans YYYY
3. je fais un export
4. je réimporte le tout (les tables qui posent pas pb seront importées dans le TBS par défaut de l'utilisateur destinataire et celles qui posent problème devrait trouver un TBS YYYY donc ça devrait aller non ?)

Merci par vance de votre réponse!

[orafrance]

oui... mais ça revient au même que ce que je suggérais

[lbgl]

oui effectivement cela revient au même dans le principe
La différence est dans le fait qu'il n'y aucune action sur la base de destination, hormis l'import lui-même, ce qui me convient mieux.

Je vais tester cette solution.

Merci beaucoup de votre aide.


lbgl