Блокировки при обработке журнолов

[Rage]

Здравствуйте форумчане.
Нужна Ваша помощь!
Обновили Аксапту, с Axapta 3.0 CIS Release SP1 на SP2 затем на KR1.
База - MSSQL 2008 в режмие 80 - перевели в режим 100.
Всё нормально за исключением жутких блокировок, при обработке журналов (заказы, инвентаризации...)
Блокируется один пользователь и за ним выстраиваются в очередь еще 10-20 человек.
При небольшом количестве человек, всё нормально, но когда в системе 50+ пользователей всё останавливается.
Профайлер отлавливает только запросы вида - "FETCH API_CURSOR000000000024D897" т.е курсоры.
Каким образом можно определить причины блокировок, и устранить их.
Заранее спасибо за помощь!

[Andrey Peganov]

Для начала определите что блокируется - отдельные записи или таблицы целиком
Администрирование\Запросы\База данных\Блокировки пользователей базы данных

Или прямой SQL:
exec sp_who2 active
exec sp_lock

Если пользователи конкурируют за конкретные записи, то решать нужно со стороны приложения
Если идет эскалация блокировок, то можно подкрутить SQL Server

У Вас, похоже, второй случай

[Rage]

Это exec sp_who2 active

Цитата:

SPID Status Login HostName BlkBy DBName Command CPUTime DiskIO LastBatch ProgramName SPID REQUESTID
150 SUSPENDED bmssa AXAOS 212 axdb SELECT 9602 194 01/19 13:25:33 Navision Axapta 150 0
163 SUSPENDED bmssa AXAOS 212 axdb SELECT 20720 250 01/19 13:24:56 Navision Axapta 163 0
178 SUSPENDED bmssa AXAOS 212 axdb SELECT 1042 220 01/19 13:26:06 Navision Axapta 178 0
186 SUSPENDED bmssa AXAOS 212 axdb SELECT 13496 493 01/19 13:25:48 Navision Axapta 186 0
191 SUSPENDED bmssa AXAOS 212 axdb SELECT 1187 124 01/19 13:29:01 Navision Axapta 191 0
202 SUSPENDED bmssa AXAOS 212 axdb SELECT 0 2 01/19 13:27:38 Navision Axapta 202 0
205 RUNNABLE bmssa AXAOS axdb SELECT 50106 974 01/19 13:29:34 Navision Axapta 205 0
207 SUSPENDED bmssa AXAOS 212 axdb SELECT 811 130 01/19 13:28:29 Navision Axapta 207 0
212 SUSPENDED bmssa AXAOS 138 axdb SELECT 8650 352 01/19 13:29:08 Navision Axapta 212 0
215 SUSPENDED bmssa AXAOS 202 axdb SELECT 0 1 01/19 13:28:50 Navision Axapta 215 0

[Rage]

Это sp_lock

Цитата:

spid dbid ObjId IndId Type Resource Mode Status
58 20 1068595641 1 PAG 1:2707701 IU GRANT
58 20 1068595641 1 PAG 1:2707700 IU GRANT
58 20 1068595641 1 PAG 1:2707703 IU GRANT
58 20 1068595641 1 PAG 1:2707702 IU GRANT
58 20 1068595641 1 PAG 1:2707697 IU GRANT
58 20 1068595641 1 PAG 1:2707696 IU GRANT
58 20 1068595641 1 PAG 1:2707699 IU GRANT
58 20 1068595641 1 PAG 1:2707698 IU GRANT
58 20 1068595641 1 PAG 1:2707653 IU GRANT
58 20 1068595641 1 PAG 1:2707652 IU GRANT
58 20 1068595641 1 PAG 1:2707655 IU GRANT
58 20 1068595641 1 PAG 1:2707654 IU GRANT
58 20 1068595641 1 PAG 1:2707649 IU GRANT
58 20 1068595641 1 PAG 1:2707648 IU GRANT
58 20 1068595641 1 PAG 1:2707651 IU GRANT
58 20 1068595641 1 PAG 1:2707650 IU GRANT
58 20 1068595641 1 PAG 1:2707597 IU GRANT
58 20 1068595641 1 PAG 1:2707596 IU GRANT
58 20 1068595641 1 PAG 1:2707599 IU GRANT
...
spid dbid ObjId IndId Type Resource Mode Status
151 20 471526 4 KEY (bf025b1b5b3f) X GRANT
151 20 811643922 2 KEY (7901adccc22e) X GRANT
151 20 830403965 4 KEY (ff03121465d4) X GRANT
151 20 811643922 3 KEY (030392cf1499) X GRANT
151 20 1085845018 15 PAG 1:921055 IX GRANT
151 20 1085845018 7 PAG 1:890479 IX GRANT
151 20 1085845018 14 KEY (e5017a3ff9fa) X GRANT
151 20 830403965 3 KEY (23031b2c635e) X GRANT
151 20 1085845018 15 KEY (720427f8e234) X GRANT
151 20 811643922 0 RID 1:10782259:9 X GRANT
151 20 1085845018 14 PAG 1:912192 IX GRANT
151 20 830403965 4 PAG 1:61747 IX GRANT
151 20 811643922 0 TAB IX GRANT
151 20 1088448839 1 KEY (bd034a2011fc) U GRANT
151 20 1085845018 8 KEY (e101a137b83a) X GRANT
151 20 830403965 5 KEY (060242cf2fe9) X GRANT
151 20 1085845018 8 PAG 1:10787568 IX GRANT
151 20 830403965 0 RID 1:10756673:19 X GRANT
151 20 1085845018 0 PAG 1:10781871 IX GRANT
151 20 1085845018 0 PAG 1:10781869 IX GRANT
151 20 1085845018 0 RID 1:10781869:3 X GRANT
151 20 1085845018 6 KEY (e901fce593ff) X GRANT
151 20 1085845018 4 PAG 1:884348 IX GRANT
151 20 811643922 0 PAG 1:10782259 IX GRANT
151 20 811643922 0 RID 1:10782259:5 X GRANT

