IMP/EXP shcema 8i => 10g [Résolu]

[guigui_cwoco]

Bonjour,

J'ai besoin d'exporter le schéma d'une base de données en 8i.

L'export ce passe niquel.

Par contre l'import rencontre quelques erreurs :

IMP-00019: row rejected due to ORACLE error 12899
IMP-00003: ORACLE error 12899 encountered
ORA-12899: value too large for column "IMPLEX_GL"."S4T_ELMT"."ELMT_DESIGNATION" (actual: 51, maximum: 50)

Et ceci pour pas mal de colonnes .. Je ne pense pas que redimensionner les colonnes a la main est une bonne idée.
Que faire ?!

Deuxieme solution :
Touts ces objects sont créés par une application. Il est possible de re installer une base vierge avec l'application.
A ce moment la il suffirait de re importer que les données (CONTENT=DATA_ONLY), mais apparement je ne peux utiliser IMPDP avec un dump de 8i ... donc bloqué.

Des idées ?!

[nuke_y]

Comment se fait-il que la taille définie dans la source et dans la cible ne soit pas la même ?

[pifor]

Quels sont les jeux de caractères de la base source et de la base cible ?

[guigui_cwoco]

Export file created by EXPORT:V08.01.07 via conventional path
import done in US7ASCII character set and AL16UTF16 NCHAR character set
import server uses AL32UTF8 character set (possible charset conversion)
export client uses WE8ISO8859P1 character set (possible charset conversion)
export server uses WE8ISO8859P1 NCHAR character set (possible ncharset conversion)

Pas les memes jeux de caractères certes, mais conversion possible a priori ...

[pifor]

Pouvez-vous donner le résultat de la requête sur les 2 bases
de:

SELECT * FROM NLS_DATABASE_PARAMETERS;

