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

[st_msav]

Доброго времени суток.

У меня стоит задача перенести БД Axapta 3.0 SP3 с MS SQL Server 2000 на Oracle 9i. Собственно, сложность состоит в том, что при выполнении операции импорта данных система где-то начинает зацикливаться, т.е. резурсы процессора отъедает, а объем БД практически не изменяется. При переносе между двумя БД MS SQL я удалял скриптом все данные из всех пользовательских таблиц и выполнял операцию Экспорта/Импорта средствами самого SQL сервера. С Oracle такой фокус не проходит, поскольку длинные имена таблиц и полей отличаются в наименовании по физической структуре представления БД сервером.

Параметры при создании представления:
- Тип: Стандарт.
- На закладке "Параметры" галочка установлена только на поле "Примечания", все остальные не выбраны.
- На закладке "Включать группы таблиц" отмечены все поля.

База данных не маленькая - 16Гб (без учета размера журнала транзакций, вместе с ним - 85Гб).

Файл экспорта по компании - 1,4Гб.

Параметры импорта данных:
- На закладке "Расширено" отмечены поля "Удаление компании перед импортом", "Резервирование кодов записей". Значение поля "Индексация" - "Переиндексация после импорта".

Импорт шел нормально первые 40 минут, т.е. размер загружаемой БД возрастал, после этого замедлился и за последние сутки вырос всего лишь на 1,2%. За первые 40 минут БД была заполнена на 31%. Такое вялое изменение динамики и наводит на мысль, что система зацикливается. При этом сама Аксапта не зависает - она продолжает реагировать на нажатия клавиш и загружает процессор.

У кого есть какие соображения на эту тему, подскажите пожалуста.

[Roman777]

Встречный вопрос: в оракле пишется журнал транзакций?

[mazzy]

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

Что нужно сделать:
1. Почистить все логи http://axapta.mazzy.ru/lib/dbgrowthsolution/ чтобы при импорте данные логов не анализировались
2. Проанализировать связи по recID. Таблицы, связанные по RecID ОБЯЗАТЕЛЬНО надо испортировать в ОДНОМ пакете. Таблицы, не связанные по recID можно импортировать разными файлами.

Например, LedgerTable, LedgerTableAlternative и LedgerTableInterval могут быть связаны по RecID. Это значит данные этих таблиц должны быть в одном файле.
А вот LedgerTableAlternativeTrans по RecID ни с кем не связана (в стандартном функционале) и на нее никто по recID не ссылается. Это значит LedgerTableAlternativeTrans можно вынести в отдельный файл экспорта/импорта.
И т.д.

Отдельный файл можно сделать создав отдельную группу определения экспорта/импорта и указав в ней только нужные вам таблицы.


Итак, главная ваша проблема - RecID при импорте изменяется и согласованно с ними изменяются ссылки на измененные RecID. При большом объеме импортируемых данных, согласованное изменение ссылок делается долго.

Ваша задача - облегчить работу алгоритму импорта.

[st_msav]

Дело в том, что самые большие логовые таблицы:
PurchParmTable
PurchParmSubTable
PurchParmLine
PurchParmUpdate
SalesParmLine
SalesParmSubTable
SalesParmTable
SalesParmUpdate
InventSumLinkTTS
InventSumLogTTS
я не могу очищать. Они используются для получения довольно хитрых отчетов и они должны остаться в полученной БД. А что касается связанных записей, то я осуществляю Экспорт/Импорт по всем таблицам. Как я выше описал, туда не включены системные и с перекрестными ссылками.

Т.е. из всего вышесказанного следует вывод, что эта грустная ситуация так вот сходу не может быть разрешена???

[mazzy]

Цитата:

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

А что касается связанных записей, то я осуществляю Экспорт/Импорт по всем таблицам. ...
Т.е. из всего вышесказанного следует вывод, что эта грустная ситуация так вот сходу не может быть разрешена???

Интересный вывод...
А что мешает вам разбить ваш экспорт/импорт на несколько блоков?

[Oz]

Цитата:

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

Во время испорта происходит...
...Таблицы, связанные по RecID ОБЯЗАТЕЛЬНО надо испортировать ...

Занятная такая очепяточка получилась Знаковая...
" - А вы уже базу происпортировали?
- Ага, испортировали уже совсем"

[Wamr]

Простите, можно уточнить что означает фраза?
"С Oracle такой фокус не проходит, поскольку длинные имена таблиц и полей отличаются в наименовании по физической структуре представления БД сервером"

[st_msav]

Цитата:

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

Простите, можно уточнить что означает фраза?
"С Oracle такой фокус не проходит, поскольку длинные имена таблиц и полей отличаются в наименовании по физической структуре представления БД сервером"

Скажем в Аксапте есть таблица LongNameTable в структуре БД SQL Servera ее имя уже выглядит LongNameT8012. В представлении БД Оракла эта таблица называется так, как в Аксапте. Та же песня с длинными полями.

[st_msav]

Цитата:

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

Интересный вывод...
А что мешает вам разбить ваш экспорт/импорт на несколько блоков?

Если я разбиваю экспорт/импорт на несколько блоков, это мне разве может дать какое-то преимущество в производительности? Я не пробовал, но, как мне кажется, на выходе будет то же время или то же зависание. У вас есть опыт увеличения производительности таким способом?

[mazzy]

Цитата:

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

У вас есть опыт увеличения производительности таким способом?

