AX 2012 R3. Включить OCC на InventSum и выжить

[kgksoft]

Цитата:

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

Вообще это странно. Неужели у вас такое количество одновременных резервирований по одинаковому сочетанию номенклатуры и аналитики?
Мне кажется дело в другом. Срабатывает страничная эскалация блокировок. У нас было такое на старте. Нужно отключить page lock на всех индексах inventsumdelta. Ну и план гайдов добавить, чтобы оптимизатор не сбивался с планами запросов.
По мне включение occ на остатках это очень опасный ход. Ведь в этом суть блокировок - не дать продать в минус, если в этот момент кто-то уже продает то же самое.

да, у меня вся розница и интернет магазин подключены к онлайн резервированию и др.операциям. Внутренние операции и от WMS тоже идет поток. Страничные блокировки у меня на ВСЕХ!!! индексах в базе отключены. У MSSQL памяти много, могу позволить себе (есть конечно сложности с невозможностью делать REORGANIZE индекса, но обхожусь ONLINE ребилдом + партиционированием таблиц + порогом фрагментации в 20%). С отрицательными проблем нет. По сути я даже не вмешивался в этот процесс. Стандарт и так излишне оптимистичен при резервировании с одной и той же аналитики. И разруливает только постпроверкой отрицательных когда все везде обновлено и списано.

Цитата:

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

Скорее всего в этом проблема. Работа с данной таблицей всегда должна происходить в рамках сессии т.е. если вам понадобился индекс где нет TTSID, то ваши планы начинают свое выполнение не с этой таблицы(это и приводит к тормозам). Т.е. если у вас 5 строк, то при выполнение join сложность выборки всегда должна равняться 5 строкам. Но если SQL выбирает неправильный план и у вас начинается выборка с InventDim(ключевое слово тут paremeters sniffing), то тут скорее всего и начинаются тормоза, ибо судя по размеру InventSum данных у вас много и сканирование может уйти в тысячи записей
Т.е. решение тут - с InventSumDelta и InventSumDeltaDim удаляете все индексы(включая индекс по RecId), оставляете один кластерный - это уберет проблему выбора индекса, так как он будет 1
Это должно помочь. Ну или можете заморочиться с план гайдами как написал sonik

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

Цитата:

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

А кроме Романа Долгополова (db / RDOL) никто не пытался бороться с блокировками на InventSumDelta, преобразованием ее в TempDB ? В АХ 2012 это проще, чем в АХ 2009.Временные SQL таблички в ax2009

Очень интересно, но и тут есть беда. У меня есть товары, которые продаются по серийным номерами (пускай будут подписки на какую-нибудь услугу). Суть в том, что из-за врожденной оптимистичности при выборе остатка при резервировании система подбирает всегда один и тот же остаток товара с одним и тем же серийным номером (сортировки остатка по фифо, партиям, датам прихода). Т.е. одновременно в InventSumDelta двумя параллельными процессами пытается списывать один и тот же товар с одним серийником. И разруливается вся эта проблема только уже на этапе посткоммита при получении отрицательного остатка. И отправляет один из процессов в тяжелый RETRY. Как я это решаю. В процессе резервирования товара при построении цикла по ФИФО пропускаю строки, которые уже есть в InvetSumDelta в других TTSID с хинтом NOLOCK. Это в разы уменьшает проблему подбора товара с одним и тем же серийником. C TEMPDB такой финт будет сложно провернуть