ORA-03113 sur export full

Bonjour à tous,

Voici un problème qui me résiste depuis 2 jours.
Nous avons une base Oracle en 9.2.0.6 (version dé-supportée depuis longtemps, mais nous n'avons pas le choix...), sur laquelle nous lançons un export full chaque nuit.

La ligne de commande est de la forme suivante :

Code:

---

1 2	exp system/xxx FULL=Y DIRECT=Y CONSISTENT=Y recordlength=65535 buffer=20000000 FILE=mydump.dmp log=mylog.log

---

Ca a très bien marché pendant des années. Mais depuis hier nous avons, immédiatement, le message suivant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

Export: Release 9.2.0.6.0 - Production on Je Oct 25 11:28:09 2012   Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. Connecté à: Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production JServer Release 9.2.0.6.0 - Production   Export fait dans le jeu de car WE8ISO8859P15 et jeu de car NCHAR AL16UTF16   Prêt à exporter l'intégralité de la base de données ... . export des définitions de tablespace EXP-00008: Erreur ORACLE 3113 rencontré ORA-03113: fin de fichier sur canal de communication EXP-00000: Procédure d'export terminée avec erreur

---

Dans le même temps, on récupère cette ligne dans alert.log :

Code:

---

1 2	ORA-07445: exception trouvée : vidage coeur [] [] [] [] [] []

---

Autre information intéressante : le même export fonctionne très bien si on force l'usage de la couche SQL*Net :
- soit en écrivant la ligne de commande comme ça : "exp system/xxx@ALIAS_SQLNET"
- soit en positionnant TWO_TASK à ALIAS_SQLNET

D'avance, merci beaucoup.

Bonjour,


J'ai expérimé des ORA-03113 aléatoires sur des instances data guard en 11g. Le support Oracle a attendu que le projet soit fini (c'était un projet très cours -> 6 mois) pour classer le dossier...

- Pouvez-vous faire un tnsping de l'instance à partir de votre machine qui fait l'export ?
- Quel est le contenu des fichiers listener.ora et tnsnames.ora ?

Cordialement,

Arkhena

ORA-7445 est une erreur liée à l'OS.

De ce que vous dites, ça semble lié aux IPC (utilisées en mode direct mais pas en mode SQL*Net).

Vous avez un contournement, utilisez le et essayez de demander l'analyse du core généré à Oracle.

Merci pour vos réponses.

En dépiautant le fichier trace généré au moment de l'ORA-07445, je me suis aperçu que la requête incriminée était la suivante :

Code:

---

1 2	SELECT FNAME, FSIZE, MAXEXTEND, INC FROM SYS.EXU9FIL WHERE TSID = :1

---

En lançant cette même requête sous Sql*Plus (sans la clause WHERE), je retrouve effectivement mon ORA-03113 à l'écran et mon ORA-07445 dans alert.log.

J'ai ouvert un SR sur MOS, on va voir... je laisse la discussion ouverte si jamais je trouve la solution.

Bonjour,

Je reviens sur ce post après quelques jours...

Sur MOS, on s'oriente vers un problème de mémoire sur le serveur. Possible, mais...
- mon collègue administrateur Unix n'a rien trouvé qui correspond à cela
- même en arrêtant toutes les autres instances qui tournent sur le serveur (pour libérer de la mémoire), le problème reste le même.

En revanche, j'ai modifié le paramètre d'initialisation db_files à 10 (au lieu de 7)... et le problème a disparu !!! (NB : la base comporte 6 datafiles)

Je ne sais qu'en penser...

Salut a tous
y'a une note metalink qui parle de ça:
421750.1

T'as regardé?
Ça s'applique a 10.2

Code:

---

1 2 3

Applies to:   Oracle Server - Enterprise Edition - Version: 10.2.0.1 and later

---

...peu être ça vaut le coup de jetter un oeil, a priori ça aurait a voir avec ceci:

Citation:

---

Its very likely to see these errors when we have invalid JVM / XDB in the database
If the error occurs while running above query and if you see all registry components and java objects in valid status.
Then it is very likely a problem with underlying JVM, you can try reloading the JVM

---

y'a eu recement un changement de version de java? ou un changement dde parametre memoire avec java?

Bonjour,

Après bien des péripéties et des essais infructueux, j'ai fini par déplacer cette fichue base sur un autre serveur AIX rigoureusement identique en tous points.

Et là, bien sûr, ça marche. Grrr... :cry: