it-swarm.dev

Problem z importem Oracle spowodowany przez różne zestawy znaków

Próbuję zaimportować eksport Oracle 11 do Oracle 11 XE.

Otrzymuję następujące wiadomości:

import w XE fehlerhaft import wykonany w zestawie znaków WE8MSWIN1252 i zestawie znaków AL16UTF16 NCHAR
serwer importu używa zestawu znaków AL32UTF8 (możliwa konwersja zestawu znaków)

Wszelkie pomysły, w jaki sposób mogę zaimportować ten zrzut do Oracle 11 XE?

Edytuj:

Biorąc pod uwagę stół

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

Mam takie błędy

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ö

W imporcie brakuje niektórych wierszy.

11
bernd_k

Jeśli jest to rzeczywisty DDL, którego używasz do utworzenia tabeli, możesz użyć parametru NLS_LENGTH_SEMANTICS . Jeśli ustawisz CHAR zamiast domyślnej wartości BYTE, VARCHAR2 (5) otrzyma wystarczającą ilość miejsca do przechowywania 5 znaków w zestawie znaków bazy danych (potencjalnie do 20 bajtów) zamiast 5 bajtów (co może pozwolić tylko na 1 znak ).

Niestety zmiana NLS_LENGTH_SEMANTICS prawdopodobnie nie będzie strasznie pomocny, jeśli polegasz na procesie importu, aby utworzyć tabelę - plik zrzutu z natury doda słowo kluczowe CHAR lub BYTE, więc faktycznie wyda instrukcję

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

Ty nie masz wyboru zestawu znaków w XE , więc nie możesz go zmienić, aby pasował do bazy danych, którą próbujesz zaimportować. Czy byłoby praktyczne migracja źródłowa baza danych przed eksportem?

Import powinien działać, ale konwersja zestawu znaków może oznaczać, że niektóre kolumny tekstowe ze znakami nie-ascii nie będą wyglądały tak samo po imporcie. A wiersze można odrzucić, jeśli są zbyt długie w nowym zestawie znaków.

W twoim przypadku konwertujesz na UTF8, co oznacza, że ​​jeden bajt może rosnąć podczas konwersji do 2 ( lub więcej w teorii ). Może być konieczne zwiększenie rozmiaru kolumny przed eksportem lub dostosowanie schematu docelowego i zaimportowanie danych w osobnym kroku. Zobacz tutaj , aby zapoznać się z innymi możliwymi problemami obcięcia danych

Najłatwiejszy sposób: (Niezbędne wyłączenie) :

Najpierw połącz jako sysdba:

sqplus / as sysdba

Następnie uruchom następujący skrypt:

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

To działało dla mnie w wersji Oracle 12c Standard Two Edition

Zaczerpnięte z: http://www.blogdelpibe.com/2015/05/como-solucionar-el-error-ora-12899.html

2
Walter Colchado

To zadziałało dla mnie. Zamiast tego:

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

Wypróbuj coś takiego w bash:

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

Zmienia to co col1 VARCHAR2(n) na col1 VARCHAR2(n CHAR) w wierszach zaczynających się na CREATE TABLE. Możesz także zmienić data.dmp Przed uruchomieniem imp, jeśli nie możesz <(...) w powłoce, na przykład:

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

... ale nie jest to konieczne w bash i coś może pójść nie tak podczas konwersji lub tworzenia kopii zapasowej, jak podano w -i.bk.

0
Kjetil S.