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

11

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?

Edytować:

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.

oracle import bernd_k
źródło

Odpowiedzi:

8

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ć na tylko 1 znak ).

Niestety, zmiana NLS_LENGTH_SEMANTICSprawdopodobnie nie będzie strasznie pomocna, 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
);
Justin Cave
źródło
Mam skrypt tworzenia tabeli i mogę go zmodyfikować zgodnie z twoją propozycją. Jeśli imp działa, gdy tabele są już utworzone, wszystko byłoby w porządku.
bernd_k
@bernd_k - Cool. Następnie możesz ustawić NLS_LENGTH_SEMANTICS przed uruchomieniem DDL lub zmodyfikować DDL, aby dodać CHAR do każdej deklaracji kolumny VARCHAR2. Podczas importowania musisz po prostu powiedzieć mu, aby zignorował błąd instrukcji CREATE TABLE, ponieważ tabele już istnieją.
Justin Cave
Zmieniłem definicję tabeli ... VARCHAR2 (60 CHAR) NOT NULL ... i użyłem IMP z IGNORE = Y i import został pomyślnie zakończony z ostrzeżeniami.
bernd_k
4

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 praktyczna byłaby migracja źródłowej bazy 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 teoretycznie ). Może być konieczne zwiększenie rozmiaru kolumny przed eksportem lub dostosowanie schematu docelowego i zaimportowanie danych w osobnym kroku. Zobacz tutaj inne możliwe problemy z obcinaniem danych

Jack mówi, że spróbuj topanswers.xyz
źródło
Zobacz moją edycję. Mam tylko nadzieję, że najpierw utworzę tabele o rozszerzonej szerokości, a następnie zaimportuję dane, ignorując tworzenie tabel z importu.
bernd_k
używasz impdp? zobacz tutaj jak
Jack mówi, spróbuj wypróbować topanswers.xyz
jeszcze nie, ale być może dobry moment na naukę.
bernd_k
ale zauważ, że impdp może być używany tylko z eksportami utworzonymi za pomocą expdp
Jack mówi, że spróbuj topanswers.xyz
2

Najłatwiejszy sposób: (Niezbędne zamknięcie) :

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

Walter Colchado
źródło
0

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

imp u/p@db file=data.dmp

Wypróbuj coś takiego w bash:

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

Zmienia się co col1 VARCHAR2(n)do col1 VARCHAR2(n CHAR)linii począwszy od CREATE TABLE. Możesz także zmienić data.dmpprzed uruchomieniem imp, jeśli nie <(...)możesz na przykład w swojej powłoce:

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 stwierdził -i.bk.

Kjetil S.
źródło