erreur "Segmentation Fault" lors de l'import d'un dump

bonjour,

Je travaille sur une base 9i et j'essaye d'importer un dump d'un schéma qui avaité été effectué il y'a 2 ans sous une base Oracle 7 mais j'obtiens l'erreur suivante sur une des tables:

Code:

---

1 2 3 4 5

es < . . Import de la table "TNSR_PROD" 1528 lignes importé es < . . Import de la table "TNSR_PROD_LDR" 1552 lignes importé es < . . Import de la table "TOPEMAR_CME_LDR" 24978 lignes importé es < . . Import de la table "TOPERATION"Segmentation Fault

---

L'import s'arrête alors à ce niveau là.
Quelqu'un peut-il m'aider?
voici ma commande d'import:

Code:

---

imp admin_prism/admin_prism fromuser=DBO_DEC05_PAP touser=DBO_DEC05_PAP file=prism_dbo_dec05_pap_20070208_1.dmp,prism_dbo_dec05_pap_20070208_2.dmp,prism_dbo_dec05_pap_20070208_3.dmp,prism_dbo_dec05_pap_20070208_4.dmp,prism_dbo_dec05_pap_20070208_5.dmp,prism_dbo_dec05_pap_20070208_6.dmp log=dbo_dec05_pap.log IGNORE=N INDEXES=Y

---

L'import s'arrête au niveau du 4ème fichier de dump.
merci de votre aide

Et si tu testes de n'importer que la table TOPERATION du 4 ème fichier avec une commande du style

Code:

---

imp admin_prism/admin_prism fromuser=DBO_DEC05_PAP touser=DBO_DEC05_PAP file=prism_dbo_dec05_pap_20070208_4.dmp log=dbo_dec05_pap_5.log tables=DBO_DEC05_PAP.TOPERATION

---

tu as la même erreur ou pas ?

je viens d'essayer et voilà ce que j'obtiens:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

Import: Release 9.2.0.8.0 - Production on Ma Nov 27 16:02:40 2007   Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.     Connecté à : Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit Production With the Partitioning, OLAP and Oracle Data Mining options JServer Release 9.2.0.8.0 - Production   Fichier d'export créé par EXPORT:V08.01.06 via le chemin direct   Attention : les objets ont été exportés par SYS, et non par vous   import effectué dans le jeu de caractères WE8ISO8859P1 et le jeu NCHAR AL16UTF16 le serveur d'import utilise le jeu de caractères NCHAR WE8ISO8859P1 (conversion possible) IMP-00046: utilisation de la valeur de FILESIZE du fichier d'export : 713031680 IMP-00047: numéro de séquence de fichier inattendu ; 1 attendu mais 4 trouvé IMP-00132: le premier fichier de l'export multi-fichiers est prism_dbo_dec05_pap_20070208_1.dmp IMP-00000: Procédure d'import terminée avec erreur

---

quelqu'un a une idée?

essayez d'importer le dump dans une 8i puis export/import vers une 9i


que donnent l'alert.log et les traces ?

je n'ai rien dans le fichier Alert à part des info sur l'archivage des redo logs.

:-(

je vais essayer de passer par une 8i

S'agit-il d'une version inférieure à 7.1.3 ?
Sur metalink, il y a une note relatant un bug générique lors d'exports sur des lignes contenant des commentaires (l'export ne se ferait pas dans le bon format syntaxique)?
est-ce qu'il pourrait s'agir de cela?
si oui, voir la Note:1005054.6 sur metalink

Citation:

---

Problem Description:
====================
The problem was reported in 7.0.13.1, and it is considered a generic bug.
EXP will not export the stored object in a proper syntactic format.
IMP will import everything without complaining but the stored object with the
bad format will not be imported at all.

---

je n'ai aucune idée de la version exacte d'oracle avec lequel a été effectué l'export.
y'a t'il un moyen de savoir ça avec les fichiers dumps?

Citation:

---

Fichier d'export créé par EXPORT:V08.01.06 via le chemin direct

---

je suis pas convaincu qu'il provienne d'une 7.... :?

effectivement,
je n'étais pas sur le projet il y'a 2 ans. On m'a dit que c'était en oracle 7 mais ils ont dû se tromper.
En tout cas ça ne fait pas avancer mon problème
:-(

Citation:

---

Envoyé par farenheiit

Code:

---

1 2 3

IMP-00047: numéro de séquence de fichier inattendu ; 1 attendu mais 4 trouvé IMP-00132: le premier fichier de l'export multi-fichiers est prism_dbo_dec05_pap_20070208_1.dmp

---

---

Mouais mon idée ne marchait pas s'il faut que tu importes tous tes fichiers d'un coup :aie:

Et ca donne quoi en essayant d'importer juste la table qui avait fait planter

Code:

---

1 2

imp admin_prism/admin_prism fromuser=DBO_DEC05_PAP touser=DBO_DEC05_PAP file=prism_dbo_dec05_pap_20070208_1.dmp,prism_dbo_dec05_pap_20070208_2.dmp,prism_dbo_dec05_pap_20070208_3.dmp,prism_dbo_dec05_pap_20070208_4.dmp,prism_dbo_dec05_pap_20070208_5.dmp,prism_dbo_dec05_pap_20070208_6.dmp log=dbo_dec05_pap.log TABLES=DBO_DEC05_PAP.TOPERATION

---

???

au moment de l'export, ont-ils eu la bonne idée d'en faire des cksum ou autre md5sum ?

certains ont fait état de soucis si on a zippé le dump aussi :?

sinon, un dump 7 est-il bien supporté en 9... je pense notamment à la taille des blocs... faudrait aussi s'assurer que l'OS d'origine était le même :?

il me semblait que l'export devait être fait dans la même version que l'import aussi :koi:

Ca sent quand même l'incompatibilité d'architecture (32/64 bits), de version ou d'OS :(

:oops: je n'avais pas vu pour la version. désolée.

Citation:

---

Et ca donne quoi en essayant d'importer juste la table qui avait fait planter

---

ba ça donne la même erreur.

je me suis renseigné finalement le dump avait bien été effectué en oracle 8. Le chef de projet avait confondu avec le fait qu'on était en Weblogic 7 sur le serveur d'application.

je pense qu'Orarance a raison c'est un probleme de zip car en fait les dumps ont été zippé et gravé sur 2 Cd différents avec Roxio et dont le fameux fichier dump numero 4 qui était coupé en 2 sur les 2 CD. A mon avis ça vient de là.

Je vais essayer d'importer un autre dump qui se trouve sur un seul CD pour voir si ça marche cette fois.