AX2012R3: полная синхронизация данных POS-магазина

[PTG]

Всем доброго дня!

Используем версии: AX2012R3 CU9, MSSQL2012

Справочник продуктов содержит 800 000 наименований.
Все продукты необходимо загружать в магазины.

Задание 1040 Продукты.
Первоначальная полная синхронизация данных с базой магазина(загрузка задания 1040) выполняется в среднем в течении 40-60 минут.

Повторная полная синхронизация идет свыше 6-и часов... далее терпение заканчивается...процесс на стороне базы магазина прерываем.

Заметили: SQL основное время выполняет delete from inventtable

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

[ZornFire]

Я правильно понял, что у Вас синхронизация выполняется не через пакетный сервер, дополняя или меняя существующие н.н., а именно напрямую синхронизируете таблицы через БД посредством MS SQL?
delete from inventtable это вот зачем? по этой логике у Вас, на БД магазина, из справочника н.н., сначала удаляются все записи, затем загружаются по новой из офисной БД.
По мне, так правильнее было бы, настроить пакетные сервера, где данные буду обновляться, не общем массивом в 800к, а только те что изменены\удалены.

Или как минимум перенастроить процесс синхронизации, что справочники н.н. не удалялись, а потом заливались по новой, а апдейтелись(update from inventtable).

Если не сможете своими силами - наймите на эту задачу консалтинговую компанию. На мой взгляд это оптимальный вариант.

[PTG]

Цитата:

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

Я правильно понял, что у Вас синхронизация выполняется не через пакетный сервер, дополняя или меняя существующие н.н., а именно напрямую синхронизируете таблицы через БД посредством MS SQL?
delete from inventtable это вот зачем? по этой логике у Вас, на БД магазина, из справочника н.н., сначала удаляются все записи, затем загружаются по новой из офисной БД.
По мне, так правильнее было бы, настроить пакетные сервера, где данные буду обновляться, не общем массивом в 800к, а только те что изменены\удалены.

Или как минимум перенастроить процесс синхронизации, что справочники н.н. не удалялись, а потом заливались по новой, а апдейтелись(update from inventtable).

Если не сможете своими силами - наймите на эту задачу консалтинговую компанию. На мой взгляд это оптимальный вариант.

Описанное в первом посте - это стандартный функционал АХ2012R3. Пакетные сервера присутствуют. Мы ничего не вкручивали.
delete from inventtable - это стандартно тоже, видимо чтобы отработали триггеры...
Писал именно про полную синхронизацию... распределение изменений работает.
Проблема растет из вот отсюда: добавляем новый магазин, он либо автоматом, либо по принуждению попадает в ассортимент, что влечет за собой вызов полной синхронизации задания 1040Продукты. А делать под каждый магазин свой ассортимент, когда он единый для магазинов...

[Alex_KD]

800 000 ..... чем торгуете если не секрет?
Действительно ли нужно все? Ведь можно настроить так что магазин А будет загружать только продукты для магазина А, а магазин Б только те что на полках лежат у магазина Б.

Зря change tracking использовать не хотите, вещь хорошая. Опять же наврятли вы все 800 000 продуктов каждый день-неделю меняете.

RetailPOS база на каком SQL сидит? Express?
Индексы периодически оптимизируете?
Есть ли триггеры на ax.InventTable?

RetailPOS база локальная в магазине или в облаке?

ЗЫ Интересно сколько времени у вас занимает calculate/post statement.
ЗЗЫ 800 000 .... сколько времени инвентаризация займет....
ЗЗЗЫ Бизнес решение, которое переодически загружает 800 000 продуктов вызывает явное подозрение...

[PTG]

Цитата:

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

800 000 ..... чем торгуете если не секрет?
Действительно ли нужно все? Ведь можно настроить так что магазин А будет загружать только продукты для магазина А, а магазин Б только те что на полках лежат у магазина Б.

Зря change tracking использовать не хотите, вещь хорошая. Опять же наврятли вы все 800 000 продуктов каждый день-неделю меняете.

