imp/exp -> неправильная конвертация

Перетаскиваю данные из 9ки в 10g.
Проблема в том, что теряется при конвертации правильное отображение
русских символов.

заголовок логов imp

Connected to: Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production JServer Release 9.2.0.4.0 - Production Export done in CL8MSWIN1251 character set and AL16UTF16 NCHAR character set server uses US7ASCII character set (possible charset conversion)

т.е. изначально БД создавалась с character set us7ascii :(, но реально использовалаь unix-кодировка.

заголовок логов exp

Соединен с: Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Production With the Partitioning, OLAP and Data Mining options Экспоpт-файл создан EXPORT:V09.02.00 чеpез пpямой маpшpут импорт выполнен в кодировке CL8MSWIN1251 и AL16UTF16 кодировке NCHAR

во второй БД, куда проходит импорт все кириллические символы видны как '???...' (симолы вопросит.знака).

пробовал
1. при импорте пробовал в NLS_LANG поставить "RUSSIAN_CIS.CL8MSWIN1251"
2. следую инструкции http://www.utexas.edu/its/unix/reference/oracledocs/v92/B10501_01/server.920/a96529/ch10.htm сделать ALTER DATABASE CHARACTER SET RUSSIAN_CIS.CL8MSWIN1251 в базе-приемнике
- результат все такой же...

где моя ошибка?

Wireless

пробовал 1. при импорте пробовал в NLS_LANG поставить "RUSSIAN_CIS.CL8MSWIN1251" 2. следую инструкции http://www.utexas.edu/its/unix/reference/oracledocs/v92/B10501_01/server.920/a96529/ch10.htm сделать ALTER DATABASE CHARACTER SET RUSSIAN_CIS.CL8MSWIN1251 в базе-приемнике - результат все такой же... где моя ошибка?

Ошибка в том, что Вам следует избежать преобразования charset при экспорте. Сделайте экспорт в кодировке US7ASCII, при импорте укажите корректную для данных "unix-кодировку".

andrey_anonymous

Ошибка в том, что Вам следует избежать преобразования charset при экспорте. Сделайте экспорт в кодировке US7ASCII, при импорте укажите корректную для данных "unix-кодировку".

попробовал эксортировать в US7ASCII,

автор

Connected to: Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production JServer Release 9.2.0.4.0 - Production Export done in US7ASCII character set and AL16UTF16 NCHAR character set

результат тот же - вопросики во второй базе после импорта.
думаю все дело как раз us7ascii - старший бит видимо отрезается в какой-то момент. как это можно победить?

Wireless

а) что значит "но реально использовалаь unix-кодировка." ?
koi8-r ?

б)
- попробуй создать в базе приемнике просто структуру таблиц (схемы)
IMP ROWS=N CONSTRAINTS=N

- перенеси данные каким либо иным способом, к примеру, через SQL*Loader, external tables или database link

- восстанови схему полностью
IMP ROWS=N CONSTRAINTS=Y IGNORE=Y

в) можно попробовать поправить базу источник (естественно, копию)
ALTER DATABASE CHARACTER SET RUSSIAN_CIS.CL8MSWIN1251

только не CL8MSWIN1251, а именно ту кодировку, в которой реально хранятся данные.

Wireless

попробовал эксортировать в US7ASCII, автор Connected to: Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production JServer Release 9.2.0.4.0 - Production Export done in US7ASCII character set and AL16UTF16 NCHAR character set результат тот же - вопросики во второй базе после импорта.

Вы в дампик-то глазами гляньте... Какую кодировку указываете при импорте? А в дампике какая?
Символы не обрезаются.
Есть данные в БД, пусть в кодировке Х.
Есть клиент, который желает работать в кодировке Y.
При этом oracle автоматически производит преобразование X<->Y.
Преобразование задается таблично.
Если для какого-то кода исходного characterset нет соответствия в целевом - символ заменяется "вопросиком".
Лазейка только одна - при совпадении characterset БД и кодировки, объявленной клиентом преобразование не производится (типа оптимизация), что и позволяло сохранять нац. символы в БД US7ASCII.
Соответственно, после экспорта в совпадающей кодировке Вы должны получить дамп, содержащий нац. символы в оригинальной кодировке.
Вот ее, родимую, и надо указывать при импорте - тогда при импорте будет выполнено преобразование, допустим, KOI-8R в WIN1251 и Вы увидите свои данные в "нормальном" виде.

grexhide

а) что значит "но реально использовалаь unix-кодировка." ? koi8-r ?

да, именно KOI8-R

grexhide