И таких записей ооочень много!
20 - это ID промышленной базы.

[Rage]

Это блокировки из администрирования АХ

Цитата:

Объект базы данных Процесс идентификации Статус блокировки Тип блокировки Режим блокировки Статус блокировки Время ожидания Пользователь
INVENTITEMLOCATION 212 Блокировка Блокировка ключа индексации Блокировка обновления Разрешение 0 <Не определено>
INVENTITEMLOCATION 212 Блокировка Блокировка ключа индексации Блокировка обновления Разрешение 0 <Не определено>
INVENTITEMLOCATION 212 Блокировка Блокировка ключа индексации Исключающая блокировка Разрешение 0 <Не определено>
INVENTITEMLOCATION 212 Блокировка Блокировка ключа индексации Блокировка обновления Разрешение 0 <Не определено>
INVENTITEMLOCATION 212 Блокировка Блокировка ключа индексации Блокировка обновления Разрешение 0 <Не определено>
INVENTITEMLOCATION 212 Блокировка Блокировка ключа индексации Блокировка обновления Разрешение 0 <Не определено>
INVENTITEMLOCATION 212 Блокировка Блокировка ключа индексации Блокировка обновления Разрешение 0 <Не определено>
INVENTITEMLOCATION 212 Блокировка Блокировка ключа индексации Блокировка обновления Разрешение 0 <Не определено>
INVENTJOURNALTABLE 162 Блокировка Блокировка ключа индексации Блокировка обновления Разрешение 0 <Не определено>
INVENTTRANSPOSTING 138 Блокировка Блокировка ключа индексации Исключающая блокировка Разрешение 0 <Не определено>
OFFICIALSTRANS_RU 151 Блокировка Блокировка страницы Нет Разрешение 0 <Не определено>
OFFICIALSTRANS_RU 71 Ожидание Блокировка страницы Блокировка обновления Ожидание 92385 <Не определено>

[Andrey Peganov]

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

С OFFICIALSTRANS_RU посмотрите метод new() класса OfficialsServ_RU. Он при каждом создании класса он пытается удалить строки, что вызывает жесткие блокировки. Решение по меньшей мере странное. Можно закоментить вызов this.cleanUp(), и это никаких траблов не создаст, но блокировок не будет.

Поставьте в параметрах всех пользователей Аксапты трассировку длинных запросов (> 10000 мс). Это поможет определить место кода, в котором блокируются данные

[Rage]

После модификаций программистами (отключение индекс хинтов, исправление методов в классе OfficialsServ_RU), остались блокировки по этим таблицам, ну и соответственно веселье продолжается

Цитата:

Объект базы данных Процесс идентификации Статус блокировки Тип блокировки Режим блокировки Статус блокировки Время ожидания Пользователь
INVENTITEMLOCATION 150 Блокировка Блокировка ключа индексации Блокировка обновления Разрешение 0 <Не определено>
SPECTRANS 55 Блокировка Блокировка ключа индексации Исключающая блокировка Разрешение 0 <Не определено>

[Andrey Peganov]

Модификация формы "Активные пользователи"
Позволяет видеть:
1 Пользователей, которые находятся в корне дерева блокировок, т.е. являются причиной проблем для остальных
2 Загрузку процессора АОСа, по сессиям. В процентах от одного процессора. Т.е. если на АОСе 4 камня, то суммарно может быть до 400%.

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

Судя по всему, у Вас пользователи дерутся в основном за INVENTITEMLOCATION. По нему совет прежний: разделять по аналитикам.
Но не забывайте, что по этой таблице отмечается начало инвентаризации номенклатуры (поля, CountingStarted и CountingJournalId). Нужно учесть открытые журналы инвентаризации при генерации мест хранения

[Rage]

Пока решаем сл. образом - вычисляем объект по которым идёт блокировка (Resource - keylock hobtid=номер объекта в базе), обычно это индексы, и отключаем Index Hint по этому индексу в коде.
Положительные изменения есть, пока не такие большие но всё же...

[Andrey Peganov]

Про блокировки INVENTITEMLOCATION на форуме написано немало. Вашим программистам полезно просмотреть эти темы, в частности
inventItemLocationSelectLocked

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

[Rage]

С INVENTITEMLOCATION будем розбираться.
Блокировки при обработке заказов немного ушли..., теперь боремся с блокировкой SPECTRANS.
Сильно лочатся журналы платежей.
В общем есть к чему стремиться...