Мне надо выполнить гетерогенную копию системы SAP Entr. 4.7 200 SR1 с платформы WIN на HPIA64, база данных 9.*
На этапе экспорта с помощью R3load возникли сложности с таблицей UMG_TEST_C (фрагмент лога SAPCLUST.log прилагаю). Изучил кучу нот на эту тему, в том числе:

722638 R3trans: GetDBMigrateCodePagesLangs fails (the same error!!)
788942 R3load-Export from Unicode system fails
718329 R3load terminates the export during a Unicode conve
494213 R3load reports errors with shared memory or NameTab

разумеется выкачал последнюю версию R3load и R3trans - ничего не помогает.

p.s. процедуру гомогенного/гетерогенного копирования разных продуктов SAP я выполнял много раз, но только не под UNICODE...

(DB) INFO: connected to DB
(DB) INFO: DbSlControl(DBSL_CMD_NLS_CHARACTERSET_GET): UTF8
(GSI) INFO: dbname = "DEV20041015021057 "
(GSI) INFO: vname = "ORACLE "
(GSI) INFO: hostname = "SAP "
(GSI) INFO: sysname = "Windows NT"
(GSI) INFO: nodename = "SAP"
(GSI) INFO: release = "5.2"
(GSI) INFO: version = "3790 "
(GSI) INFO: machine = "4x Intel 801586 (Mod 2 Step 7)"

Mon Feb 07 18:11:48 2005
MtxInit: 0 0 0
(GSI) INFO: instno = "0020144318"
myCluster (3.9.Exp): 649: error when retrieving alternate nametab description for physical table UMG_TEST_C.
myCluster (3.9.Exp): 650: return code received from nametab is 32
myCluster (3.9.Exp): 296: error when retrieving physical nametab for table UMG_TEST_C.
(CNV) ERROR: code page conversion failed
rc = 2


.------------------------------============----------------------------.

| RSCP - Error |

`----------------------------------------------------------------------'

Поимел много гемора с гомогенным копированием юникодовой системы с HP-UX64 (IA или RA-RISC все равно) на Win2000. Есть один тонкий момент, который ни где не описывается. От САПа на тот момент ничего добится не удалось, но в результате получил благодарность и обещания внести коррективы в инсталлейшн гайд.
Короче (в твоем случае),
при экспорте БД указываешь:
Data file codepage - 4103 (по умолчанию - 1100, что приводит к генерации огромного по объему количества XML-файлов)
4103 = используемой на Виндах DB Codepage (UTF-16LE)

Потом при импорте говоришь (я уже точно не помню, но):
DB Codepage 4102 (что и предлагается по умолчанию - это нормально и соответствует используемой на Юниксе UTF-16BE)
Data file codepage 4103 (возможно и не спрашивается, давно это было...)

В общем из-за неправильной Codepage может возникнуть (проверено на собственном опыте) масса совершенно необъяснимых ошибок на стадии R3load и даже после нее, потому что в базе на самом деле - мусор !

Удачи !

Да, в твоем случае просто пытается сконвертировать кластерную таблицу, у которой нет кода языка в неюникод 1100. Указав кодовую страницу целевого файла 4103 мы избегаем ненужной конвертации...

Удачи еще раз !

В принципе со "старым" R3load так оно и было, но вчера я выкачал его самую новейшую версию, ты же видишь лог соединения с базой:

DB) INFO: connected to DB
(DB) INFO: DbSlControl(DBSL_CMD_NLS_CHARACTERSET_GET): UTF8
(GSI) INFO: dbname = "DEV20041015021057 "
(GSI) INFO: vname = "ORACLE "

Но тем не менее я также подозреваю, что выгрузка несмотря на это производится все-таки в 1100. Т.к. есть транзакция SPUMG, где на закладке "Export Control" везде фигурирует 1100. Самое интересное заключается в том, что кластера UMG_TEST_C просто нет в списке "Consistenty Check" - похоже его забыли добавить в таблицу UMGSETTING.

А как переключить R3load в режим обработки DB Codepage 4102?

DB File Codepage выбирается в диалоге Экспорта на сколько я помню...
Кстати не 4102, а 4103 в твоем случае. Это важно !

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

А почему надо выбирать 4103, а не 4102?

Я точно не помню, но кажется в системе приемнике(HPIA64) по умолчанию стоит 4102...

Кодовая страница 4103 - используется в Виндах, 4102 - на Юниксе.
Возможно ты и прав, и можно указать 4102 во время экспотра. Я рассказывал как делал я и это 100% работало.
На самом деле конвертация 4102 -> 4103 или наоборот все таки происходит, но она очень "незначительная", если можно так выразиться. В моем случае она выполняется на стадии импорта...
Если есть желание - можешь поэксперементировать

Спасибо, проблема рассосалась. Если что готов поделиться опытом.