RetailPOS база на каком SQL сидит? Express?
Индексы периодически оптимизируете?
Есть ли триггеры на ax.InventTable?

RetailPOS база локальная в магазине или в облаке?

ЗЫ Интересно сколько времени у вас занимает calculate/post statement.
ЗЗЫ 800 000 .... сколько времени инвентаризация займет....
ЗЗЗЫ Бизнес решение, которое переодически загружает 800 000 продуктов вызывает явное подозрение...

Ассортимент единый.
Индексы обязательно. Ежедневно.
Триггеры стандартно на ax.InventTable есть.
База локальная.
Подозрение вызывает стандартный функционал, который вызывает полную синхронизацию.

[AvrDen]

Доброе утро!
Поделитесь пожалуйста кто как настраивает ассортименты для магазинов в ситуации когда ассортимент единый(300-500 тыс позиций) и количество магазинов 30-50. Создать один ассортимент для всех магазинов или для каждого магазина создавать свой ассортимент?

[Ivanhoe]

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

Ну и в целом, какие-то бешенные у вас ассортименты. Это что, запчасти какие-то? Даже в продуктовых гиперах активных позиций на магазин максимум тысяч 100 и это с запасом.

[PTG]

Цитата:

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

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

Ну и в целом, какие-то бешенные у вас ассортименты. Это что, запчасти какие-то? Даже в продуктовых гиперах активных позиций на магазин максимум тысяч 100 и это с запасом.

В R2, если не ошибаюсь механизм аналогичный AX5. Собственно мы перелезли с АХ5 на R3 и механизм уже другой.
Уточните пжлс еще у коллег, стоит ли под каждый магазин создавать свою отдельную группу данных канала?

С новым магазином ситуация следующая: чтобы товар был виден в магазине, этот товар должен быть включен в ассортимент, в который в свою очередь должен быть включен магазин. Так как у нас ассортимент общий (одинаковый) для всех магазинов, то мы не создаем под каждый магазин свой ассортимент.
Далее создаем новый магазин, относим его в орг. иерархию, сопоставляем с розничной категорией, включаем в имеющийся ассортимент(ассортимент пере опубликовываем) или можно первоначально указать организационную иерархию
,к уда входит магазин, но все равно ассортимент при запуске процедуры обновления ассортиментов обновится, так что повлечет запуск полной синхронизации ассортимента.

Да ассортименты бешеные: от колбасы до ручек.

[mazzy]

Цитата:

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

delete from inventtable это вот зачем?

Именно

Цитата:

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

В R2, если не ошибаюсь механизм аналогичный AX5. Собственно мы перелезли с АХ5 на R3 и механизм уже другой.

и в r2 и в r3 существует понятие "иерархия таблиц"
в r2 эта иерархия настраивалась в справочнике аксапты.
в r3 эта иерархия существует в виде xml-файла, изменяется только в текстовом редакторе.

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

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

повторюсь, в r3 точно такой же механизм. только настройка в xml-файле, а не в аксапте. насколько я помню, интеллекта в этот механизм не добавляли.

продукты, насколько я помню, находятся где-то в середине иерархии.
насколько я помню, к продуктам были пристроены с десяток других таблиц.

снятие галочки "Каскадное обновление" решает проблему с производительностью
но добавляет кучу геморроя с точки зрения целостности данных.

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

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

по идее, механизм обмена нужно делать более интеллектуальным. например, чтобы случаи "удаление-тутже-вставка" не приводили к каскадному удалению-вставке.

==========================
по идее число delete/insert должно быть минимальным всегда.
прежде чем менять настройки, галочки и джобы, разберитесь почему вообще возникают команды на удаление при реинициализации.

[Ivanhoe]

Говорят, что нет проблемы описанной выше. Точно нет доработок? Как у вас заведены магазины, группы (или как они там называются в r3), ассортименты?

[PTG]

Цитата:

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

Говорят, что нет проблемы описанной выше. Точно нет доработок? Как у вас заведены магазины, группы (или как они там называются в r3), ассортименты?

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