Оптимизация апгрейда больших баз

[mazzy]

Цитата:

Сообщение от 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, то может быть, еще можно будет что-нибудь посоветовать.

[alex55]

Цитата:

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

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

Приветствую! А кому-нибудь удалось понять в каких случаях пересоздание таблицы происходит вместо alter table? Мне казалось что исключением является только добавление поля типа container, но похоже это еще от чего-то зависит..

[fed]

Например - пересоздание таблицы происходит при урезании строчных полей. Типа было поле 50 символов, а стало - 40. Насколько я помню, ALTER TABLE такие операции просто не поддерживает, поэтому таблица пересоздается.

[vmoskalenko]

Ох старая тема однако... Ну ладно, тогда я расскажу из своей практике об одном старом проекте. Года 4 было назад, надо было проапгрейдить Аксапту AX 4.0 - AX2012RTM
Размер БД, примерно 2-3ТБ. После апгрейда размер БД вырос на 20%.
Multicompany. Все цифры примерные, простите уже не помню точно.

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

Всё успешно.