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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 01.01.2011, 21:28   #1  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,594 / 5232 (182) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 2
Переход с Axapta 3.0 на AX 2009 - критика утилиты конвертации БД и скриптов обновления
Думаю, в ближайшее время для многих компаний будет актуален вопрос перехода с версии 3.0 на 2009-ю. Если у компании достаточно большая база, и компания не хочет переходить лишь со справочниками и начальными остатками, то возможность конвертации такой большой базы стандартными средствами в приемлемые сроки может стать серьезным препятствием: обычно простой приемлем в течение выходных (т.е. в районе 60-и часов, включая вечер пятницы и утро понедельника), в то время как стандартный способ конвертации базы представляется, мягко говоря, далеким от оптимального.
Что предлагается сделать при штатной конвертации базы:
  • перевести базу на левое выравнивание;
  • удалить из базы данные, которые не предполагается переносить, т.е. затраты времени на перенос которых не оправданы (всякие там логи, параметрические таблицы для обработки заказов/закупок и т.п);
  • с помощью отдельной утилиты создать слепок базы 3.0, подготовленный для AX 2009 (с данными, конвертированными в Unicode, с 64-битными полями под RecId, но со схемой от базы 3.0); утилита не разбирает, какие таблицы переносит, поэтому чтобы не переносить лишнее, нужен предыдущий шаг;
  • с помощью скриптов конвертации:
    • перенести часть данных из удаляемых полей в новые (например, из createdTime/modifiedTime - в createdDateTime/modifiedDateTime);
    • заполнить часть новых полей константами либо значениями других полей той же записи (например, новые поля с MST-суммами могут заполняться из полей с валютными суммами при условии совпадения валюты проводки и основной валюты компании);
    • перебить значения некоторых enum'ов на новые (т.е. было значение 200, стало 5);
    • ну и выполнить какие-то нетривиальные преобразования.
Мне лично непонятно, зачем нужно тратить столько драгоценного времени на тупое перелопачивание одних и тех же данных, если кучу перечисленных действий можно было бы выполнить в рамках одного этапа - создания слепка базы 3.0, подготовленного для AX 2009. Ведь можно было бы на лету:
  • переводить данные на левое выравнивание;
  • заполнять поля типа UtcDateTime из имеющихся старых пар полей типа date + time (а это в скриптах конвертации реализовано офигенски неэффективно);
  • перебивать значения enum'ов;
  • заполнять новые либо незаполненные старые поля, если их значения можно легко и просто вычислить из других полей записи либо вообще задать константами;
  • выбирать, какие таблицы не переливать вовсе;
  • фильтровать переливаемые таблицы, чтобы не переливать лишние данные (всякие там отмененные/закрытые и т.п. записи либо записи с датой ранее заданной);
  • и много чего еще...
При всем при этом за счет сокращения числа промежуточных "переделов" базы можно также сократить число создаваемых по ходу конвертации резервных копий, что даст дополнительный выигрыш во времени. В общем, отсюда вопрос: почему стандартная конвертация сделана так неэффективно? Я уже молчу про скрипты перебивки енумов, которые зачем-то запускаются в разрезе компаний вместо выполнения одного прямого SQL-запроса, но зачем же столько ненужных промежуточных действий?..
Кто как боролся с этими проблемами - из тех, кому уже приходилось участвовать в переходе на 2009-ю с конвертацией имеющейся базы? Если верить недавнему семинару, кто-то для части таблиц отключает поля createdDate/modifiedDate, чтобы сэкономить время на их преобразовании в createdDateTime/modifiedDateTime, но это, по-моему, не выход... Какие еще есть варианты?
За это сообщение автора поблагодарили: Logger (5).
Старый 02.01.2011, 10:22   #2  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,441 / 1561 (59) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
  • перевести базу на левое выравнивание;
  • удалить из базы данные, которые не предполагается переносить, т.е. затраты времени на перенос которых не оправданы (всякие там логи, параметрические таблицы для обработки заказов/закупок и т.п);
Ничего же не мешает выполнить это заранее, а не в день Ч, правда ?
Цитата:
Ведь можно было бы на лету..
Теоретически ничего не мешает построить гораздо более эффективные запросы для обновления конкретной таблицы "на лету" в конкретного экземпляре приложения. Проблема в том, что
  • над скриптами обновления как собственно и над отдельными модулями работают назависимые команды и люди
  • отлаживать несколько простых скриптов им проще чем универсальный мегаскрипт (или получаем на выходе письмо дяди Федора)
  • скрипты должны работать (или не работать) в зависимости от состояния конфигурационных ключей
  • при апгрейде все равно где-то надо по каждой записи запускать бизнес-логику на X++ (те же расчеты AmountMST сумм и более сложную) зависящую от тех же enum-ов
Так что мегаскрипт тут не помощник
Что касается тормознутости отдельных скриптов, это частично компенсируется тем, что можно поиграть с количеством AOS-ов и параллельно выполняемых батчей
Цитата:
Если верить недавнему семинару, кто-то для части таблиц отключает поля createdDate/modifiedDate, чтобы сэкономить время на их преобразовании в createdDateTime/modifiedDateTime, но это, по-моему, не выход
Это один из выходов, кстати не самый плохой

