ORA-04030 lors d'un import [Résolu]

[tck-lt]

Bonjour,

je rencontre actuellement des difficultés d'import sur une base en 10.2.0.3 située sur un serveur AIX 5.3 (utilitaire impdp utilisé pour l'import non full). Voici le message d'erreur :

Traitement du type d'objet DATABASE_EXPORT/SCHEMA/PACKAGE/PACKAGE_SPEC
ORA-39125: Erreur grave inattendue du processus esclave dans KUPW$WORKER.PUT_DDLS lors de l'appel de DBMS_METADATA.CONVERT []
ORA-04030: mémoire de traitement manquante lors d'affectation de 65584 octets (session heap,kuxLpxAlloc)

ORA-06512: à "SYS.DBMS_SYS_ERROR", ligne 95
ORA-06512: à "SYS.KUPW$WORKER", ligne 6228

----- PL/SQL Call Stack -----
object line object
handle number name
700000020f5f0a8 14916 package body SYS.KUPW$WORKER
700000020f5f0a8 6293 package body SYS.KUPW$WORKER
700000020f5f0a8 12280 package body SYS.KUPW$WORKER
700000020f5f0a8 3278 package body SYS.KUPW$WORKER
700000020f5f0a8 6882 package body SYS.KUPW$WORKER
700000020f5f0a8 1259 package body SYS.KUPW$WORKER
70000001c1c3c80 2 anonymous block

Tâche "SYSTEM"."SYS_IMPORT_SCHEMA_13" arrêtée en raison d'une erreur grave à 11:11:31

J'ai donc effectué quelques recherches sur le net et modifié quelques paramètres. J'ai en particulier augmenter la PGA de 100Mo à 500Mo. J'ai également effectuer quelques modifications sur le fichier /etc/security/limits comme indiqué dans le lien suivant. Ce qui me donne :

@atef:/users/atef/ora $ ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes) 32768
memory(kbytes) unlimited
coredump(blocks) unlimited
nofiles(descriptors) 2000

Voici autrement les paramètres PGA (que je ne sais pas interprété):

SQL> select * from v$pga_target_advice;

PGA_TARGET_FOR_ESTIMATE PGA_TARGET_FACTOR ADV BYTES_PROCESSED ESTD_EXTRA_BYTES_RW ESTD_PGA_CACHE_HIT_PERCENTAGE ESTD_OVERALLOC_COUNT
----------------------- ----------------- --- --------------- ------------------- ----------------------------- --------------------
65536000 ,125 ON 386658304 61820928 86 6
131072000 ,25 ON 386658304 0 100 0
262144000 ,5 ON 386658304 0 100 0
393216000 ,75 ON 386658304 0 100 0
524288000 1 ON 386658304 0 100 0
629145600 1,2 ON 386658304 0 100 0
734003200 1,4 ON 386658304 0 100 0
838860800 1,6 ON 386658304 0 100 0
943718400 1,8 ON 386658304 0 100 0
1048576000 2 ON 386658304 0 100 0
1572864000 3 ON 386658304 0 100 0
2097152000 4 ON 386658304 0 100 0
3145728000 6 ON 386658304 0 100 0
4194304000 8 ON 386658304 0 100 0

SQL> select * from v$pgastat;

NAME VALUE UNIT
---------------------------------------------------------------- ---------- ------------
aggregate PGA target parameter 524288000 bytes
aggregate PGA auto target 453878784 bytes
global memory bound 104857600 bytes
total PGA inuse 20070400 bytes
total PGA allocated 49342464 bytes
maximum PGA allocated 171080704 bytes
total freeable PGA memory 10289152 bytes
process count 18
max processes count 23
PGA memory freed back to OS 410386432 bytes
total PGA used for auto workareas 0 bytes
maximum PGA used for auto workareas 25566208 bytes
total PGA used for manual workareas 0 bytes
maximum PGA used for manual workareas 537600 bytes
over allocation count 0
bytes processed 1536091136 bytes
extra bytes read/written 26340352 bytes
cache hit percentage 98,31 percent
recompute count (total) 5161

