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

[Oleksandr]

Коллеги,
кто-либо сталкивался с оптимизацией апгрейда очень больших баз?

У нас база почти 1ТБ, апгрейд 4.0 - 2009 на слабоватом сервачке.

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

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

Заранее благодарю за ответ.

[someOne]

Кое что обсуждалось тут Переход с Axapta 3.0 на AX 2009 - критика утилиты конвертации БД и скриптов обновления

[EfimV]

А вы переходить собираетесь со всеми данными? Как вариант можно перейти с переносом в новую систему начальных остатков. Тогда при конвертации вас будут интересовать только "справочники". И перед конвертацией можно ещё почистить InventTrans, SalesLine и др. таблицы.

[Oleksandr]

Цитата:

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

А вы переходить собираетесь со всеми данными? Как вариант можно перейти с переносом в новую систему начальных остатков. Тогда при конвертации вас будут интересовать только "справочники". И перед конвертацией можно ещё почистить InventTrans, SalesLine и др. таблицы.

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

[Link]

Цитата:

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

Ну не нам тут решать - клиент хочет все.

Жадный какой )

Цитата:

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

Поэтому готовимся к оптимизации. Но это тоже, конечно, вариант.

Не знаю, что вы там собираетесь оптимизировать, вы за выходные собираетесь проапгрейдить такую базу?

Цитата:

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

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

Intelligent Data Management Framework называется, мы собираемся заюзать, если успеем...

[gl00mie]

Цитата:

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

Не знаю, что вы там собираетесь оптимизировать, вы за выходные собираетесь проапгрейдить такую базу?

Если за выходные считать еще вечер пятницы и утро понедельника, то терабайтную базу 4.0 на хорошем железе вполне себе реально конвертнуть. На самом деле, при отлаженном процессе большую часть времени займут уже не столько скрипты конвертации, сколько перестройка индексов в ходе синхронизации.
А на счет "что там собираетесь оптимизировать" - применительно к скриптам конвертации список может быть очень длинным. Большую их часть писали какие-то "студенты" и тестировали их явно на базёнке в 10 Гб с 3-мя компаниями

[Oleksandr]

Цитата:

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

Кое что обсуждалось тут Переход с Axapta 3.0 на AX 2009 - критика утилиты конвертации БД и скриптов обновления

Интересно, спасибо

