Migration Oracle8 => Oracle9 : conversion characters set

Bonjour,

J'ai une base oracle 8 qui a le jeu de caractères WE8ISO8859, et je veux la migrer sur une base oracle 9i qui doit avoir le jeu de caractères AL32UTF8, et ces 2 bases sont sur 2 machines différentes sans connexion entre elles.

La seule facon que je connaisse de faire cette migration c'est avec les dumps. (imp/exp)
J'exporte la base 8 que je réimporte dans la base 9.
le problème du dump c'est que quand on exporte, on exporte aussi le jeu de caractères avec.
Donc pas moyen de faire une conversion lors de l'import.

Je voudrais donc savoir comment, à partir de ma base 8 WE8ISO8859, migrer vers une base 9 AL32UTF8.

Merci beaucoup pour vos réponses.
(PS : comment vérifier le jeu de caractères sur ma base 9?)

D'après la doc. Utilities Oracle 9, je comprends que l'import va réaliser les conversions nécessaires:

Citation:

Character Set and Globalization Support Considerations
This section describes the character set conversions that can take place during export and import operations.

Character Set Conversion
The following sections describe character conversion as it applies to user data and DDL.

User Data
Data of datatypes CHAR, VARCHAR2, NCHAR, NVARCHAR2, CLOB, and NCLOB are written to the export file directly in the character sets of the source database. If the character sets of the source database are different than the character sets of the import database, a single conversion is performed.

Data Definition Language (DDL)
Up to three character set conversions may be required for DDL during an export/import operation:

1. Export writes export files using the character set specified in the NLS_LANG environment variable for the user session. A character set conversion is performed if the value of NLS_LANG differs from the database character set.
2. If the export file's character set is different than the Import user session character set, then Import converts the character set to its user session character set. Import can only perform this conversion for single-byte character sets. This means that for multibyte character sets, the import file's character set must be identical to the export file's character set.
3. A final character set conversion may be performed if the target database's character set is different from Import's user session character set.

To minimize data loss due to character set conversions, ensure that the export database, the export user session, the import user session, and the import database all use the same character set.

Import and Single-Byte Character Sets
Some 8-bit characters can be lost (that is, converted to 7-bit equivalents) when you import an 8-bit character set export file. This occurs if the system on which the import occurs has a native 7-bit character set, or the NLS_LANG operating system environment variable is set to a 7-bit character set. Most often, this is apparent when accented characters lose the accent mark.

To avoid this unwanted conversion, you can set the NLS_LANG operating system environment variable to be that of the export file character set.

When importing an Oracle version 5 or 6 export file with a character set different from that of the native operating system or the setting for NLS_LANG, you must set the CHARSET import parameter to specify the character set of the export file.

Import and Multibyte Character Sets
During character set conversion, any characters in the export file that have no equivalent in the target character set are replaced with a default character. (The default character is defined by the target character set.) To guarantee 100% conversion, the target character set must be a superset (or equivalent) of the source character set.

PS: Le jeu de caractères de la base est retourné par:
Code:

1 2 select * from v$nls_parameters where parameter = 'NLS_CHARACTERSET';

Citation:
Envoyé par pifor
PS: Le jeu de caractères de la base est retourné par:
Code:

1 2 select * from v$nls_parameters where parameter = 'NLS_CHARACTERSET';
Merci.

Je confirme bien que le jeu utilisé par la base 9 est AL32UTF8.
Mais lorsque j'ai fais l'import de la base8 vers la 9, la conversion ne s'est pas faite automatiquement.

Pouvez-vous

1. nous donner un exemple qui montre que la conversion ne s'est pas faite en donnant votre environnement NLS avec

Code:

select * from nls_session_parameter

2. nous dire quel était l'environnement NLS au niveau système lors de l'import ? = valeur de la variable environnement NLS_LANG

Citation:

Envoyé par pifor

Pouvez-vous

1. nous donner un exemple qui montre que la conversion ne s'est pas faite en donnant votre environnement NLS avec

Code:

select * from nls_session_parameter

2. nous dire quel était l'environnement NLS au niveau système lors de l'import ? = valeur de la variable environnement NLS_LANG

Pour le point 1 apparemment il manque un 's' à la fin du nom de ta table :

PARAMETER VALUE
------------------------------------------------------------------------------------------------------------------------ ----------------------------------------------------------------------------------------------------------------------------------------------------------------
NLS_LANGUAGE FRENCH
NLS_TERRITORY FRANCE
NLS_CURRENCY €
NLS_ISO_CURRENCY FRANCE
NLS_NUMERIC_CHARACTERS ,.
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD/MM/RR
NLS_DATE_LANGUAGE FRENCH
NLS_SORT FRENCH
NLS_TIME_FORMAT HH24:MI:SSXFF
NLS_TIMESTAMP_FORMAT DD/MM/RR HH24:MI:SSXFF
NLS_TIME_TZ_FORMAT HH24:MI:SSXFF TZR
NLS_TIMESTAMP_TZ_FORMAT DD/MM/RR HH24:MI:SSXFF TZR
NLS_DUAL_CURRENCY €
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CONV_EXCP FALSE

17 rows selected.

Pour le point 2 comment puis-je connaitre l'environnement NLS au niveau système lors de l'import?

:oops: En effet, essayez plutôt:

Code:

select * from nls_session_parameters;

Pour 2)
sous UNIX, c'est le contenu de la variable d'environnement NLS_LANG.
sous Windows, c'est dans les registres ...
et il faut exécuter

Code:

