Version imprimable
Bonjour à tous,
j' ai importé une base de oracle 9i vers oracle 10g XE le gros problème c'est le champ blob quelqu'un aurait il deja rencontrer ce genre de probleme et aurait donc une manière de le resoudre?
En fait j'aimerai savoir comment importer ma base sans perdre les donnés du champ blob.
Je vous remercie par avance.
Quel est le type exact des colonnes LOB ? CLOB ou BLOB ?
Avez-vous utilisé les outils exp et imp ? Avec quelles options ?
Quel est le problème exact rencontré ? Quels sont les messages d'erreur complets (avec ORA-XXXX) ?
Quels sont les jeux de caractères des bases concernées ?
Normalement les outils exp/imp sont capables de traiter des colonnes de type CLOB ou BLOB.
Je m'excuse de repondre si tard, c'est que j'ai eu des imprévus.Citation:
Envoyé par pifor
Mais mon problème n'est pas résolu et je continue a chercher une solution.
Donc pour bien expliquer quelqu'un a fait un export d'une base oracle 9i, (en l'occurence mon tuteur de stage) j'ai donc récupérer le fichier .dump que je dois importer sous oracle 10 g XE.
J'ai essayé l'import avec la commande imp (sous dos) qui n'a malheureusement pas aboutit.
Puis j'ai décidé de prendre les scripts de les executer sous oracle 10g; je cree donc des tables puis avec la commande import et l'option 'tables= ' je selectionne les tables importer.
J'utilise ausi l'option "rows=y" (pour les données) et "ignore=y"
Ceci a marcher pour plusieurs tables et donc je l'ai fait pour la table contenant un champ blob (et non pas clob ou lob ;) ) seulement rien ne se passe il y a écrit sous dos : import de la table "bidule" (qui contient le blob) mais elle reste bloquée sans aucun message d'erreur .
Sinon pour le jeu de carcactères : je vous fourni une partie du log
import effectué dans le jeu de caractères WE8MSWIN1252 et le jeu NCHAR AL16UTF16
le serveur d'import utilise le jeu de caractères AL32UTF8 (conversion possible)
Voila j'espère avoir été plus clair, n'hésitez surtout pas à me demander plus de détails je vous remercie par avance de m'aider :P
Quelle est la taille en nombres de lignes de la table à importer ?
Il est normal que l'import n'affiche rien pour un table donnée jusqu'à ce que la table soit complètement importée: si la table est volumineuse, l'import peut rester muet pendant un certain temps sauf si on utilise l'option FEEDBACK:
Essayez d'ajouter l'option FEEDBACK:
qui demande à l'outil d'import d'afficher toutes les 10 lignes importées un caractère.Code:feedback=10
Y-a-il des erreurs dans le fichier alert.log de l'instance ?
Pouvez-vous vous connecter à l'instance sans problème ?
Si la base fonctionne en mode archive log, il y a un risque de saturation du répertoire d'archivage en cas d'import volumineux: cela peut bloquer l'import.
Merci de me repondre :Citation:
Envoyé par pifor
le fichier dump à importer ne fait que 100 MO donc a priori pas très volumineux je ne saurai pas dire le nombre de lignes exact mais puisque j'importe maintenant les tables une à une (car c'est le seul moyen que j'ai trouvé pour ne pas importer sous le tablespace system...rien à faire sinon) ce qui véritablement me dérange c'est la table avec le champ blob car quand j'importe les tables une à une c'est la seule qui pose problème...et puisque c'est la seule qui contient un fichier BLOB cela ne peut venir que de là. Mais je ne trouve pas de solution à l'import de cette table en particulier....
On m'a soufflé une solution éventuelle mais je ne sais absolument pas comment faire (je suis vraiment débutant) ce serait de créer un lien vers cette table spécifiquement pour ne plus avoir besoin de l'importer, je ne sais pas si c'est réalisable et si c'est une bonne solution...
et sinon à propos de archivelog : LOG_MODE : NOARCHIVELOG donc ça ne vient pas de là à priori.
Merci de votre aide
Conclusion un peu hâtive... Difficile de conclure sans message d'erreur...Citation:
.et puisque c'est la seule qui contient un fichier BLOB cela ne peut venir que de là
Que donne l'import avec l'option FEEDBACK=10 ?
Avez-vous vérifié le fichier alert.log ?
Pouvez-vous vérifier avec un outil comme TOAD ou SQL Developper ou un outil XE ce que fait la session Oracle de l'import pendant l'import de cette table ?
Pouvez-vous donner les lignes de commande complètes des commandes export et import avec le log complet ?
Possible sans doute mais cela oblige à modifier le code SQL qui va accéder à la table et à garder la base en 9.Citation:
On m'a soufflé une solution éventuelle mais je ne sais absolument pas comment faire (je suis vraiment débutant) ce serait de créer un lien vers cette table spécifiquement pour ne plus avoir besoin de l'importer, je ne sais pas si c'est réalisable et si c'est une bonne solution...
je l'ai essayé sur l'import de la table en question mais rien ne se passe...c'est comme avant il est écrit import de la table **** et puis c'est tout cela reste bloqué.Citation:
Envoyé par pifor
je suppose que le fichier alerte.log est celui que je specifie dans la comande d'import log=Import.log que je vous donne complètement ici :Citation:
Envoyé par pifor
imp system/poi@XE file='C:\Users\Downloads\Dump DB\2007062fichier.dmp' fromuser=user1 touser=user2 tables=nom_table feedback=10 rows=y ignore=y log=Import.log
pause
dans le fichier Import.log il n'y a rien puisque l'import reste bloquée (si c'est bien celui auquel vous pensiez).
Je vais télécharger toad et faire le test de suite, je vous tiens au courant ;)Citation:
Envoyé par pifor
Bonjour alors j'ai du nouveau,
pour commencer je n'ai pas réussi à télécharger toad car quand je l'installe il me dit que je dois le mettre a jour car il est expiré 8O
puis quand je telecharge la mise à jour elle ne s'installe pas...peut être que cela est du au fait que je suis sous windows vista et qu'il y des problèmes de compatibilité....
Mais le plus important est que : hier avant de partir du bureau j'ai refait une tentative d'import de la table en question (contenant donc le fichier blob) avec l'option "feedback=1" et je me suis rendu compte que l'import semblait sef faire très lentement certes, mais fonctionnait puisque j'avais avant de partir 22 petits carrés :mrgreen:
J'ai donc pris soin de désactiver la mise en veille avant de rentrer chez moi pour lui laisser le temps d'importer toute la nuit.
Je viens d'arriver au bureau et je vois que la fenêtre dos est réduite je l'agrandi puis je constate avec stupeur plusieurs lignes de petits carrés donc l'import a bien progressé mais à peine avais-je eu le temps de voir tous ces petits carrés que la fenêtre s'est refermée :cry: je suis allé vérifier dans l'interface graphique d'oracle et ma table en question ne contient toujours pas de données :cry:
Toutefois je pense que cela permet d'avancer car au moins on sait que l'import se fait mais qu'il est très lent non?
Comment faire pour connaître le nombre de lignes à importer d'une table, en l'occurence celle-ci ? Merci.
Non, il s'agit du fichier alert.log de l'instance qui est dans le répertoire défini par le paramètre d'initialisation BACKGROUND_DUMP_DEST (le fichier s'appelle probablement alertXE.log).Citation:
je suppose que le fichier alerte.log est celui que je specifie dans la comande d'import log=Import.log que je vous donne complètement ici :
Oui, Pour vérifier si les données sont bien insérées, vous pouvez lancer imp avec COMMIT=y: l'import va valider ses transactions sur la table par paquet et non à la fin de la table (mais ça risque de ralentir encore plus l'import).Citation:
Toutefois je pense que cela permet d'avancer car au moins on sait que l'import se fait mais qu'il est très lent non?
Pour accèlérer l'import, vous pouvez essayer de positionner le paramètre BUFFER à une plus grande valeur (la taille maximale de vos LOB).
ah..d'accord mais comment faire concrètement pour y accéder (je suis désolé mais je suis vraiment debutant)Citation:
Envoyé par pifor
ok, donc je rajoute l'option commit=y mais si il bug dans l'import et que je recommence cela signifie qu'il ne va pas réimporter ce qu'il a deja importer precedemment, n'est ce pas ?Citation:
Envoyé par pifor
et a propos du "buffer" comment faire pour y accéder s'il vous plaît.
Sous SQL*Plus:
(il y a probablement un outil graphique qui liste les paramètres de l'instance).Code:show parameter BACKGROUND_DUMP_DEST
oui s'il y a une clé primaire sur la table en question. Sinon vous aurez des lignes en double dans la table (dans ce cas, il vaut mieux supprimer la table avant de lancer l'import).Citation:
ok, donc je rajoute l'option commit=y mais si il bug dans l'import et que je recommence cela signifie qu'il ne va pas réimporter ce qu'il a deja importer precedemment, n'est ce pas ?
C'est un paramètre de la commande imp.Citation:
et a propos du "buffer" comment faire pour y accéder s'il vous plaît
Merci pour tout ces renseignements, je vous tiens au courant de mon avancé.
Alors j'ai lancé l'import avec la commande commit sans même avoir touché au buffer (j'étais trop impatient :oops:) mais je suis allé voir dans l'interface d'oracle et ma table est en train de se remplir des données et pour couronner le tout il semble qu'il y ai une clé primaire.
Enfin voila je croise les doigts pour l'instant et espere que je vais arriver a bout de ce problème...ce serait un grand pas.
Mais si l'import s'arrête pour quelques raisons, je modifierai le buffer comme vous me l'avez suggéré...
A l'heure actuelle l'import est toujours en cours....je ne sais pas si c'est bon signe mais en tout cas sur l'interface web d'oracle les données arrive bien au fur et à mesure, j'en suis à 358 lignes...
Je me demandais ce que je devais faire sachant que je n'ai pas l'intention de coucher au bureau et que lorsque j'avais laisseé l'import se faire hier soir (sans le commit) à mon arrivé ce matin la fenêtre dos s'était fermée presque aussitôt qu'elle s'est ouverte.
Donc si jamais l'import s'interrompt c'est sûr que si je le relance par exemple demain matin il ne vas pas tout recommencer depuis le début?
:yaisse2: à mon arrivé ce matin je pouvais voir d'écrit
"Fin de l'import reussie avec avertissements"
la table s'est importé la nuit durant plus la journée d'hier.
Merci beaucoup pour votre aide Pifor, le seul mystère qui demeure c'est la raison de la lenteur de cet import ???? il a importé 658 lignes mais d'autres tables en avait autant et ça n'a pas pris autant de temps je suppose que le champ blob y est pour quelque chose...
mais bon l'important c'est que l'import ai eu lieu.
Voila merci encore, votre savoir m'a été précieux.
Bonjour Alafu.
Je suis face au même problème et ce que je fais c'est attendre. Est-ce que vous pourriez me dire cela a pris combien de temps au total votre import?
Merci.
Bonjour ilalaina,Citation:
Envoyé par ilalaina
Eh bien je saurai pas vous le dire à l'heure près :mrgreen: mais je l'ai lançé vers 11h et je suis parti du bureau à 19h en le laissant continuer (ne pas oublier de désactiver la mise en veille du PC ;) ) puis le lendemain matin c'etait fait mais je dirais qu'il a du finir vers le milieu de la nuit.....je sais c'est très long mais il faut savoir que j'ai mis feedback=2 je pense que ça ralentit pas mal en plus du commit...mais l'important c'est que ça marche.
Voila j'espere que ma réponse n'arrive pas trop tard et qu'elle vous satisfait,
Bon courage, et si jamais vous trouvez un moyen de l'accélerer n'hesitez pas à me le dire. Enfin deja il serait bon de suivre les conseils de pfior sur le buffer...mais je n'ai pas encore eu l'occasion de le faire.
Pouvez-vous me tenir au courant du temps de votre import, et si possible du nombre de lignes de votre table contenant le champ blob ?
histoire de comparer.
Merci.
Bonjour Alafu.
Ce qui ralentissait mon import en fait (je crois) c'est que je l'ai fait à partir d'un fichier full export de la base. Je l'ai recommencé en important un fichier full export de la table en question (mais pas de la base) et ça n'a pris que 15mn à peine.
Je ne sais pas si mon raisonnement est plausible, à toi d'en juger. En tout cas merci de ton réponse.
Cdt, Ilalaina.
Je vois ce que tu veux dire, j'essaierai cette solution, merci.Citation:
Envoyé par ilalaina