[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 дня ушло на разборки среди менеджеров.

Всё успешно.

[gl00mie]

Если по существу, то ниже приведена кое-какая информация (применимая к 4.0 и шведскому функционалу) из того, что я делал для оптимизации работы скриптов обновления данных. После тестовой конвертации базы были выявлены самые "долгоиграющие" скрипты и они оптимизировались в первую очередь. Некоторые замечания по приведенным данным:

• В моем случае конвертировалась база 3.0, соотв., мне пришлось оптимизировать куда больше скриптов, в т.ч. касающихся российской локализации;
• При конвертации базы 3.0 идет переливка данных в новую базу, и кучу того, что делают штатные скрипты конвертации, я запихнул в эту переливку, а скрипты отключил; для 4.0 это, видимо, не прокатит.
• Конвертация шла на Oracle DB, у которого, скажем так, не лады с not exists join в плане скорости его отработки, при этом в скриптах конвертации not exists join используется повсеместно; весьма вероятно, на Ms SQL Server ситуация была бы менее плачевной.
• Время работы скриптов конвертации очень сильно зависит от конкретных данных, их объема, используемого функционала, числа компаний...

То, что идет перед названием метода, - это часть имени того или иного класса ReleaseUpdateDB*, т.е., скажем, 41_Basic - это класс ReleaseUpdateDB41_Basic.

Название метода класса обновления данных          Длит., мин.   Что сделано
                                                До   После Gain 
41_Cust.updateCustTransIdRef                    2010 40    1970 добавлен альтернативный метод для случая, когда таблица CustTransIdRef исходно пуста
41_Basic.updateTimeZoneDataUpgrade              1450 40    1410 конвертация выполняется на лету, скрипты обновления отключаются через их настроечную таблицу
401_Vend.createDimHistory_PurchInvoice_DSQL     656  66    590  Переписан ReleaseUpdateDB401_Vend.createDimHistorySprocs для формирования распараллеливаемых запросов с литералами
401_Vend.createDimHistory_PurchPackingSlip_DSQL 60              Переписан ReleaseUpdateDB401_Vend.createDimHistorySprocs для формирования распараллеливаемых запросов с литералами
41_Cust.updateCustTable_W                       20   0     20   значение MandatoryCreditLimit перебивается на лету, скрипт отрублен
41_Cust.updateCustInvoiceJour_HU                10   0     10   добавлена привязка к конфигурационному ключу CRSEHungary
41_Cust.updateCustInterestValues_PL             10   0     10   добавлена привязка к конфигурационному ключу CustInterest
401_Asset.updateCategorizationTrans_CZ          10   0     10   добавлена привязка к конфигурационному ключу PreAcquisition_W
401_Vend.updateVatNum_PL                        10   0     10   добавлена привязка к конфигурационному ключу CRSEPoland
401_Vend.updateVendRegNum_W                     10   0     10   добавлена привязка к конфигурационному ключу CRSEEstonia

[Link]

Цитата:

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

Если по существу, то ниже приведена кое-какая информация (применимая к 4.0 и шведскому функционалу) из того, что я делал для оптимизации работы скриптов обновления данных. После тестовой конвертации базы были выявлены самые "долгоиграющие" скрипты и они оптимизировались в первую очередь.

Спасибо! А можно узнать размер базы и время на синхронизацию и постсинхронизацию.
У меня база в 400Гб, апгрейд с 4ки на 2009.
Тестовый апгрейд выполняется на одном сервере, с виртуализацией под VMWare, ОС Win 2008R2 SP1x64, SQL 2008 SP2 + KB979065. Апгрейд боевой базы, будет проводиться на нескольких серверах, но тоже с виртуализацией.
Фаза синхронизации проходит за 12 часов на тестовом сервере.
Сейчас выполняется постсинхронизация и очень похоже, что тоже придется оптимизировать скрипты.

[gl00mie]

В моем случае конвертировалась база 3.0 размером чуть больше 600 Гб, происходило все на Оракле. Отличие от конвертации базы 4.0 тут в том, что для 2009-й создается новая база, в которую переливаются данные с одновременной конвертацией в Unicode, а уже потом по этой новой базе работают скрипты конвертации. Опять же, в моем случае под 2009-ю был разведен новый комплекс СУБД (хранилище данных и сервера БД), поэтому одним из этапов конвертации было создание "слепка" базы 3.0 на этом новом комплексе: оказалось быстрее сперва перелить данные по сети средствами СУБД и потом уже в рамках одного физического хранилища переливать данные из этого слепка в базу 2009-й, нежели напрямую из старого комплекса переливать их в базу 2009-й по сети. Ниже приводится хронология событий, восстановленная по информации, которую я публиковал для заинтересованных лиц по ходу конвертации.

• 31.12.10 00:00 начало создания "слепка" рабочей базы на новом комплексе (копирование данных средствами СУБД)
• 31.12.10 02:52 запуск скриптов переливки данных из слепка базы 3.0 в базу AX 2009
• 31.12.10 07:15 (приблизительно - по данным об активности СУБД) завершение скриптов переливки данных из слепка - этот момент я это благополучно проспал
• 31.12.10 09:02 запуск контрольного списка обновления в AX 2009
• 31.12.10 09:23 запуск скриптов перед синхронизацией БД
• 31.12.10 09:23 запуск синхронизации БД
• 31.12.10 09:40 начало реальной активности (AX 2009 сперва собирает сведения и показывает, что будет делать при синхронизации, а уже потом собственно приступает к работе). За счет распараллеливания создания индексов, которые были удалены перед заливкой данных из 3.0, СУБД очень неплохо нагружается, см., скажем, http://i56.tinypic.com/2vht750.png
• 31.12.10 11:42 оракловая нода, к которой подключен AOS, на создании индексов по SalesTable объелась памяти, ушла в своп и начала отстреливать активные сессии. AOS попал под обстрел и свалился
• 31.12.10 11:56 как раз в тот момент, когда я перезапустил AOS и хотел было продолжить синхронизацию, у меня пропало соединение с тырнетом (где-то на полчаса, как оказалось). Надо было подумать о резервном канале
• 31.12.10 12:07 связался с коллегой, он возобновил синхронизацию
• 31.12.10 15.30 синхронизация завершилась, но с ошибками на создании нескольких индексов. Для прохождения контрольного списка нужно, чтобы ошибок не было, - пришлось разбираться
• 31.12.10 17:01 запущены пакетные обработки после синхронизации
• 31.12.10 23:53 скрипты конвертации данных завершили свою работу. на все про все ушло 6:51:53 "календарного" времени и порядка 76:31:22 времени БД (т.е. скрипты неплохо распараллелились). За счет тонкой настройки СУБД удалось ускориться по сравнению с последней тестовой конвертацией (82:25:15 времени БД). Я не ожидал, что скрипты конвертации отработают так быстро, поэтому заметил, что все закончилось, лишь полтора часа спустя
• 01.01.11 01:20 отключены конфигурационные ключи SysDeletedObjects40 и SysDeletedObjects41 и запущена повторная синхронизация (в принципе, это можно было отложить на потом).
• 01.01.11 08:40 вылезла ошибка с сообщением о том, что после удаления ненужных полей один из индексов стал индексировать ровно те же поля, что и другой индекс, а для СУБД это неприемлемо. Из-за того, что я не удалил точки останова на выводе ошибок, вылез отладчик, и синхронизация на этом застопорилась. Это событие я тоже проспал
• 01.01.11 10:15 я вырубил отладчик, и синхронизация продолжилась
• 01.01.11 13:28 синхронизация после обновления закончилась, начаты кое-какие дополнительные настройки, в основном касающиеся пользователей
• 01.01.11 16:10 список обновления выполнен полностью, начата выгрузка данных в кубы, чтобы сверить основные транзакционные таблицы "до и после".

[Link]

Спасибо, за столь подробный пост.
Похоже что на MSSQL все выглядит гораздо лучше, без оптимизаций.
Постсинхронизация проходит за 6 часов, правда на 2008 сервере под VMWare съедает всю доступную память - 15 ГБ.
Пробовал экспортировать в сиквел процесс синхронизации, как указанно в мануале, это может дать улучшение производительности при параллельном запуске на нескольких клиентах. Сразу насторожило предупреждение, что все на свой страх и риск. А потом когда выгрузил в сиквел, и увидел сколько там ошибок, от этой идеи отказался.

Мы подумываем воспользоваться зеркалом базы для апгрейда, дабы сэкономить время на копирование или восстановление.
Интересно, вы данные через кубы проверяли. У меня простой джоб все в ексель выкладывает. В чем было преимущество делать через кубы?

А мультисайт сразу активировали? Кто то говорил, что лучше через неделю после успешной работы на новой версии. Гайд по этом поводу предательски молчит.

[gl00mie]

Цитата:

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

Похоже что на MSSQL все выглядит гораздо лучше, без оптимизаций. Постсинхронизация проходит за 6 часов

Это, видимо, без фиговой тучи скриптов обновления базы 3.0 -> 4.0.

Цитата:

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

правда на 2008 сервере под VMWare съедает всю доступную память - 15 ГБ.

Настройкой СУБД занимался не я, так что тут вряд ли чем помогу. На оракловом сервере, про который я писал, что он ушел в своп, памяти было 48 Гб

Цитата:

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

Пробовал экспортировать в сиквел процесс синхронизации, как указанно в мануале, это может дать улучшение производительности при параллельном запуске на нескольких клиентах.

В моем случае ощутимо ускориться удалось еще за счет того, что пакетный сервер был настроен на гораздо большее число потоков, нежели штатные 8: не все, конечно, но часть скриптов очень хорошо распараллеливается, а основная нагрузка все равно приходится на СУБД, поэтому при настройке имеет смысл ориентироваться на число ядер сервера БД, а не AOS.

Цитата:

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

Интересно, вы данные через кубы проверяли. У меня простой джоб все в ексель выкладывает. В чем было преимущество делать через кубы?

В транзакционных таблицах - десятки миллионов записей, Excel подавится. К тому же отделом отчетности, который "ворочает кубы", были заранее написаны соотв. скрипты, и было бы глупо отказываться от удачной возможности переложить на них часть работы по выверке данных

Цитата:

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

А мультисайт сразу активировали?

Нет, не сразу. Вообще, первый где-то месяц-полтора было не до мультисайта

[gl00mie]

Цитата:

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

Сейчас выполняется постсинхронизация и очень похоже, что тоже придется оптимизировать скрипты.

В моем случае самый первый тестовый прогон конвертации (со стандартными скриптами) занял полторы недели Правда, надо признать, и настройка СУБД тогда была, мягко говоря, неоптимальной...

[mazzy]

а давайте про скрипты все-таки в отдельной ветке
Переход с Axapta 3.0 на AX 2009 - критика утилиты конвертации БД и скриптов обновления