@.[%NLS_LANG%]

depuis sqlplus pour avoir la valeur.

Pour 2 :

NLS_LANG = FRENCH_FRANCE.WE8MSWIN1252

Le character set de la base est différent de celui de l'environnement, c'est normal?
Ca ne pose pas de problème?

L'export et l'import ont-t-ils étaits fait depuis Windows ?
La base de l'import est sous Unix ?

Je me permets d'insister: pouvez-vous donner un exemple qui montre que selon vous la conversion ne s'est pas faite ? Je voudrais juste être sûr qu'il ne s'agit pas juste d'un problème d'"environnement" alors que les données seraient correctement converties dans la base...

Citation:

Envoyé par pifor

L'export et l'import ont-t-ils étaits fait depuis Windows ?
La base de l'import est sous Unix ?

Je me permets d'insister: pouvez-vous donner un exemple qui montre que selon vous la conversion ne s'est pas faite ? Je voudrais juste être sûr qu'il ne s'agit pas juste d'un problème d'"environnement" alors que les données seraient correctement converties dans la base...

export et import ont été fait depuis windows et la base etait sous windows.
Je ne sais pas comment vous donner un exemple, mais si vous considerez que c'est un problème d'environnement, alors comment le régler?

Au cas où ca peut vous aider :
NLS_LANG = AMERICAN_AMERICA.WE8ISO8859P1 sur la machine ou se trouve la base 8

Je vous propose le test suivant. Exécutez le code suivant sur votre base source dans un nouveau schéma pour ne rien casser:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 drop table cars; create table cars ( code INTEGER, car VARCHAR2(10) ); create or replace procedure init_cars is begin for i in 0..255 loop insert into cars values (i, chr(i)); end loop; commit; end; / exec init_cars;
Et:
1. Exporter la table cars de la même façon que vous avez exporté votre base source.
2. Importer la table cars de la même façon que vous avez importé votre base source dans votre base cible (même options, même valeur de NLS_LANG)
3. Vérifier les points suivants:
- y-a-t-il erreur à l'import (normalement vous avez un warning qui vous prévient que l'import va faire la conversion mais c'est un warning et non une erreur)
- comparer les données affichées dans les 2 cas par
Code:

1 2 select * from cars
en prenant bien soin de positionner NLS_LANG tel qu'il est utilisé par vos applications.
S'il n'y a ni erreur, ni différence d'affichage, cela signifie que toutes les colonnes de type VARCHAR2 sont bien converties.

Pour être exhaustif, il faudrait faire le même test avec CHAR, NCHAR, NVARCHAR2 et CLOB s'ils sont utilisés par votre base.

D'un autre côté, vous dites

Citation:

Je ne sais pas comment vous donner un exemple

que la conversion n'a pas fonctionné. Comment le savez-vous alors ? Y-a-t-il des caractères correctement affichés par le système source et qui ne le sont pas par le système cible ?

Citation:

Envoyé par pifor

D'un autre côté, vous dites

Citation:

Envoyé par ieb

Je ne sais pas comment vous donner un exemple

que la conversion n'a pas fonctionné. Comment le savez-vous alors ? Y-a-t-il des caractères correctement affichés par le système source et qui ne le sont pas par le système cible ?

Le signe € ne s'affiche pas par exemple, j'ai un petit carré à la place

Quelles sont les valeurs de NLS_LANG au niveau OS sur l'ancienne application et sur la nouvelle application ?
Pouvez-vous nous confimer que € est correctement affiché par l'ancienne application et pas par la nouvelle application ?
L'application c'est du client/serveur ou du 3/tiers ?

Je rajoute une précision essentielle. La note Metalink Euro Symbol Turns up as Upside-Down Questionmark Doc ID: Note:252352.1 explique très clairement pourquoi '€' était correctement affiché avec NLS_LANG utilisant WE8ISO8859P1 et une base définie avec WE8ISO8859P1 et pourquoi cela ne marche plus avec un autre jeu de caractères comme WE8MSWIN1252. Le raison en est que WE8ISO8859P1 ne définit pas le caractère '€' mais que si le jeu de caractères de NLS_LANG correspond à celui de la base alors les code des caractères sont stockés tels qu'ils sont définis par l'OS client. Ca "marche" mais dès qu'on modifie NLS_LANG ou le jeu de caractères de la base ça ne marche plus.

Citation:

Envoyé par pifor

Quelles sont les valeurs de NLS_LANG au niveau OS sur l'ancienne application et sur la nouvelle application ?
Pouvez-vous nous confimer que € est correctement affiché par l'ancienne application et pas par la nouvelle application ?
L'application c'est du client/serveur ou du 3/tiers ?

NLS_LANG = AMERICAN_AMERICA.WE8ISO8859P1 sur la machine ou se trouve la base 8 (ancienne machine)
==>€ correctement affiché

NLS_LANG = FRENCH_FRANCE.WE8MSWIN1252 sur la machine ou se trouve la base 9 (nouvelle machine)
==>le signe € ne s'affiche pas, il y a un carré à la place

L'application est une application web, client/server.

D'après la note de Metalink, je ne vois pas de solution simple à votre problème car le caractère euro n'est pas correctement stocké par le jeu de caractères source et ne peut donc être correctement traduit par
les outils import/export.

Une solution possible consiste à écrire un programme qui analyserait dans la base cible toutes vos données caractères en testant avec la fonction DUMP le code traduit par l'import du caractère euro et le remplacerait par la bonne valeur dans le jeu de caractère cible.