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

[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

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

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