it-swarm-fr.com

Problème d'importation Oracle causé par différents jeux de caractères

J'essaie d'importer une exportation Oracle 11 dans Oracle 11 XE.

Je reçois les messages suivants:

importation dans XE fehlerhaft importation effectuée dans le jeu de caractères WE8MSWIN1252 et le jeu de caractères AL16UTF16 NCHAR
Le serveur d'importation utilise le jeu de caractères AL32UTF8 (conversion possible du jeu de caractères)

Des idées, comment puis-je importer ce vidage dans Oracle 11 XE?

Modifier:

Étant donné une table

CREATE TABLE BDATA.Artikel(
    Key                   VARCHAR2(3)  NOT NULL,
    Name                  VARCHAR2(60) NOT NULL,
    Abkuerzung            VARCHAR2(5)  NOT NULL
);

Je reçois des erreurs comme celle-ci

IMP-00019: row rejected due to Oracle error 12899
IMP-00003: Oracle error 12899 encountered
ORA-12899: value too large for column "BDATA"."ARTIKEL"."ABKUERZUNG" (actual: 6, maximum: 5)
Column 1 ABL
Column 2 Aufbewahrungslösung
Column 3 AfbLö

Certaines lignes sont manquantes lors de l'importation.

11
bernd_k

S'il s'agit du DDL réel que vous utilisez pour créer la table, vous pouvez utiliser le paramètre NLS_LENGTH_SEMANTICS . Si vous définissez cela sur CHAR plutôt que sur la valeur par défaut de BYTE, un VARCHAR2 (5) se verra allouer suffisamment d'espace pour stocker 5 caractères dans le jeu de caractères de la base de données (potentiellement jusqu'à 20 octets) plutôt que 5 octets (ce qui pourrait n'autoriser qu'un seul caractère). ).

Malheureusement, la modification du NLS_LENGTH_SEMANTICS ne sera probablement pas très utile si vous comptez sur le processus d'importation pour créer la table - le fichier de vidage ajoutera de manière inhérente le mot-clé CHAR ou BYTE afin qu'il émette effectivement l'instruction

CREATE TABLE BDATA.Artikel(
    Key                   VARCHAR2(3 BYTE)  NOT NULL,
    Name                  VARCHAR2(60 BYTE) NOT NULL,
    Abkuerzung            VARCHAR2(5 BYTE)  NOT NULL
);
8
Justin Cave

Vous vous n'avez pas le choix de jeu de caractères sur XE vous ne pouvez donc pas le changer pour l'adapter à la base de données que vous essayez d'importer. Serait-il pratique de migrer la base de données source avant l'exportation?

L'importation devrait fonctionner, mais la conversion du jeu de caractères peut signifier que certaines colonnes de texte avec des caractères non ascii ne seront pas identiques après l'importation. Et les lignes peuvent être rejetées si elles sont trop longues dans le nouveau jeu de caractères.

Dans votre cas, vous convertissez en UTF8, ce qui signifie qu'il est possible qu'un caractère à un octet croisse pendant la conversion en 2 ( ou plus en théorie ). Vous devrez peut-être augmenter la taille de la colonne avant d'exporter ou d'ajuster le schéma cible et d'importer les données dans une étape distincte. Voir ici pour d'autres problèmes de troncature de données possibles

La manière la plus simple: (Arrêt nécessaire) :

Tout d'abord, connectez-vous en tant que sysdba:

sqplus / as sysdba

Ensuite, exécutez le script suivant:

alter system set nls_length_semantics=CHAR scope=both;
shutdown;
startup restrict;
alter database character set INTERNAL_USE WE8ISO8859P1;
shutdown;
startup;

Cela a fonctionné pour moi dans une Oracle 12c Standard Two Edition

Tiré de: http://www.blogdelpibe.com/2015/05/como-solucionar-el-error-ora-12899.html

2
Walter Colchado

Cela a fonctionné pour moi. Au lieu de cela:

imp u/[email protected] file=data.dmp

Essayez quelque chose comme ça dans bash:

imp u/[email protected] file=<(Perl -pe'/^CREATE TABLE/&&s/(VARCHAR2\(\d+)\)/$1 CHAR)/g' data.dmp)

Cela change chaque col1 VARCHAR2(n) en col1 VARCHAR2(n CHAR) dans les lignes commençant par CREATE TABLE. Vous pouvez également modifier data.dmp Avant d'exécuter imp sur celui-ci, si vous n'êtes pas en mesure de <(...) dans votre Shell par exemple:

Perl -i.bk -pe'/^CREATE TABLE/&&s/(VARCHAR2\(\d+)\)/$1 CHAR)/g' data.dmp

... mais ce n'est pas nécessaire dans bash et quelque chose pourrait mal tourner dans la conversion ou dans la sauvegarde comme indiqué par -i.bk.

0
Kjetil S.