Цитата:
Думаю, в ближайшее время для многих компаний будет актуален вопрос перехода с версии 3.0 на 2009-ю
Или уже на 6.0 ?
__________________
-ТСЯ или -ТЬСЯ ?
Старый 02.01.2011, 14:15   #3  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,247 / 2131 (78) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от Vadik Посмотреть сообщение
Или уже на 6.0 ?
На 6.0 никто не обещал автоматического перехода.

По поводу тормознутости конвертера - поддерживаю Gl00mie - по сути, инструмент вроде есть, но на реальной базе без серьезных переработок неприменим.
Старый 02.01.2011, 19:19   #4  
someOne is offline
someOne
Участник
Аватар для someOne
 
171 / 409 (14) +++++++
Регистрация: 11.12.2008
Адрес: Москва
Совершенно согласен с вами, gl00mie.
Видимо, при создании этой процедуры руководствовались лишь чисто теоретической возможностью перехода, не думая о том с какими сложностями придется столкнуться разработчикам Аксапта при переходе.

Для себя решил проблему написанием собственного скрипта (на C#) по переносу данных из Ax 3.0 (Oracle) --> Ax2009 (MSSQL)

Удалось решить сразу ряд проблем
- Не нужна подготовка исходной базы данных
- Весь перенос данных происходит в один заход, при этом происходят все необходимые этапы (Преобразование Unicode, Выравнивание влево, конвертация DateTime, конвертация типов int--> int64, конвертация спец символов Orale пустой строки в "")
- Переносятся только те данные которые используются в новой версии.
Например ряд таблиц, типа DataBaseLog, Xref*, SalesParm* и так далее при переносе пропускаются, что так же экономит время.

Скрипт лишь наполняет "пустую", подготовленную заранее базу данных Ax2009 данными, в уже существующие таблицы Ax2009 из базы Ax 3.0 средствами SQL (Bulk Copy).

При этом происходит сравнивание таблиц SQLDictionary исходной и итоговой базы,
и переносятся данные в соответствии с кодами таблиц и полей, даже если они были переименованы в новой версии Аксапта.

После работы скрипта остается лишь реиндексировать базу (скрипт удаляет индексы для ускорения переноса данных), так как база до этого уже полностью была синхронизована.

Скрипт позволяет перенести базу 150 GB за
- 9 часов при одно поточном запуске
- 4 часа (ели запустить скрипт в 3-х потока одновременно на разных серверах.)

+ 4 часа на полную индексацию...

Не понятно почему в MS не могли написать "нормальную", удобную процедуру конвертации, с их возможностями разработки ?

Кстати, по поводу ENUM- ов. Вы имеете ввиду процедуру "последующей синхронизации" ?.
Что то про ENUM - ы я ничего не встречал в описании процедуры конвертации...

Последний раз редактировалось someOne; 02.01.2011 в 19:26.
За это сообщение автора поблагодарили: ziva (2), gl00mie (2).
Старый 02.01.2011, 20:34   #5  
ziva is offline
ziva
Иван Захаров
Злыдни
Лучший по профессии AXAWARD 2013
 
65 / 106 (4) +++++
Регистрация: 25.03.2005
Цитата:
Сообщение от someOne Посмотреть сообщение
Для себя решил проблему написанием собственного скрипта (на C#) по переносу данных из Ax 3.0 (Oracle) --> Ax2009 (MSSQL)
А я написал DTS-ку на Integration Services, управляемую из базы-получателя (АХ2009) - имеется список таблиц из 2009 (и полей с их типами, выравниванием и пр.), а также список таблиц (и полей) из Ах30.
Средствами Аксапты это всё сопоставляется (делается нужное выравнивание, приведение, ...) и по сути для каждой таблицы генерим запрос вида:
INSERT INTO ... SELECT ...
А сама DTS обходит это дело по помеченным к переносу таблицам и выполняет для каждой таблицы подобный запрос.
Потом уже средствами AX2009 обновляем данные (запускаем нужные методы из ReleaseUpdateDB*)

Надеюсь что кому-нибудь такой подход тоже облегчит жизнь
За это сообщение автора поблагодарили: gl00mie (2), Logger (3).
Старый 02.01.2011, 23:37   #6  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,071 / 2100 (79) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
А я бы еще про время перехода уточнил. Если система работает каждый день (про круглосуточно молчу), то выходных просто нет и для "стандартного перехода" придется все равно дополнительно переносить операционные данные за время конвертирования основной БД.
__________________
Ivanhoe as is..
Теги
ax2009, upgrade, конвертация базы данных, полезное

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Переход (upgrade) Аксапта с версии 3 на Ax 2009 Evgeniy2020 DAX: Администрирование 4 15.07.2010 09:10
gatesasbait: Dynamics AX 2009 SSRS and SSAS Integration Tips Blog bot DAX Blogs 3 09.07.2009 13:07
Arijit Basu: AX 2009 Document Management & MOSS / WSS Blog bot DAX Blogs 0 23.01.2009 01:07
Dynamics AX: Business Intelligence in Dynamics AX 2009 (Part I) Blog bot DAX Blogs 0 26.06.2008 02:19
Введение в Аксапту Роман Кошелев DAX: Прочие вопросы 0 18.12.2001 14:00
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

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

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

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