Проблема импорта Oracle, вызванная различными наборами символов

11

Я пытаюсь импортировать экспорт Oracle 11 в Oracle 11 XE.

Я получаю следующие сообщения:

импорт в XE fehlerhaft импорт выполняется в наборе символов WE8MSWIN1252 и сервере импорта набора символов AL16UTF16 NCHAR
использует набор символов AL32UTF8 (возможно преобразование кодировки)

Любые идеи, как я могу импортировать этот дамп в Oracle 11 XE?

Редактировать:

Учитывая стол

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

Я получаю такие ошибки

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ö

Некоторые строки отсутствуют в импорте.

oracle import bernd_k
источник

Ответы:

8

Если это фактический DDL, который вы используете для создания таблицы, вы можете использовать параметр NLS_LENGTH_SEMANTICS . Если вы установите для этого параметра значение CHAR, а не значение по умолчанию BYTE, для VARCHAR2 (5) будет выделено достаточно места для хранения 5 символов в наборе символов базы данных (возможно, до 20 байтов), а не 5 байтов (которые могут содержать только 1 символ). ).

К сожалению, изменение NLS_LENGTH_SEMANTICSвероятно не будет очень полезно, если вы полагаетесь на процесс импорта для создания таблицы - в файл дампа будет добавлено ключевое слово CHAR или BYTE, поэтому он фактически выдаст оператор

CREATE TABLE BDATA.Artikel(
    Key                   VARCHAR2(3 BYTE)  NOT NULL,
    Name                  VARCHAR2(60 BYTE) NOT NULL,
    Abkuerzung            VARCHAR2(5 BYTE)  NOT NULL
);
Джастин Кейв
источник
У меня есть скрипт создания таблицы, и я могу изменить его в соответствии с вашим предложением. Если imp работает, когда таблицы уже созданы, все будет хорошо.
bernd_k
@bernd_k - Круто. Затем вы можете либо установить NLS_LENGTH_SEMANTICS перед запуском DDL, либо изменить DDL, добавив CHAR к каждому объявлению столбца VARCHAR2. Когда вы выполняете импорт, вам просто нужно сказать ему игнорировать сбой операторов CREATE TABLE, так как таблицы уже существуют.
Джастин Кейв
Я изменил определение таблицы ... VARCHAR2 (60 CHAR) NOT NULL ... и использовал IMP с IGNORE = Y, а импорт успешно завершен с предупреждениями.
bernd_k
4

У вас нет выбора набора символов в XE, поэтому вы не можете изменить его в соответствии с базой данных, которую вы пытаетесь импортировать. Было бы целесообразно перенести исходную базу данных перед экспортом?

Импорт должен работать, но преобразование набора символов может означать, что некоторые текстовые столбцы с символами, отличными от ascii, после импорта не будут выглядеть одинаково. И строки могут быть отклонены, если они слишком длинные в новом наборе символов.

В вашем случае вы конвертируете в UTF8, что будет означать, что при преобразовании до 2 ( или более в теории ) возможно увеличение одного байтового символа . Возможно, вам придется увеличить размер столбца перед экспортом или настроить целевую схему и импортировать данные в отдельном шаге. Смотрите здесь для других возможных проблем усечения данных

Джек говорит, попробуйте topanswers.xyz
источник
Смотрите мое редактирование. Моя единственная надежда - сначала создать таблицы с расширенной шириной, а затем импортировать данные, игнорируя создание таблиц из импорта.
bernd_k
вы используете impdp? смотрите здесь, как
Джек говорит попробуйте topanswers.xyz
пока нет, но, возможно, хорошее время, чтобы учиться.
bernd_k
но учтите, что impdp может использоваться только с экспортом, созданным с помощью expdp
Джек говорит, что попробуйте topanswers.xyz
2

Самый простой способ: (отключение необходимо) :

Сначала подключитесь как sysdba:

sqplus / as sysdba

Далее выполните следующий скрипт:

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

У меня это работало в Oracle 12c Standard Two Edition

Взято с: http://www.blogdelpibe.com/2015/05/como-solucionar-el-error-ora-12899.html

Вальтер Кольчадо
источник
0

Это сработало для меня. Вместо этого:

imp u/p@db file=data.dmp

Попробуйте что-то вроде этого в bash:

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

Это меняет каждый col1 VARCHAR2(n)на col1 VARCHAR2(n CHAR)в строках, начинающихся с CREATE TABLE. Вы также можете изменить его data.dmpперед запуском команды imp, если вы не можете включить его <(...)в свою оболочку, например:

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

... но это не обязательно в bash, и что-то может пойти не так при преобразовании или создании резервной копии, как указано в -i.bk.

Кжетил С.
источник