AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Администрирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 11.01.2006, 10:42   #1  
st_msav is offline
st_msav
Участник
Аватар для st_msav
 
49 / 14 (1) ++
Регистрация: 24.08.2005
Адрес: Moscow City
? Тормозит Экспорт/Импорт данных
Доброго времени суток.

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

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

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

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

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

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

У кого есть какие соображения на эту тему, подскажите пожалуста.
Старый 11.01.2006, 11:08   #2  
Roman777 is offline
Roman777
NavAx
Аватар для Roman777
NavAx Club
 
320 / 64 (3) ++++
Регистрация: 10.02.2005
Адрес: г. Москва
Встречный вопрос: в оракле пишется журнал транзакций?
Старый 11.01.2006, 11:12   #3  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Во время испорта происходит:
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. При большом объеме импортируемых данных, согласованное изменение ссылок делается долго.

Ваша задача - облегчить работу алгоритму импорта.
__________________
полезное на axForum, github, vk, coub.
Старый 11.01.2006, 11:23   #4  
st_msav is offline
st_msav
Участник
Аватар для st_msav
 
49 / 14 (1) ++
Регистрация: 24.08.2005
Адрес: Moscow City
Дело в том, что самые большие логовые таблицы:
PurchParmTable
PurchParmSubTable
PurchParmLine
PurchParmUpdate
SalesParmLine
SalesParmSubTable
SalesParmTable
SalesParmUpdate
InventSumLinkTTS
InventSumLogTTS
я не могу очищать. Они используются для получения довольно хитрых отчетов и они должны остаться в полученной БД. А что касается связанных записей, то я осуществляю Экспорт/Импорт по всем таблицам. Как я выше описал, туда не включены системные и с перекрестными ссылками.

Т.е. из всего вышесказанного следует вывод, что эта грустная ситуация так вот сходу не может быть разрешена???
Старый 11.01.2006, 11:25   #5  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от st_msav
А что касается связанных записей, то я осуществляю Экспорт/Импорт по всем таблицам. ...
Т.е. из всего вышесказанного следует вывод, что эта грустная ситуация так вот сходу не может быть разрешена???
Интересный вывод...
А что мешает вам разбить ваш экспорт/импорт на несколько блоков?
__________________
полезное на axForum, github, vk, coub.
Старый 11.01.2006, 11:36   #6  
Oz is offline
Oz
Участник
Аватар для Oz
 
293 / 51 (2) ++++
Регистрация: 22.08.2002
Адрес: Москва
Цитата:
Сообщение от mazzy
Во время испорта происходит...
...Таблицы, связанные по RecID ОБЯЗАТЕЛЬНО надо испортировать ...
Занятная такая очепяточка получилась Знаковая...
" - А вы уже базу происпортировали?
- Ага, испортировали уже совсем"
__________________
Здесь могла быть Ваша реклама!
Старый 11.01.2006, 11:52   #7  
Wamr is offline
Wamr
----------------
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
 
1,737 / 858 (32) +++++++
Регистрация: 15.01.2002
Адрес: Москва
Записей в блоге: 7
Простите, можно уточнить что означает фраза?
"С Oracle такой фокус не проходит, поскольку длинные имена таблиц и полей отличаются в наименовании по физической структуре представления БД сервером"
Старый 11.01.2006, 13:45   #8  
st_msav is offline
st_msav
Участник
Аватар для st_msav
 
49 / 14 (1) ++
Регистрация: 24.08.2005
Адрес: Moscow City
Цитата:
Сообщение от Wamr
Простите, можно уточнить что означает фраза?
"С Oracle такой фокус не проходит, поскольку длинные имена таблиц и полей отличаются в наименовании по физической структуре представления БД сервером"
Скажем в Аксапте есть таблица LongNameTable в структуре БД SQL Servera ее имя уже выглядит LongNameT8012. В представлении БД Оракла эта таблица называется так, как в Аксапте. Та же песня с длинными полями.
Старый 11.01.2006, 13:48   #9  
st_msav is offline
st_msav
Участник
Аватар для st_msav
 
49 / 14 (1) ++
Регистрация: 24.08.2005
Адрес: Moscow City
Цитата:
Сообщение от mazzy
Интересный вывод...
А что мешает вам разбить ваш экспорт/импорт на несколько блоков?
Если я разбиваю экспорт/импорт на несколько блоков, это мне разве может дать какое-то преимущество в производительности? Я не пробовал, но, как мне кажется, на выходе будет то же время или то же зависание. У вас есть опыт увеличения производительности таким способом?
Старый 11.01.2006, 14:38   #10  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от st_msav
У вас есть опыт увеличения производительности таким способом?
Да.

Я же написал выше причину медленной работы - поиск связанных recID в импортируемых данных.
__________________
полезное на axForum, github, vk, coub.
Старый 11.01.2006, 14:48   #11  
db is offline
db
Роман Долгополов (RDOL)
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
 
