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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 23.06.2011, 08:30   #1  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Oleksandr Посмотреть сообщение
У нас база почти 1ТБ, апгрейд 4.0 - 2009 на слабоватом сервачке.

Подозреваю, что процесс займет очень большое время или вообще зависнет.

Ненужные таблицы почистим, само собой (SalesParm*, SysDatabaseLog, SalesTable/Line).
Может быть, можно переписать некоторые из скриптов, или удалить какието из таблиц, итп.
Как результаты? Можете рассказать как у вас получилось?

============
Террабайные я не конвертировал. Несколькосотмегабайные были.
Скрипты обсуждались в отдельной ветке.

что касается самой конвертации.
надо помнить, как Аксапта может делать Alter Table: В некоторых случаях Аксапта вместо Alter Table создает новую таблицу, копирует туда преобразованные данные, удаляет старую таблицу, переименовывает новую. Я не знаю условий, когда она вместо Alter Table решает применить пересоздание, но на больших таблицах это частенько происходит.Причем часто делает копирование через tempdb.

Поэтому важно сразу увеличить размер базы данных, чтобы при пересоздании таблиц sql не тратил время на расширение/сжатие файла с данными. Понимаю, что для террабайта рекомендация звучит по-дебильному... Но... Просто учитывайте как Акапта вносит изменения в таблицы.

И обязательно отследите, не происходит ли копирование через tempdb. Если через tempdb, то тоже выделите ему место сразу и желательно на отдельный диск. tempdb может задействоваться, если происходит изменение данных в новой таблице. Например, при смене выравнивания с правого на левое.

И конечно смените выравнивание в ax3.0 отдельной процедурой ДО собственно самой конвертации, как говорится в рекомендациях. В ax2009 по-умолчанию выравнивание влево. В ax3.0 очень часто установлено выравнивание вправо.

==================
По поводу данных. дополенение к http://axapta.mazzy.ru/lib/dbgrowthsolution/
Смотрите в SQL по самым большим таблицам.

Я не знаю реального положения дел, но подозреваю, что у вас самыми большими таблицами являются inventSettlement и LedgerTrans.

Далее пойдут очень опасные советы. И нужно смотреть в ваши модификации. Советы безопасны только для стандартной версии.

inventSettlement.
Скорее всего, в inventSettlement большую часть составляют записи, у которых поле cancelled == NoYes::Yes. Это отмененные сопоставления. В стандартной версии такие записи можно безболезненно удалить (внимание! могут быть модификации, в которых удалять нельзя!!!!)

Если вы раньше не удаляли отмененные, то отмененных может накопится до 80-90% записей в inventSettlement. Удалив сильно облегчите себе апгрейд.

Но если у вас метод списания "по среднему", то даже без cancelled записей эта таблица может быть самой большой

Ну, и конечно может помочь группировка inventSettlement, как описано в статье. Но группировку опасно делать даже в стандартной версии - не все комбинации настроек могут правильно работать с группировкой. Обязательно обсудите возможность группировки с вашими консультантами.

-------------------------
LedgerTrans.
Снова очень опасный совет, если есть модификации. Будьте внимательны.

Если у вас несколько финансовых периодов, то у вас есть открывающие проводки в каждом финансовом году.
LedgerTrans.PeriodCode == PeriodCode::Opening

В стандартной версии такие проводки рассчитываются и перерассчитываются автоматом. Если у вас нет модфикаций, которые работают с такими записями, то открывающие проводки можно удалить. И пересоздать уже в новой версии Главная книга \ Периодические операции \ Закрытие финансового года \ Открывающие проводки.

ЕСЛИ у вы активно используете финансовые аналитики, у вас больше трех финансовых аналитик И вы НЕ сворачиваете финансовые аналитики при переходе в другой период,
ТО таких проводок в открывающих периодов может быть много (до 10-20% от всех записей в LedgerTrans)

-------------------------
также очень опасный совет
в ax2009 изменена работа с промежуточными итогами по финансовым проводкам.
В ax3.0 это таблицы
LedgerBalancesTrans
LedgerBalancesDimTrans

В ax2009 им соответствуют
LedgerBalancesTrans
LedgerBalancesDimTrans
LedgerBalancesTransDelta (!!!!! поищите на форуме по этому ключевому слову. Особенно сообщения от fed - Дениса Федотенко)

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

Если у вас нет модификаций, которые вмешиваются в работу этих таблиц, то перед конвертацией очистите их. А после конвертации пересчитайте периоды Главная книга \ Периодические операции \ Пересчитать сальдо по периодам - записи будут пересозданы уже в новой версии по новым правилам.

======================
Примерно так.

Если приведете строки из отчета Disk Usage by Top Table, то может быть, еще можно будет что-нибудь посоветовать.
__________________
полезное на axForum, github, vk, coub.
За это сообщение автора поблагодарили: Poleax (1), alex55 (3).
Старый 16.01.2018, 18:07   #2  
alex55 is offline
alex55
MCTS
MCBMSS
 
224 / 145 (5) +++++
Регистрация: 13.02.2007
Адрес: Москва
Цитата:
Сообщение от mazzy Посмотреть сообщение
что касается самой конвертации.
надо помнить, как Аксапта может делать Alter Table: В некоторых случаях Аксапта вместо Alter Table создает новую таблицу, копирует туда преобразованные данные, удаляет старую таблицу, переименовывает новую. Я не знаю условий, когда она вместо Alter Table решает применить пересоздание, но на больших таблицах это частенько происходит.Причем часто делает копирование через tempdb.
Приветствую! А кому-нибудь удалось понять в каких случаях пересоздание таблицы происходит вместо alter table? Мне казалось что исключением является только добавление поля типа container, но похоже это еще от чего-то зависит..
Старый 16.01.2018, 19:31   #3  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,913 / 5736 (197) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Например - пересоздание таблицы происходит при урезании строчных полей. Типа было поле 50 символов, а стало - 40. Насколько я помню, ALTER TABLE такие операции просто не поддерживает, поэтому таблица пересоздается.
За это сообщение автора поблагодарили: alex55 (1), vmoskalenko (1).
Старый 17.01.2018, 19:31   #4  
vmoskalenko is offline
vmoskalenko
Участник
Аватар для vmoskalenko
 
145 / 334 (12) ++++++
Регистрация: 25.01.2007
Адрес: Toronto
Ох старая тема однако... Ну ладно, тогда я расскажу из своей практике об одном старом проекте. Года 4 было назад, надо было проапгрейдить Аксапту AX 4.0 - AX2012RTM
Размер БД, примерно 2-3ТБ. После апгрейда размер БД вырос на 20%.
Multicompany. Все цифры примерные, простите уже не помню точно.

Готовились к мигарции данных примерно год.
Процедура непосредственно апгрейда длилась несколько месяцев. И ПРОД не останавливался. У нас было две DELTA.
Последняя процедура длилась 2-3 дня. Потом еще 4 дня ушло на разборки среди менеджеров.

Всё успешно.
За это сообщение автора поблагодарили: Logger (3).
Теги
ax2009, ax4.0, upgrade, производительность

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Оптимизация класса Tax Lihgt DAX: Программирование 43 27.05.2022 11:05
оптимизация запроса статистики по клиенту wojzeh DAX: Программирование 2 26.04.2011 05:08
Оптимизация SQL сервера под Аксапту. 3oppo DAX: Администрирование 23 03.08.2010 14:08
Оптимизация кода с LedgerTrans Poleax DAX: Программирование 18 07.11.2008 12:32
Оптимизация производственного планирования Fisher DAX: Прочие вопросы 19 16.04.2005 11:57

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

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

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 06:22.