Ce qui est étrange, c'est que j'ai une dizaine d'instance sur ce serveur et c'est la seule qui me sorte cette erreur lors d'un import.

Je me tourne donc vers vous pour me venir en aide.

Merci d'avance.

[mboubidi]

Bonjour,
c'est quoi la valeur de sort_area_size and/ou hash_area_size

[Heaven93]

bonjour,

regarde sur metalink la description du bug 6051734. ça a l'air de correspondre à ton cas. il existe un patch générique à appliquer.

[tck-lt]

Avec un exp/imp au lieu d'expd/impdp, c'est passé. Pour le moment, je ne peux pas retoucher à la base et faire les tests. Dès que je peux je vais appliquer le patch voir si ça change quelque chose.

[tck-lt]

Envoyé par Heaven93

bonjour,

regarde sur metalink la description du bug 6051734. ça a l'air de correspondre à ton cas. il existe un patch générique à appliquer.

Merci, pour cette info, car j'ai le même souci pour une autre base. Les patchs existant en sont à priori qu'à partir de la 10.20.4, or je suis en 10.2.0.3, pensez-vous que je puisse l'appliquer quand même (j'en doute mais bon...)

Edit : après quelques recherches sur Metalink, je l'ai enfin trouvé en 10.2.0.3. Il fallait en fait que je cherche juste le 6051734 et non le 9541999 qui corrige 2 bugs dont le 6051734.

Je teste ça et je vous redis.

[tck-lt]

Même après avoir passé le patch, j'ai toujours le même problème :

Traitement du type d'objet DATABASE_EXPORT/SCHEMA/PACKAGE/PACKAGE_SPEC
ORA-39125: Erreur grave inattendue du processus esclave dans KUPW$WORKER.PUT_DDLS lors de l'appel de DBMS_METADATA.CONVERT []
ORA-04030: mémoire de traitement manquante lors d'affectation de 65584 octets (session heap,kuxLpxAlloc)

ORA-06512: à "SYS.DBMS_SYS_ERROR", ligne 95
ORA-06512: à "SYS.KUPW$WORKER", ligne 6228

----- PL/SQL Call Stack -----
object line object
handle number name
7000000227211c0 14916 package body SYS.KUPW$WORKER
7000000227211c0 6293 package body SYS.KUPW$WORKER
7000000227211c0 12280 package body SYS.KUPW$WORKER
7000000227211c0 3278 package body SYS.KUPW$WORKER
7000000227211c0 6882 package body SYS.KUPW$WORKER
7000000227211c0 1259 package body SYS.KUPW$WORKER
7000000224f75b0 2 anonymous block

Tâche "SYSTEM"."SYS_IMPORT_FULL_06" arrêtée en raison d'une erreur grave à 19:02:26

[tck-lt]

Je viens également de passer le patch 4352110 et toujours le même souci.

[Heaven93]

ok. on va reprendre depuis le début. quelle est la ligne de commande passée pour l'import? est-ce que tu le fais directement sur le serveur ou via le listener?

[Pomalaix]

Envoyé par Heaven93

... est-ce que tu le fais directement sur le serveur ou via le listener?

Les deux sont tout à fait compatibles...

[tck-lt]

Je suis directement sur le serveur de BDD :

impdp system/xxxxxxx DIRECTORY=data_pump_dir DUMPFILE=expdpVHIP.dmp LOGFILE=impdpVHIP.log REMAP_SCHEMA=VHI35:VHI35 TABLE_EXISTS_ACTION=REPLACE

[Heaven93]

peux-tu s'il te plait essayer de nouveau en ajoutant une clause exclude=statistics?

[tck-lt]

En fait je n'utilisais pas correctement la commande. Ce n'est pas REAMP_SCHEMA que je devais faire (vu que les schémas portent le même nom) mais SCHEMAS=VHI35. Du coup, il tentait de remplacer des tables du schéma SYS d'où mes erreurs.

Merci à vous.