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

11

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
serveur d'importation de jeu de caractères AL16UTF16 NCHAR utilise le jeu de caractères AL32UTF8 (conversion de jeu de caractères possible)

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

Éditer:

É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.

oracle import bernd_k
la source

Réponses:

8

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 espace 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, changer le NLS_LENGTH_SEMANTICSprobablement ne sera pas terriblement utile si vous comptez sur le processus d'importation pour créer la table - le fichier de vidage ajoutera intrinsèquement le mot-clé CHAR ou BYTE afin qu'il émette réellement l'instruction

CREATE TABLE BDATA.Artikel(
    Key                   VARCHAR2(3 BYTE)  NOT NULL,
    Name                  VARCHAR2(60 BYTE) NOT NULL,
    Abkuerzung            VARCHAR2(5 BYTE)  NOT NULL
);
Justin Cave
la source
J'ai le script create table et je peux le modifier selon votre proposition. Si imp fonctionne alors que les tables sont déjà créées, tout irait bien.
bernd_k
@bernd_k - Cool. Ensuite, vous pouvez soit définir NLS_LENGTH_SEMANTICS avant d'exécuter le DDL, soit modifier le DDL pour ajouter CHAR à chaque déclaration de colonne VARCHAR2. Lorsque vous effectuez l'importation, vous n'aurez qu'à lui dire d'ignorer l'échec des instructions CREATE TABLE car les tables existent déjà.
Justin Cave
J'ai changé ma définition de table ... VARCHAR2 (60 CHAR) NOT NULL ... et utilisé IMP avec IGNORE = Y et l'importation s'est terminée avec succès avec des avertissements.
bernd_k
4

Vous n'avez pas le choix de jeu de caractères sur XE , vous ne pouvez donc pas le modifier 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

Jack dit d'essayer topanswers.xyz
la source
Voir mon montage. Mon seul espoir est de créer d'abord les tables avec une largeur étendue et ensuite d'importer les données en ignorant les tables de création à partir de l'importation.
bernd_k
utilisez-vous impdp? voir ici pour savoir comment
Jack dit d'essayer topanswers.xyz
pas encore, mais peut-être un bon moment pour apprendre.
bernd_k
mais notez que impdp ne peut être utilisé qu'avec les exportations créées avec expdp
Jack dit essayez topanswers.xyz
2

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

Walter Colchado
la source
0

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

imp u/p@db file=data.dmp

Essayez quelque chose comme ça dans bash:

imp u/p@db file=<(perl -pe'/^CREATE TABLE/&&s/(VARCHAR2\(\d+)\)/$1 CHAR)/g' data.dmp)

Ceci change tout col1 VARCHAR2(n)à col1 VARCHAR2(n CHAR)en lignes commençant par CREATE TABLE. Vous pouvez également changer data.dmpavant d'exécuter imp sur celui-ci, si vous ne pouvez pas <(...)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.

Kjetil S.
la source