Тормозит Экспорт/Импорт данных

[Vadik]

Цитата:

Сообщение от db

2 vadik: базы ФУНКЦИОНАЛЬНО один в один - никто все таблицы 1 в 1 не копирует. Процесс двухступенчатый - сначала развертывание другой БД с идентичной лицензией и конфигурационными ключами, потом перенос пользовательских данных

Да, это я уже понял. А что, DTS некорректно экспорт делает, если приходится через linked server скриптом данные заливать?

[st_msav]

Цитата:

Сообщение от db

2 st_msav: идеями я делюсь; готовыми средствами, с помощью которых наша компания зарабатывает себе на жизнь - нет.

А я без претензий на эту тему. Наоборот, весьма благодарен за конструктивный ответ.

[sukhanchik]

пусть меня подправит db (если я ошибаюсь, т.к. я такое не делал) - но как я понял из обсуждения - скрипт нужен для того чтобы пробежаться по сделанной таблице соответствий и программно сгенерировать запросы insert into ... select. Ибо DTS-ом - можно - но вручную окучить 2000 таблиц (ну пусть даже в 2 раза меньше) - дольше нежели сделать скрипт, генерирующий скрипт

[glibs]

Цитата:

Сообщение от st_msav

...
при выполнении операции импорта данных система где-то начинает зацикливаться, т.е. резурсы процессора отъедает, а объем БД практически не изменяется.
...

Вот и мне захотелось перелить данные из Oracle на MS SQL... нет, я конечно знал, что тормозит... но чтобы настолько...

проблема возникает с таблицами, для которых включены свойства CreatedTransactionId и ModifiedTransactionId. Например, когда у меня начала заливаться LedgerTrans, то скорость импорта достигла 4-х записей в секунду. При этом ax32.exe отъедает ресурсы процессора.

Я пока остановился на двух вариантах борьбы с проблемой. Вариант №1 — закоментарить в Classes\SysDataImport\importBuffer две следующих строчки кода

this.updateTransactionId(_oldTableId, _oldCreatedTransactionId, _oldModifiedTransactionId);
this.updateTransactionIdReference();

Коментарить нужно в двух местах.

Решение кривое, но быстрое. При импорте после таких модификаций умирает аудит, но для проведения разработки (и тестирования) данные будут вполне вменяемые.

Также я думаю над вариантом №2. Суть в том, чтобы не пересчитывать RecId Created/ModifiedTransId. Т.е. закачать как есть, а потом сдвинуть значения в SystemSequence (зарезервировав правильное количество кодов записей через класс). В общем, он очень похож на решение с MS DTS, но реализуем в Аксапте и снимает некоторые сложности с SqlSystemVariables и именами полей, которые были перечислены выше.

Предварительный эксперимент пока дал положительные результаты. База 1.5 ГБ (файл данных, в MS SQL 2.8 ГБ с индексами получилось) загрузилась в пределах полутора часов на лаптопе (хоть и мощный, но не сервер все таки). Планирую продолжить опыты в будущем.

Преимуществом варианта является то, что его можно параллелить (наиболее крупные таблицы тянуть параллельно, выделив их в отдельную группу), так как RecId не пересчитываются. Также при понимании дела с помощью него можно перенести несколько компаний, которые имеют общие данные в виртуальных компаниях.

Естественно, такой вариант прокатит только в случае, если компани переливается целиком, а в заливаемой компании нет данных. Для объединения двух компаний, например, такой вариант не подойдет. Но для миграции с Oracle на MS SQL (или наоборот), думаю, сможет подойти.

[DmitrySt]

А стандартные Аксаптовские проверки логической целостности данных до (на старом сервере) и после (на новом) запускались? Как результаты?

[glibs]

Не запускались.