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

[farenheiit]

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

[scheu]

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 ?

[farenheiit]

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?

[LeoAnderson]

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


que donnent l'alert.log et les traces ?

[farenheiit]

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

[Heaven93]

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

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.

[farenheiit]

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?

[LeoAnderson]

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

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

[farenheiit]

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

[scheu]

Envoyé par farenheiit

Code :

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

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

???

[LeoAnderson]

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

[orafrance]

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

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

[Heaven93]

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

[farenheiit]

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.