Да.

Я же написал выше причину медленной работы - поиск связанных recID в импортируемых данных.

[db]

Цитата:

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

Скажем в Аксапте есть таблица LongNameTable в структуре БД SQL Servera ее имя уже выглядит LongNameT8012. В представлении БД Оракла эта таблица называется так, как в Аксапте. Та же песня с длинными полями.

16 ГБ стандартным экпортом-импортом? Хотите умереть на работе? Ну ну

соответствие аксаптовских и бд-шных имен живет в SQLDictionray
Возьмите эту таблицу и из Оракла и из SQL, постройте на их основе таблицу для соответствий имен
Axapata-Оракл-SQL и поместите, например в SQL-базу

Прилинкуйте Оракловый сервер к SQL-ному
С использованием таблицы соответсвий нагенерите скрипт из команд типа insert into oracle select from sql, не забыв при этом
перекодировать все пустые sql строки в chr(2)

Исполните скрипт - при нормальном железе база перельется часов за 6.
Не забудьте перенести системную табличку SystemSequences

[mazzy]

Цитата:

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

С использованием таблицы соответсвий нагенерите скрипт из команд типа insert into oracle select from sql, не забыв при этом
перекодировать все пустые sql строки в chr(2)

Исполните скрипт - при нормальном железе база перельется часов за 6.
Не забудьте перенести системную табличку SystemSequences

Угу. Вы уже выполняли подобную работу?
Каковы результаты?

Еще немножко побрюзжу:
1. Типичный программистский подход - вместо решения основной проблемы решать кучу маленьких вспомогательных технических проблем (с основной никак не связанных). Еще раз: основная проблема медленной работы - поиск связанных RecID.
2. Что самое показательное, не говорится, что перечислены все пункты, которые надо "не забыть"
3. И никто не гарантирует, что получится правильный результат
4. Когда я слышу подобные рассуждения от программистов, то отношусь обычно очень подозрительно.

db, надеюсь, вы знаете, что советуете.

[db]

Выполнял, замечательные, 75 ГБ за 8 часов, база функционально один в один и никаких проблем

1. Да, типичный программерский подход - не брюзжать, а сделать дело - перевести клиента на другую СУБД за полночи, не забыв поспать самому
2. Перечислены
3. Как хотите, господа консультанты

[Vadik]

Цитата:

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

2. Перечислены

а SQLSYSTEMVARIABLES тоже переливаете "1 к 1" ?

З.Ы, Все, понял - не переливаете, ее в SQLDICTIONARY нет

[komar]

Цитата:

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

Выполнял, замечательные, 75 ГБ за 8 часов, база функционально один в один и никаких проблем

1. Да, типичный программерский подход - не брюзжать, а сделать дело - перевести клиента на другую СУБД за полночи, не забыв поспать самому
2. Перечислены
3. Как хотите, господа консультанты

Может, Вы поможете участникам, и выложите на всеобщее обозрение свой скрипт, тем самым подтвердив свою точку зрения?
Я, например, также считаю, что стандартным импортом 16 Гб качать нереально долго, хоть бей на блоки, хоть не бей.

[mazzy]

Цитата:

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

Выполнял, замечательные, 75 ГБ за 8 часов, база функционально один в один и никаких проблем

Ок. Спасибо.

[st_msav]

Сейчас пробую импортировать с разбивкой на части стандартным способом.

Я уже попробывал произвести экспорт/импорт стандартными средствами, встроенными в SQL Server и Oracle, но при импорте данных Оракл неправильно воспринимает значения полей с типом varchar. Полагаю, что единственным выходом остается предложенный способ.

Возникает только закономерный вопрос: неужели никто не переводил стандартными средствами БД Аксапты с MS SQL в Oracle?!

P.S. Думаю, что было бы просто прекрасно, если уважаемый DB поделился бы скриптами.

[mazzy]

Цитата:

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

Возникает только закономерный вопрос: неужели никто не переводил стандартными средствами БД Аксапты с MS SQL в Oracle?!

Я бы не сказал, что такой перевод делается каждым
Я знаю всего нескольких клиентов, которые это делали.

Мы и они знали, что это будет долго и готовились к переходу.
Насколько я понимаю, никто сейчас не понимает чего именно вы хотите от процедуры экспорта/импорта.

Неужели вы ни разу не импортировали свою базы в SQL?

[st_msav]

Цитата:

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

Я бы не сказал, что такой перевод делается каждым
Я знаю всего нескольких клиентов, которые это делали.

Мы и они знали, что это будет долго и готовились к переходу.
Насколько я понимаю, никто сейчас не понимает чего именно вы хотите от процедуры экспорта/импорта.

Неужели вы ни разу не импортировали свою базы в SQL?

Стандартными средствами делал - на седмые сутки терпение кончилось и я это все дело остановил.

Средствами SQL Server можно выполнить примерно за 40 минут, если восстанавливать из Backup и за час, если выпонять прямой перенос данных между двумя серверами.

Цитата:

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

Насколько я понимаю, никто сейчас не понимает чего именно вы хотите от процедуры экспорта/импорта.

Хочу я, собственно, перевести БД на Оракл. И это есть цель, которая поставлена заказчиком. Единственное требование - вложиться в срок не более 2,5 суток, в самом крайнем случае - 3 суток.

[mazzy]

Цитата:

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

И это есть цель, которая поставлена заказчиком.

Заказчиком?!
Забавно...