393 / 692 (24) +++++++
Регистрация: 01.04.2004
Адрес: Москва
Цитата:
Сообщение от 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 (18), Vadik (5).
Старый 11.01.2006, 14:58   #12  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от db
С использованием таблицы соответсвий нагенерите скрипт из команд типа insert into oracle select from sql, не забыв при этом
перекодировать все пустые sql строки в chr(2)

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

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

db, надеюсь, вы знаете, что советуете.
__________________
полезное на axForum, github, vk, coub.
Старый 11.01.2006, 15:10   #13  
db is offline
db
Роман Долгополов (RDOL)
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
 
393 / 692 (24) +++++++
Регистрация: 01.04.2004
Адрес: Москва
Выполнял, замечательные, 75 ГБ за 8 часов, база функционально один в один и никаких проблем

1. Да, типичный программерский подход - не брюзжать, а сделать дело - перевести клиента на другую СУБД за полночи, не забыв поспать самому
2. Перечислены
3. Как хотите, господа консультанты
За это сообщение автора поблагодарили: Wamr (5).
Старый 11.01.2006, 15:20   #14  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от db
2. Перечислены
а SQLSYSTEMVARIABLES тоже переливаете "1 к 1" ?

З.Ы, Все, понял - не переливаете, ее в SQLDICTIONARY нет
__________________
-ТСЯ или -ТЬСЯ ?
Старый 11.01.2006, 15:23   #15  
komar is offline
komar
Шаман форума
Аватар для komar
Ex AND Project
 
5,571 / 600 (32) +++++++
Регистрация: 24.05.2002
Цитата:
Сообщение от db
Выполнял, замечательные, 75 ГБ за 8 часов, база функционально один в один и никаких проблем

1. Да, типичный программерский подход - не брюзжать, а сделать дело - перевести клиента на другую СУБД за полночи, не забыв поспать самому
2. Перечислены
3. Как хотите, господа консультанты
Может, Вы поможете участникам, и выложите на всеобщее обозрение свой скрипт, тем самым подтвердив свою точку зрения?
Я, например, также считаю, что стандартным импортом 16 Гб качать нереально долго, хоть бей на блоки, хоть не бей.
__________________
All information in this post is strictly confidential. If you have read it in error, please forget it immediately.
Старый 11.01.2006, 15:28   #16  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от db
Выполнял, замечательные, 75 ГБ за 8 часов, база функционально один в один и никаких проблем
Ок. Спасибо.
__________________
полезное на axForum, github, vk, coub.
Старый 11.01.2006, 15:50   #17  
st_msav is offline
st_msav
Участник
Аватар для st_msav
 
49 / 14 (1) ++
Регистрация: 24.08.2005
Адрес: Moscow City
Сейчас пробую импортировать с разбивкой на части стандартным способом.

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

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

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

Последний раз редактировалось st_msav; 11.01.2006 в 15:53.
Старый 11.01.2006, 16:43   #18  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от st_msav
Возникает только закономерный вопрос: неужели никто не переводил стандартными средствами БД Аксапты с MS SQL в Oracle?!
Я бы не сказал, что такой перевод делается каждым
Я знаю всего нескольких клиентов, которые это делали.

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

Неужели вы ни разу не импортировали свою базы в SQL?
__________________
полезное на axForum, github, vk, coub.
Старый 11.01.2006, 20:35   #19  
st_msav is offline
st_msav
Участник
Аватар для st_msav
 
49 / 14 (1) ++
Регистрация: 24.08.2005
Адрес: Moscow City
Цитата:
Сообщение от mazzy
Я бы не сказал, что такой перевод делается каждым
Я знаю всего нескольких клиентов, которые это делали.

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

Неужели вы ни разу не импортировали свою базы в SQL?
Стандартными средствами делал - на седмые сутки терпение кончилось и я это все дело остановил.

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

Цитата:
Сообщение от mazzy
Насколько я понимаю, никто сейчас не понимает чего именно вы хотите от процедуры экспорта/импорта.
Хочу я, собственно, перевести БД на Оракл. И это есть цель, которая поставлена заказчиком. Единственное требование - вложиться в срок не более 2,5 суток, в самом крайнем случае - 3 суток.
Старый 11.01.2006, 21:46   #20  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от st_msav
И это есть цель, которая поставлена заказчиком.
Заказчиком?!
Забавно...
__________________
полезное на axForum, github, vk, coub.
Теги
тормоза, экспорт/импорт

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Экспорт/импорт платежных поручений _scorp_ DAX: Функционал 96 04.05.2017 17:52
Стандартный импорт данных. Обновление sparur DAX: Функционал 0 24.03.2008 19:07
Экспорт/импорт таблиц IT-specialist DAX: Администрирование 15 26.02.2005 20:46
Импорт на данных из 2.5 в 3.0 ddadream DAX: Прочие вопросы 14 10.06.2003 20:28
Импорт данных Swetik DAX: Функционал 2 30.01.2003 01:52

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 07:58.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.