migration oracle9 en UTF8

Version imprimable

Voir 40 message(s) de cette discussion en une page

02/05/2007, 09h31
ljoly

migration oracle9 en UTF8
Bonjour,

je migre un base 8.1.7.4 en WE8ISO8859P1 vers une base 9.2.0.8 en UTF8. je fais un export des schémas sur la base source puis un import sur la base cible. j'ai un problème car les caractéres spéciaux (accents...) sont codés sur 2 caractères en UTF8 au lieu de 1 en WE8ISO. Cela provoque des depassements de taille de colonnes et le message suivant:
Code:

1 2 3 IMP-00019: row rejected due to ORACLE error 1401 IMP-00003: ORACLE error 1401 encountered ORA-01401: inserted value too large for column
Je n'ai pas la possibilité de modifier le format des tables.
Quelqu'un a t'il déjà rencontré ce type de problème?
02/05/2007, 09h45
LeoAnderson

oui, c'est une classique.
vous devez créer les tables avec le NLS_LENGTH_SEMANTICS correctement positionné (i.e. CHAR) ou spécifier CHAR dans la définition des colonnes VARCHAR2 puis, ensuite, importer le dump IGNORE=Y ROWS=Y

C'est lié à la structure UTF
Téléphones= 10 caractères = 10 bytes en ISO, 12 en UTF
et l'import garde la même structure VARCHAR2(10 BYTES) => VARCHAR2(10 BYTES), et ce quelque soit le NLS_LENGTH_SEMANTICS

[EDIT]
le plus simple et le plus propre serait sûrement de migrer la base de 8i en 9i (par upgrade) puis ensuite, de changer le CS
[/EDIT]
02/05/2007, 10h09
ljoly

Citation:

Envoyé par LeoAnderson

oui, c'est une classique.
vous devez créer les tables avec le NLS_LENGTH_SEMANTICS correctement positionné (i.e. CHAR) ou spécifier CHAR dans la définition des colonnes VARCHAR2 puis, ensuite, importer le dump IGNORE=Y ROWS=Y

C'est lié à la structure UTF
Téléphones= 10 caractères = 10 bytes en ISO, 12 en UTF
et l'import garde la même structure VARCHAR2(10 BYTES) => VARCHAR2(10 BYTES), et ce quelque soit le NLS_LENGTH_SEMANTICS

[EDIT]
le plus simple et le plus propre serait sûrement de migrer la base de 8i en 9i (par upgrade) puis ensuite, de changer le CS
[/EDIT]

Je n'ai pas la possibilité de créer les tables car il s'agit d'un migration oracle application 11.0.3 vers oracle e-business 11.5.10. Le shema de données sur la base cible est créé par l'installation standard (rapidwiz).
02/05/2007, 13h05
LeoAnderson

si vous faites un import qui créé les tables, je ne vois pas en quoi vous ne pouvez pas créer les tables à la main ?!
02/05/2007, 14h21
ljoly

Citation:

Envoyé par LeoAnderson

oui, c'est une classique.
vous devez créer les tables avec le NLS_LENGTH_SEMANTICS correctement positionné (i.e. CHAR) ou spécifier CHAR dans la définition des colonnes VARCHAR2 puis, ensuite, importer le dump IGNORE=Y ROWS=Y

C'est lié à la structure UTF
Téléphones= 10 caractères = 10 bytes en ISO, 12 en UTF
et l'import garde la même structure VARCHAR2(10 BYTES) => VARCHAR2(10 BYTES), et ce quelque soit le NLS_LENGTH_SEMANTICS

[EDIT]
le plus simple et le plus propre serait sûrement de migrer la base de 8i en 9i (par upgrade) puis ensuite, de changer le CS
[/EDIT]

Je viens d'essayer, ça ne fonctionne pas, j'ai le même message d'erreur.
02/05/2007, 17h40
ljoly

En effectuant la commande

Code:

alter database character set internal_use UTF8;

sur la base 8.1.7.4 en WE8ISO8859P1, puis en faisant un export et un import sur la base cible, ça fonctionne et je retrouve tous mes caractères spéciaux. Ca parait un peu simple?
02/05/2007, 19h14
LeoAnderson

Allez-y ! essayez tout et ensuite, à nous de réfléchir ? :roll:

je vous avais conseillé de créer les tables, pas de les importer :

Code:

CREATE TABLE ...
03/05/2007, 08h52
ljoly

Citation:

Envoyé par LeoAnderson

Allez-y ! essayez tout et ensuite, à nous de réfléchir ? :roll:

je vous avais conseillé de créer les tables, pas de les importer :

Code:

CREATE TABLE ...

il s'agit d'une base e-business 8, càd plusieurs centaines de tables, ça serait trop long à recréer les tables une par une.
03/05/2007, 14h32
ljoly

Citation:

Envoyé par ljoly

En effectuant la commande