Si la base cible est bien en AL32UTF8 (multi byte) et la base source est en WE8ISO8859P1 (single byte), il faut positionner NLS_LENGTH_SEMANTICS à CHAR au lieu de BYTE avant la création des objets dans la base cible(voir http://download-uk.oracle.com/docs/c....htm#sthref385

[guigui_cwoco]

EDIT :

La base source (8i)

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
PARAMETER                      VALUE
------------------------------ --------------------------------
NLS_LANGUAGE                   AMERICAN
NLS_TERRITORY                  AMERICA
NLS_CURRENCY                   $
NLS_ISO_CURRENCY               AMERICA
NLS_NUMERIC_CHARACTERS         .,
NLS_CHARACTERSET               WE8ISO8859P1
NLS_CALENDAR                   GREGORIAN
NLS_DATE_FORMAT                DD-MON-RR
NLS_DATE_LANGUAGE              AMERICAN
NLS_SORT                       BINARY
NLS_TIME_FORMAT                HH.MI.SSXFF AM
 
PARAMETER                      VALUE
------------------------------ --------------------------------
NLS_TIMESTAMP_FORMAT           DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT             HH.MI.SSXFF AM TZH:TZM
NLS_TIMESTAMP_TZ_FORMAT        DD-MON-RR HH.MI.SSXFF AM TZH:TZM
NLS_DUAL_CURRENCY              $
NLS_COMP                       BINARY
NLS_NCHAR_CHARACTERSET         WE8ISO8859P1
NLS_RDBMS_VERSION              8.1.7.0.0

La base cible (10g)

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
 
PARAMETER                                VALUE
---------------------------------------- --------------------
NLS_LANGUAGE                             AMERICAN
NLS_TERRITORY                            AMERICA
NLS_CURRENCY                             $
NLS_ISO_CURRENCY                         AMERICA
NLS_NUMERIC_CHARACTERS                   .,
NLS_CHARACTERSET                         AL32UTF8
NLS_CALENDAR                             GREGORIAN
NLS_DATE_FORMAT                          DD-MON-RR
NLS_DATE_LANGUAGE                        AMERICAN
NLS_SORT                                 BINARY
NLS_TIME_FORMAT                          HH.MI.SSXFF AM
 
PARAMETER                                VALUE
---------------------------------------- --------------------
NLS_TIMESTAMP_FORMAT                     DD-MON-RR HH.MI.SSXF
                                         F AM
 
NLS_TIME_TZ_FORMAT                       HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT                  DD-MON-RR HH.MI.SSXF
                                         F AM TZR
 
NLS_DUAL_CURRENCY                        $
NLS_COMP                                 BINARY
NLS_LENGTH_SEMANTICS                     BYTE
NLS_NCHAR_CONV_EXCP                      FALSE
 
PARAMETER                                VALUE
---------------------------------------- --------------------
NLS_NCHAR_CHARACTERSET                   AL16UTF16
NLS_RDBMS_VERSION                        10.2.0.1.0

[guigui_cwoco]

Envoyé par pifor

il faut positionner NLS_LENGTH_SEMANTICS à CHAR au lieu de BYTE avant la création des objets dans la base cible(voir http://download-uk.oracle.com/docs/c....htm#sthref385

Apparement je n'arrive pas a changer la valeur, peut etre je m'y prends mal :

Code :

1
2
3
4
5
6
7
8
 
SQL> SELECT * FROM NLS_DATABASE_PARAMETERS WHERE parameter = 'NLS_LENGTH_SEMANTICS';
 
PARAMETER                                VALUE
---------------------------------------- --------------------
NLS_LENGTH_SEMANTICS                     BYTE
 
SQL>

=> j'ai redémarré mon instance avec le parametre bien positionné dans le pfile :

Code :

1
2
3
4
 
[oracle@ateq-gl dbs]$ cat initateqora.ora | grep nls
*.nls_length_semantics='CHAR'
[oracle@ateq-gl dbs]$

Evidemment avant ca j'ai essayé :

Code :

1
2
 
ALTER system SET NLS_LENGTH_SEMANTICS = CHAR scope = MEMORY;

Rien n'y fais.

D'apres la documentation, on peut le changer via ALTER SESSION, mais dans mon cas cela ne fonctionnera pas, puisque mon import (via IMP) se fera avec une nouvelle session ...


Un peu d'infos avec Metalink a prendre en compte :

The import utility uses a value of NLS_LENGTH_SEMANTICS from the export dump
file, not from the target database settings. So you will likely run into errors like
" ORA-01401: inserted value too large for column " during the import from a single
byte characterset to an unicode database.
If you want to migrate tables from BYTE to CHAR semantics using export/import
you need to precreate the tables with the NLS_LENGTH_SEMANTICS set to CHAR and
then import with IGNORE=Y.

[pifor]

L'option est peut-être définie au niveau du registre Windows ou de l'environnement Unix ? Dans ce cas là, il faut redéfinir la valeur dans l'environnement OS juste avant de lancer l'exécutable d'import:

Code :

1
2
Sous Windows:
SET NLS_LENGTH_SEMANTICS=CHAR

Sous Unix en ksh:

Code :

export NLS_LENGTH_SEMANTICS=CHAR

[guigui_cwoco]

Pas mieux.

Code :

1
2
3
 
[oracle@ateq-gl bin]$ echo $NLS_LENGTH_SEMANTICS
CHAR

[pifor]

J'ai tord et la note Metalink a raison: le fichier export créé le DDL pour créer la table et le DDL comprend pour chaque objet la taille des colonnes avec l'option NLS_LENGTH_SEMANTICS en dur. Il faut bien recréer les objets en question avant l'import avec la bonne option:

Code :

CREATE TABLE t(x VARCHAR2(30  CHAR));

[guigui_cwoco]

OK.

Bon effectivement re créer les objets a la main est une solution. Cepandant il y a plus de 1000 objets a vérifier, et probablement bien trop pour tout re créer a la main.

Apparement, les objets peuvent être créés par l'application. J'ose espérer que cette application étant bien concue, si on lui demande de re créer les objets sur la nouvelle base 10g, elle le fera proprement et prendra en compte le jeu de caractères UTF8. Est ce que ca pourrai résoudre mon probleme d'import ?

Si oui, via l'utilitaire d'importation IMP, est il possible d'importer seulement les données ?! (Correspondance sous IMPDP : CONTENT=DATA_ONLY).
Je suggère d'utiliser le parametre IGNORE=Y.

[orafrance]

ROWS=N n'insère pas les data sinon

[pifor]

Envoyé par guigui_cwoco

OK.

Apparement, les objets peuvent être créés par l'application. J'ose espérer que cette application étant bien concue, si on lui demande de re créer les objets sur la nouvelle base 10g, elle le fera proprement et prendra en compte le jeu de caractères UTF8. Est ce que ca pourrai résoudre mon probleme d'import ?

Si l'application ne code pas en dur BYTE dans les colonnes CHAR, VARCHAR2 des instructions CREATE TABLE ou ALTER TABLE (i.e. si elle utilise le paramètre NLS_LENGTH_SEMANTICS de l'instance), ça doit marcher.

Je ne suis pas sûr que l'option ROWS=N peut créer le bon DDL car l'export va probablement coder en dur BYTE dans le fichier export au lieu de CHAR.

[guigui_cwoco]

Bon je vais essayer de voir tout ca.
Merci de votre aide, je ferai un UP avec des nouvelles infos.

[guigui_cwoco]

Mesdames, Messieurs,

Bon ca y est j'ai réussi a migrer ma base !

Donc 2 imports différents :

Code :

1
2
 
./imp system/oracle file=/home/oracle/SCHEMA_IMPLEX.DMP log=/home/oracle/IMPORT_IMPLEX.log fromuser=implex touser=implex rows=n constraints=y compile=y

Le premier pour créer les objets sans les données.

Puis modification des colonnes qui posent probleme :

Code :

1
2
3
 
ALTER TABLE "IMPLEX"."S4T_ELMT" MODIFY (ELMT_DESIGNATION VARCHAR2(50 CHAR));
...

Puis second import pour remplir les tables :

Code :

1
2
 
./imp system/oracle file=/home/oracle/SCHEMA_IMPLEX.DMP log=/home/oracle/IMPORT_IMPLEX.log 	fromuser=implex touser=implex rows=y constraints=n compile=n IGNORE=y

Entre les 2 imports il faut désactiver triggers & contraintes, donc récupérer dans un script SQL le nom de toutes les contraintes et triggers du
schéma via les vues DBA_CONSTRAINTS et DBA_TRIGGERS.

Recompiler le schéma avec DBMS_UTILITY.COMPILE_SCHEMA.

Et tester ...

Bref pour une premiere migration, je trouve que je m'en sors pas trop mal !

Merci de vos conseils