Discussion :

[mikeOSX]

salut a tous,

j'ai un programme en pl/sql qui fait des export et import de tables entre autre.
dernierement, le client a voulu qu'on passe de 8i a 9i.

donc il faut aussi passer ses données de 8i a 9i.
Le client ayant ses propres données, nous ne pouvont pas le faire.

le probleme est que des fois, il y a une erreur lors de l'import dans 9i.

je m'explique:
Je fais un export a partir de la 8i, qui me donne un fichier.
a partir de ce fichier, j'essaye de l'importer dans la 9i avec la commande imp.

des fois ca marche, des fois, il me met une erreur de statistiques....
alors que si je reimporte ce fichier sous 8i, ca passe tres bien.

mes questions:
est ce que c'est normal ce probleme de compatibilité ?
est ce que les statistiques servent a quelque chose ? (vu qu'elles nous posent probleme, on pourrait peut etre envisager de ne pas les exporter)

la commande pour l'import :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

imp user/mdp@bdd tables = archiv_message (...) file=d:\fic.dmp touser=user log = d:\imp.log ignore=Y commit = Y

la commande pour l'export:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

exp user/mdp@bdd tables = archiv_message (...) grants=N constraints=N log = d:\exp.log file=d:\fic.dmp

voila une partie du log de l'import qui plante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
IMP-00017: Echec de l'instruction suivante avec erreur ORACLE 6550 :
 "DECLARE  SREC DBMS_STATS.STATREC; BEGIN SREC.MINVAL := 'C4135A563C'; SREC.M"
 "AXVAL := 'C4135B1E4E'; SREC.EAVS := 0; SREC.CHVALS := NULL; SREC.NOVALS := "
 "DBMS_STATS.NUMARRAY(18898559,18902977); SREC.BKVALS := DBMS_STATS.NUMARRAY("
 "0,1); SREC.EPC := 2; DBMS_STATS.SET_COLUMN_STATS(NULL,'ARCHIV_IPL_VAL','ID_"
 "IPL_VAL',NULL,NULL,NULL,4419,,000226295541977823,0,srec,5,0); END;"
IMP-00003: Erreur ORACLE 6550 rencontrée
ORA-06550: Ligne 1, colonne 330 :
PLS-00103: Symbole "," rencontré à la place d'un des symboles suivants :
 
   ( - + case mod new not null others <an identifier>
   <a double-quoted delimited-identifier> <a bind variable> avg
   count current exists max min prior sql stddev sum variance
   execute forall merge time timestamp interval date
   <a string literal with character set specification>
   <a number> <a single-quoted SQL string> pipe
Symbole "null" a été substitué à "," pour continuer.

l'erreur viendrait ici (en rouge)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DBMS_STATS.SET_COLUMN_STATS(NULL,'ARCHIV_IPL_VAL','ID_IPL_VAL',NULL,NULL,NULL,4419,,000226295541977823,0,srec,5,0)

merci

mike

[scheu]

Tu utilises bien la commande "exp" en version 8i et la commande "imp" en version 9i ?

[mikeOSX]

il me semble qu'entre les 2 versions, les commandes pour importer et exporter sont exactement les memes entre 8i et 9i

donc oui, pour importer sous 9i, j'utilise imp, et pour exporter sous 8i, j'utilise exp

[ducho]

Bonjour,

J' ai rencontré à peu prés le même souci ,

Normalement, il suffit de lancer l' Import avec statistics=none ..

Et relancer les stats apres l' import ...

cdlt

[mikeOSX]

salut ducho,

c'est l'une des solutions que j'avais envisagé, mais ca ne m'arrange pas plus que ca, car la version du logiciel avec 8i est deja livrée chez le client.

les statistiques, ca sert a quelque chose si personne ne les consulte ?
a quoi ca sert de les exporter par defaut ? ou de les exporter tout court ?

merci

mike

[ducho]

Bonjour,

l' option statistics=none existe aussi dans l' export .
personnelement je ne vois pas non plus l' intéret de les exporter ,
peut-être utiles au cas ou en oracle9 , tu te sers de l' optimiseur Oracle8 ??

les statistiques, d' une façon générale, sont surtout utiles à Oracle .
si elles sont présentes en oracle8, il faudra les réexecuter sous Oracle9
sinon tu auras des surprises sur les temps de réponse des requêtes ...

Pour un complément d' infos sur les stats, il vaudrait mieux que tu regardes
la doc et le forum qui regorgent de posts sur l' optimisation des requêtes

cdlt

[mikeOSX]

Salut,

je ne me sers pas de l'optimiseur, ou tout du moins pas a ma connaissance, j'ai repris un logiciel deja existant, et je ne le connais pas dans les moindre recoins

en fait, lorsque j'importe, j'importe des tables temporaires, donc qui vont servir juste apres l'import, puis ne plus servir.

je suppose qu'il y a une requete en PL/SQL pour recalculer ces statistiques ?

c'est long de recalculer les stats ?
a savoir si ca sert, car ces tables, je m'en sert une fois, puis plus du tout, donc a savoir ou est ce que je perdrai le moins de temps.

merci

mike

[Mikl-Dba]

Salut,

J'ai plusieurs fois rencontré ce type de soucis sur de la prod, entre des bases 8.1.7 et 9.2.0, et en fait le souci semble connus (de mémoire, une note metalink en relate, je vais tenter la recherche..)..

J'ai également passé quelques jours à me tirer les cheveux , et en fait ce problème, qui en fait n'en est pas vraiment un puisqu'il n'agit pas sur les données et que cela concerne l'optimisation de la base, est sans gravité, il indique juste que les stats permettant d'alimenter l'optimiser n'ont pas été importées. Le fonctionnement et la library de l'optimiser entre 8 et 9 est bien sur différent, et d'après la note Metalink, cela pourrai engendrer ce type d'erreur.

cela ne se produit qu'entre base 8i et 9i. Je n'ai a ce jour sur mes plusieurs client pas connus d'autre bug de ce type, entre d'autres versions supérieures ou égales.

Bref, en fait j'ai plus ou moins contourné le souci, en encapsulant dans un shell l'appel à l'export, suivi d'un calcul de stat en "estimate" avec le package dbms_stats , lancé sur les schémas de la base, en tache de fond coté OS.

Certes cela te prend de la ressource machine après l'export, aussi je te conseille de le faire la nuit si tu est en prod...

J'avoue que ca corrige pas ton pb, ca le contourne, mais c'est une méthode qui fonctionne.

Si tu est interresé je peut te passer un tit script.

Bon courage,
Mikl.

[mikeOSX]

salut mikl

le probleme en fait, n'est pas pour moi, mais c'est pour le client.
car avant, on avait l'habitude de lui passer ses trucs de la version 8i a 9i, donc vu qu'on a le code, on peut modifier et faire comme on veut

mais depuis quelques temps, il veut le faire lui meme, donc il n'a que l'executable sous 8i qui exporte a chaque fois les stats, et l'executable sous 9i qui les importe, et des fois, ca plante.

donc si les stats sur des tables temporaires ne servent quasi a rien, faudra que je vois s'il est possible de leur refiler une ancienne version modifiée (sans stats).

ou si vous avez d'autres idées...

merci

mike

[Mikl-Dba]

Il est vrai que des Stats sur des tables temporaire n'est pas vraiment utile, cela ne sert que sur des tables fixes qui sont amenées à évoluer.

Ta solution peut fonctionner avec une ancienne version, mais peut être suffirait il d'expliquer au client que cela ne provoque aucune erreur sur le SGBDR.
A tu essayé l'option ignore=y ? il me semble qu'elle évite cette remontée d'erreur (ce n'est pas recommandé, mais si tu es sur que c'est le seul problème...)

Pour info, voici ma méthode d'import qui consiste à splitter chaque partie :

=> Import de la structure des tables (rows=n), sans index
=> Import des datas , toujours sans index avec ignore=y
=> récration des index
=> Execution des stats sur les schémas importés.

Mes clients utilise mon script, et ne constate pas cette erreur alors qu'elle est pourtant bien présente...mais les stats pouvant être rejouées, je fait en sorte de les virer direct de la log.....

Sinon dernière solution :
Avant l'export de la base source, tu vire les stats de tes schémas (DBMS_STATS.delete_schemas_stats.....) et ensuite une fois que c'est fait tu peut faire un export (full ou non) et ensuite procéder ton import sur la base cible et tu n'auras plus ce soucis. Par contre il faudra refaire des stats sur la base cible.

Bonne journée
Mikl

[mikeOSX]

non, je n'ai pas testé avec ignore=y
normalement, c'est la seule erreur, mais est ce vraiment "serieux" de mettre ca, car si une autre erreur arrivait comme ca, on ne pourrait pas le savoir.

pour l'import, on fait tout ca en une seule fois, on peut ensuite decouper l'export ?

ou est ce qu'on peut tout simplement ne pas importer les stats meme si elles ont été exportées ?

merci

mike