ssedovЧто потенциально можно сделать в таком случаеДобавлю к ответу invm, старайтесь блокировать на максимально короткое время, если это возможно.
invmПри конфликте читатель-писатель - грязное чтение, RCSI, snapshot isolation.Гразное чтение или snapshot isolation ТС вряд ли подойдёт, это же получение счётчика.

invmalexeyvgГразное чтение или snapshot isolation ТС вряд ли подойдёт, это же получение счётчика.Зависит от предназначения читаемого. А оно нам неведомо.Вангую, что это самодельный идентити.

ssedovПроблемы ежедневно практически в одно и тоже время. Количество блокированных процессов вырастает от нескольких сотен, до почти двух тысяч. При этом у пользователей все встаеет, начинаются звонки и жалобы. Порой это чаще, раз 5-10 в день, порой 1 раз или редкие дни что ни разу.
В итоге решили понять в чем причина, так как какой то связи пока проследить не получается. Запустил на день трейс на эскалации и блокированные процессы. На двух таблицах были эскалации, но блокировки возникали на той что привел в первом посте. Поэтому эскалации оставил на потом, считая что дело не в них. Пока решил попробовать разобраться с блокировками.
С бд работают около 10 серверов веб приложения. Через веб подключаются пользователи.- А вы отследили цепочку блокировок, когда у пользователя "всё встаёт"?
- Исходной точкой является обращение к SEQUENCES?
- Обращение, на котором блокируется, всегда один и тот же запрос?
- Почему проблема не постоянная, а проявляется периодически? Что меняется в запросах, когда она возникает?
- И на какое время блокируется SEQUENCES? На работу с ней, или в общей транзакции?
- Когда появились эти проблемы? Что то менялось, кто либо полдключался кк серверу для проведения каких то действий (например, для апдэйта софта)?

PizzaPizzassedovесли ПО от стороннего разработчика, то как верно адресовать ему этот вопрос?

Примерно вот так

ssedov ежедневно практически в одно и тоже время ( указать время и конкретные дни ). Количество блокированных процессов вырастает от нескольких сотен, до почти двух тысяч.

у пользователей все встаеет, начинаются звонки и жалобы. Порой это чаще, раз 5-10 в день, порой 1 раз или редкие дни что ни разу

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

a_voroninВот тут самое оно перевести таблицу в InMemory и такое понятие как блокировка вообще исчезнет как класс, но вы версию не указали.Ээээ, "исчезнет как класс"?
Блокировка - это не какая то "бага", которую поправили внедрением функционала InMemory, это фцнуциорал СУБД, гарантирующий атомарность изменения данных. Разумеется, для InMemory таблиц блокировки точно такие же, разве что реализованы другим кодом. Иначе были бы перекорёженные записи, где половина полей изменены одним процессом, а половина другим.

ТС нужно просто делать блокировки короче, если это возможно. Например, без внешней транзакции, внутри простого апдэйта.

invmalexeyvgЭэээ, "исчезнет как класс"?Исчезнет. In-memory таблицы lock-free - применяются оптимистические блокировки. Соответственно, при конкурентном изменении одних и тех же строк, возникает конфликт и одна из транзакций откатывается.А, точно.

Просто это как бы базовое ограничение - "необходимо обеспечить атомарность". Так что не поможет, даже можно не читать про InMemory, что бы это понять. А то, что там откатывается, а не ждёт, я не помнил, не работаю с InMemory, но это уже детали

aleks222Кто на ком стоял?

ЗЫ. Интересно, как "возникает конфликт", если "блокировки нет"?Ну, не придирайтесь к словам :-)
Блокировки нет, но ждать прога не будет, просто отвалится с ошибкой.

Владислав Колосовinvm,

не пойму вопрос. Откуда появится нарушение?Две транзакции сделали обновление строки, изменили поле field = field + 1

Значение field было равно 100
Каждая транзакция в своей копии строки установила значение поля 101.
Далее первая записала 101, второй что записывать, тоже 101? Это нарушение целостности данных. Потому что выполнение двух запросов field = field + 1 должно увеличить field на 2, а не на 1.

Владислав Колосов,

https://docs.microsoft.com/ru-ru/sql/database-engine/transactions-in-memory-optimized-tables

a_voroninalexeyvgпропущено...
Две транзакции сделали обновление строки, изменили поле field = field + 1

Значение field было равно 100
Каждая транзакция в своей копии строки установила значение поля 101.
Далее первая записала 101, второй что записывать, тоже 101? Это нарушение целостности данных. Потому что выполнение двух запросов field = field + 1 должно увеличить field на 2, а не на 1.

Одна транзакция валиться, делает retry, обновляет на 102 . Скажем так, побыстрее это шуршать будет, чем то, что сейчас имеем на физической таблице.Разве быстрее второй транзакции делать всё заново, после того, как завершиться первая, чем подождать до конца первой? Ведь ожидание-то одинаковое, в любом случае второй траназкции придётся ждать окончания первой, она же раньше не сможет продолжиться.

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

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

a_voroninВ данном случае надо было задействовать sequence и непонятно почему это было не сделано. Если это невозможно из-за низкой версии, то надо предгенерить значения или использовать очередь в брокере, что возможно уже давно и дает параллельность.Да, или IDENTITY
Но это уже другой вопрос.
Может, у них какой то особый алгоритм формирования этого номера, определяемый, скажем, внешними правилами (скажем, государственными нормативными актами, или давно принятыми локальными нормативными актами).