б) - попробуй создать в базе приемнике просто структуру таблиц (схемы) IMP ROWS=N CONSTRAINTS=N - перенеси данные каким либо иным способом, к примеру, через SQL*Loader, external tables или database link - восстанови схему полностью IMP ROWS=N CONSTRAINTS=Y IGNORE=Y

спасибо за вариант, но кажется не рационально - зачем imp/exp тогда вообще? ;) попробую как последнее лекарство, таблиц очень много

grexhide

в) можно попробовать поправить базу источник (естественно, копию) ALTER DATABASE CHARACTER SET RUSSIAN_CIS.CL8MSWIN1251 только не CL8MSWIN1251, а именно ту кодировку, в которой реально хранятся данные.

очень дельный вариант. только вот копию бд развернуть - тоже целое дело... :-/
а можно как-то сделать

ALTER DATABASE CHARACTER SET RUSSIAN_CIS.CL8KOI8R

с каким-нибудь ключиком, чтобы в контрол-файле поменялась только информация о кодировке, а при этом реально данные таблиц не апдейтились? если "да"-можно, тогда думаю можно и на живой БД это провернуть.

andrey_anonymous

Wireless попробовал эксортировать в US7ASCII, результат тот же - вопросики во второй базе после импорта. Вы в дампик-то глазами гляньте... Какую кодировку указываете при импорте? А в дампике какая?

Глянул:) Реально в бинарном дампе самый что не есть KOI8-R...
При импорте что только не пробовал указывать в переменной окружения NLS_LANG, по вашему рецепту в последний раз

export NLS_LANG=RUSSIAN_CIS.CL8KOI8R

получил

автор

Экспоpт-файл создан EXPORT:V09.02.00 чеpез пpямой маpшpут импорт выполнен в кодировке CL8KOI8R и AL16UTF16 кодировке NCHAR импортирующий сервер использует кодировку CL8MSWIN1251 (возможно перекодирование) экспортирующий клиент использует кодировку US7ASCII (возможно перекодирование)

результат опять тот же самый :(
Может в базе, в которую экспорт тоже сделать alter database character set US7ASCII и везде переменные окружения такие же выставить, тогда может перекодирования не будет?

andrey_anonymous

... Если для какого-то кода исходного characterset нет соответствия в целевом - символ заменяется "вопросиком". Лазейка только одна - при совпадении characterset БД и кодировки, объявленной клиентом преобразование не производится (типа оптимизация), что и позволяло сохранять нац. символы в БД US7ASCII. Соответственно, после экспорта в совпадающей кодировке Вы должны получить дамп, содержащий нац. символы в оригинальной кодировке. Вот ее, родимую, и надо указывать при импорте

Пробовал только что сделать это - результат см. выше

andrey_anonymous

- тогда при импорте будет выполнено преобразование, допустим, KOI-8R в WIN1251 и Вы увидите свои данные в "нормальном" виде.

преобразование какое-то кривое получилось, опять вопросики...

andrey_anonymous

При этом oracle автоматически производит преобразование X<->Y.

Начиная с 9i при экспорте перекодировка пользовательских данных не выполняется. Note 15095.1

andrey_anonymous

Вот ее, родимую, и надо указывать при импорте - тогда при импорте будет выполнено преобразование, допустим, KOI-8R в WIN1251 и Вы увидите свои данные в "нормальном" виде.

На 99.99% не поможет. Кодировка прописывается в экспортном файле (вроде как) для каждого столбца типа char/varchar2 etc.

На 99.9999999% поможет следующее:

1. На всякий случай полный бэкап базы.
2.
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER SYSTEM ENABLE RESTRICTED SESSION;
ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;
ALTER SYSTEM SET AQ_TM_PROCESSES=0;
ALTER DATABASE OPEN;
ALTER DATABASE CHARACTER SET INTERNAL_USE CL8KOI8R;
SHUTDOWN;
STARTUP;

3. Вышеуказанный параметр не совсем документирован, поэтому используется на свой страх и риск ;-)
4. Проверяем alert.log на изменение инфы в упр. файле
5. Можно просто (кому как) хакнуть словарь, но указанная команда проще ;-)
6. Не боись, данные таблиц "апдейтится" не будут :-)

Импорт Экспортович Мигратор

Note 15095.1

Thanks, не знал.
По поводу остального - я имел ввиду попробовать поправить кодировку в дампе.
Хотя самовыразился, надо отметить, более чем криво.

Импорт Экспортович Мигратор

ALTER DATABASE CHARACTER SET INTERNAL_USE CL8KOI8R;

супер! все получилось :-) спасибо