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

[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. При большом объеме импортируемых данных, согласованное изменение ссылок делается долго.

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

[Oz]

Цитата:

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

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

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

[st_msav]

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

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

[mazzy]

Цитата:

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

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

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

[st_msav]

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

Да.

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

[Wamr]

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

[st_msav]

Цитата:

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

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

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

[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. Как хотите, господа консультанты

[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

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

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

[st_msav]

Цитата:

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

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

А что Вас в этом удивляет? У заказчика есть свой собственный IT-отдел, сотрудники которого ведут разработку своего собственного программного обеспечения. Они же поддерживают функционирование серверов. Там же и определяется все информационная политика. Я думаю, что никто тут не станет спорить, что Аксапта используется компаниями ради самой Аксапты...

[Serge Kotov]

Цитата:

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

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

Это действительно цель или один из способов решения некой задачи? Не будет ли "заказчик" потом разачарован результатами?

[db]

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

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

2 komar: Использовать, не использовать, спорить, ругаться, доказывать - это личное дело каждого. Доказывать свою правоту или не правоту не собираюсь - наверное слишком старый стал

Успехов.