Code:

alter database character set internal_use UTF8;

sur la base 8.1.7.4 en WE8ISO8859P1, puis en faisant un export et un import sur la base cible, ça fonctionne et je retrouve tous mes caractères spéciaux. Ca parait un peu simple?

Qui peut me dire ce que fait exactement le alter database?
Dans metalink on me conseille d'effectuer également un csscan avant, A quoi ça sert? ça génére juste un report avec les lignes non convertibles ou tronqués?
03/05/2007, 17h18
pifor

Les commandes ALTER DATABASE SET CHARACTER USE ou ALTER DATABASE SET CHARACTER INTERNAL_USE ne font pas de conversion des colonnes contenant des caractères mais change le jeu de caractères déclaré de la base d'après la note Metalink 66320.1.

CSSCAN permet de vérifier que les données existantes seront bien reconnues dans le nouveau jeu de caractères: il ne doit signaler que des données ChangeLess sinon il y aura incohérence entre le jeu de caractères déclaré de la base et les données de la base :aie:
03/05/2007, 17h33
ljoly

Citation:

Envoyé par pifor

Les commandes ALTER DATABASE SET CHARACTER USE ou ALTER DATABASE SET CHARACTER INTERNAL_USE ne font pas de conversion des colonnes contenant des caractères mais change le jeu de caractères déclaré de la base d'après la note Metalink 66320.1.

CSSCAN permet de vérifier que les données existantes seront bien reconnues dans le nouveau jeu de caractères: il ne doit signaler que des données ChangeLess sinon il y aura incohérence entre le jeu de caractères déclaré de la base et les données de la base :aie:

Je n'ai que des 'convertible', 'lossy conversion', 'exceed column size'. Connaissez-vous la signification ces valeurs? et les conséquences sur la base de donnée convertie
03/05/2007, 17h54
pifor

convertible: peut être converti uniquement par export/import.
lossy: ne peut être converti par aucun moyen.
exceed column size: les données seront tronquées s'il y a conversion, car la colonne est trop petite (les nouveaux caractères prennent au moins 2 octets au lieu d'un seul).
03/05/2007, 18h05
LeoAnderson

Citation:

Envoyé par pifor

convertible: peut être converti uniquement par export/import.
lossy: ne peut être converti par aucun moyen.
exceed column size: les données seront tronquées s'il y a conversion, car la colonne est trop petite (les nouveaux caractères prennent au moins 2 octets au lieu d'un seul).

en d'autres termes et vu que vous avez déjà effectué l'alter database, vous avez pourri vos données ! :roll:
04/05/2007, 10h44
ljoly

heureusement c'était sur une base de test...
04/05/2007, 10h46
ljoly

merci pour les infos
25/05/2007, 11h24
ljoly

Je ne comprends pas, j'ai effectué un scscan, qui m'a renvoyé juste un pb de 'exceed column size', après conversion par 'alter database character set internal_use UTF8' , j'ai des caractères spéciaux qui sont remplacés par des ?. Y a t'il un paramétrage à effectuer (dans la base ou sur le client) afin qu'ils s'affichent correctement.
25/05/2007, 13h05
LeoAnderson

oui, vous devez positionner le NLS_LANG sur le client afin de dire quel jeu de caractères vous souhaitez utiliser.

Si vous choisissez un jeu qui ne contient pas certains des caractères stockés, vous aurez des ? ou des points d'interrogations inversés à la place.
29/05/2007, 17h03
ljoly
J'ai quelque chose de bizarre, pour une même requête

sur sqlplus sous windows avec NLS_LANG = AMERICAN_AMERICA.UTF8, j'ai
Code:

1 2 3 ITEM_DESCRIPTION -------------------------------------------------------------------------------- Schlï¿½ssel Nr. 2H 0418 fï¿½r Taschenbox
sur sqlplus sous unix avec NLS_LANG = American_America.UTF8
Code:

1 2 3 ITEM_DESCRIPTION -------------------------------------------------------------------------------- Schlüssel Nr. 2H 0418 für Taschenbox
Y a t'il quelque chose d'autre à configurer au niveau du client oracle ou au niveau du listener?
30/05/2007, 10h18
pifor

Essayez avec NLS_LANG = AMERICAN_AMERICA.WE8MSWIN1252 et le client sqlplus graphique (sqlplusw.exe) ou Toad ou SQL Developper.
30/05/2007, 10h23
LeoAnderson

le problème est que Oracle ne peut pas faire mieux que le système.

Il est probable que sous windows l'UTF soit mal géré, notamment sur un vieux Windows et/ou que le SQL*Plus graphique (qui est à éviter à tout prix !) en soit lui-même incapable !

Ce n'est pas Oracle qui ne fonctionne pas, c'est le programme client et/ou l'OS.
Essayez sous SQL*Plus en mode texte.

Voir 40 message(s) de cette discussion en une page