it-swarm-eu.dev

Oracle-Importproblem durch unterschiedliche Zeichensätze

Ich versuche, einen Oracle 11-Export in Oracle 11 XE zu importieren.

Ich erhalte folgende Meldungen:

import in XE Fehlerhaft Import in WE8MSWIN1252 Zeichensatz und AL16UTF16 NCHAR Zeichensatz
Importserver verwendet AL32UTF8-Zeichensatz (mögliche Zeichensatzkonvertierung)

Irgendwelche Ideen, wie ich diesen Dump in Oracle 11 XE importieren kann?

Edit :

Gegeben eine Tabelle

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

Ich bekomme solche Fehler

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ö

Einige Zeilen fehlen beim Import.

11
bernd_k

Wenn dies die tatsächliche DDL ist, die Sie zum Erstellen der Tabelle verwenden, können Sie den Parameter NLS_LENGTH_SEMANTICS verwenden. Wenn Sie dies auf CHAR anstatt auf den Standardwert von BYTE setzen, wird einem VARCHAR2 (5) genügend Speicherplatz zugewiesen, um 5 Zeichen im Datenbankzeichensatz (möglicherweise bis zu 20 Byte) anstatt 5 Bytes (die nur 1 Zeichen zulassen könnten) zu speichern ).

Leider ändert sich das NLS_LENGTH_SEMANTICS ist wahrscheinlich nicht besonders hilfreich, wenn Sie sich beim Erstellen der Tabelle auf den Importprozess verlassen. Die Dump-Datei fügt von Natur aus das Schlüsselwort CHAR oder BYTE hinzu, sodass die Anweisung tatsächlich ausgegeben wird

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

Sie haben in XE keine Auswahl an Zeichensätzen Sie können ihn also nicht an die Datenbank anpassen, die Sie importieren möchten. Wäre es praktisch, die Quellendatenbank vor dem Export zu migrieren ?

Der Import sollte funktionieren, aber die Konvertierung von Zeichensätzen kann bedeuten, dass einige Textspalten mit Nicht-ASCII-Zeichen nach dem Import nicht gleich aussehen. Und Zeilen können abgelehnt werden, wenn sie im neuen Zeichensatz zu lang sind.

In Ihrem Fall konvertieren Sie in UTF8, was bedeutet, dass ein einzelnes Bytezeichen während der Konvertierung in 2 ( oder theoretisch mehr ) wachsen kann. Möglicherweise müssen Sie die Spaltengröße vor dem Export erhöhen oder das Zielschema anpassen und die Daten in einem separaten Schritt importieren. Siehe hier für andere mögliche Probleme beim Abschneiden von Daten

Der einfachste Weg: (Herunterfahren erforderlich) :

Verbinden Sie sich zunächst als sysdba:

sqplus / as sysdba

Führen Sie als Nächstes das folgende Skript aus:

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

Es hat bei mir in einer Oracle 12c Standard Two Edition funktioniert

Entnommen aus: http://www.blogdelpibe.com/2015/05/como-solucionar-el-error-ora-12899.html

2
Walter Colchado

Das hat bei mir funktioniert. An Stelle von:

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

Versuchen Sie so etwas in Bash:

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

Dies ändert jedes col1 VARCHAR2(n) in col1 VARCHAR2(n CHAR) in Zeilen, die mit CREATE TABLE Beginnen. Sie können auch data.dmp Ändern, bevor Sie imp ausführen, wenn Sie nicht in der Lage sind, <(...) in Ihrer Shell zu verwenden, zum Beispiel:

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

... aber es ist nicht notwendig in Bash und etwas könnte bei der Konvertierung oder bei der Sicherung schief gehen, wie in -i.bk angegeben.

0
Kjetil S.