SQL SERVER, exclusive lock on table

[Homa Brut]

Всем здоровья.

У меня есть процедура, которая должна прочитать максимальное заначение в поле, и сделать новую запись с этим значением + 1. Не хотелось бы, чтоб в одно время несколько пользователей вызвали эту процедуру и прочитали одно и тоже. Вроде надо использовать exclusive lock. Подскажите прав ли я. Если можно с простеньким примером , как его использовать.
Заранее спасибо.

[Helmsman]

Для таких дел обычно sequence используется. Не подойдёт?

[iDesperado]

https://www.edureka.co/blog/sql-auto-increment/

[Bobeg]

Эксклюзив лок на тейбл это очень очень дорого.

[Тоторо]

Обычно для этой цели используется поле типа integer с auto-increment.
Но для начала надо разобраться для чего вам изначально понадобилось увеличивать поле на 1. Возможно это результат не очень продуманного дизайна.

[Andrey Strelnikov]

Обычно для этой цели используется поле типа integer с auto-increment.
Но для начала надо разобраться для чего вам изначально понадобилось увеличивать поле на 1. Возможно это результат не очень продуманного дизайна.

Ну там могут быть траблы с возвратом значения при параллельной обработке. Есть какие-то механизмы, но вроде не всегда все надежно.
Вообщем-то надо самим генерить guid и его писать. И его же пользовать.

[VovaK98]

У меня есть процедура, которая должна прочитать максимальное заначение в поле, и сделать новую запись с этим значением + 1. Не хотелось бы, чтоб в одно время несколько пользователей вызвали эту процедуру и прочитали одно и тоже. Вроде надо использовать exclusive lock. Подскажите прав ли я. Если можно с простеньким примером , как его использовать.
Заранее спасибо.

Ваш вопрос настолько.. мягко говоря, глубокий и всёобъемлющий, что сложно сразу ответить.

Во-первых, лок на таблицу- это при нынешних возможностях SQL сервера и объемах данных = чистый фейспалм.

Во-вторых, вопрос содержит часть ответа, как вверху правильно ответили, есть уже встроенный тип поля - identity (AKA autoincrement), значение которого вычисляется и поддерживается почти на системном уровне. Зачем эмулировать уже существующий системный код высокоуровневым кодом? Для практики??

Тогда ответ- вместо лока на таблицу создайте или реальную, или вот типа временную таблицу для учёта обращений к вашей процедуре. Что-то вроде

Code: Select all

create table ##g_connections (id bigint IDENTITY, username varchar(64));
create nonclustered index idx_connections_id ON ##g_connections ( [id] DESC);

В вашей уже процедуре проверяйте или добавляйте содержимое глобальной таблицы

Code: Select all

select top 1 username from ##g_connections order by id desc;
insert into ##g_connections (username) values ('testuser');

По выходе из процедуры удаляйте запись во временной таблице

Code: Select all

delete top (1) from ##g_connections where username=@username

Это так, навскидку. Есть и другие варианты.

[Homa Brut]

Thanks. I will take look on what you wrote.

[iDesperado]

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

это бред.

Тогда ответ- вместо лока на таблицу создайте или реальную, или вот типа временную таблицу для учёта обращений к вашей процедуре. Что-то вроде

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

[Andrey Strelnikov]

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

это бред.

Неа . Даже при оборачивании в транзакцию при хорошей нагрузке бывали инцеденты с возвратом @@IDENTITY.

В реале такая процедура много затаскивает в таблицы( не в одну), грузит сервер чем-нибудь . Все это не быстро происходит. Воевать с этим дорого.

В свое время решили просто guid формировать на клиенте и его хранить.
Правда это было еще лет пятнадцать назад.

[VovaK98]

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

Да ладно, всё лучче, чем лок на всю таблицу. Ну пусть тогда триггер пишет.

[liamkin]

Всем здоровья.

У меня есть процедура, которая должна прочитать максимальное заначение в поле, и сделать новую запись с этим значением + 1. Не хотелось бы, чтоб в одно время несколько пользователей вызвали эту процедуру и прочитали одно и тоже. Вроде надо использовать exclusive lock. Подскажите прав ли я. Если можно с простеньким примером , как его использовать.
Заранее спасибо.

Из вашего вопроса непонятно - нужно найти Select max(pole) from Table ?
И затем прибавить 1 и куда-то записать?
Тогда лучше всего подойдет Sequence. Блокировать всю таблицу - очень медленно и поэтому неправильно.

Или в одну строчку таблицы обновить - UPDATE table SET pole=pole+1 WHERE row=myrow ?
В этом случае вам поможет hint WITH ROWLOCK - https://docs.microsoft.com/en-us/sql/t- ... rver-ver15
Будет блокироваться только ваша строчка таблицы, а не вся таблица.

[Homa Brut]

Всем здоровья.

У меня есть процедура, которая должна прочитать максимальное заначение в поле, и сделать новую запись с этим значением + 1. Не хотелось бы, чтоб в одно время несколько пользователей вызвали эту процедуру и прочитали одно и тоже. Вроде надо использовать ехцлусиве лоцк. Подскажите прав ли я. Если можно с простеньким примером , как его использовать.
Заранее спасибо.

Из вашего вопроса непонятно - нужно найти Селецт мах(поле) фром Табле ?
И затем прибавить 1 и куда-то записать?
Тогда лучше всего подойдет Сэуенце. Блокировать всю таблицу - очень медленно и поэтому неправильно.

Или в одну строчку таблицы обновить - УПДАТЕ табле СЕТ поле=поле+1 ШХЕРЕ рош=мырош ?
В этом случае вам поможет хинт ШИТХ РОШЛОЦК - хттпс://дощ.мицрософт.цом/ен-ус/съл/т-съл/ъуериес/хинтс-трансацт-съл-табле?виеш=съл-сервер-вер15
Будет блокироваться только ваша строчка таблицы, а не вся таблица.

Мне как раз нужно было всю таблицу. Но вопрос решил локером в шарп коде.

[Andrey Strelnikov]

Мне как раз нужно было всю таблицу. Но вопрос решил локером в шарп коде.

Ага - аналогично на текущей работе делается. Вообще шарп достаточно производителен, распаралелен и БД ему нужна чтобы хранить.
Ничего интересного не надо в ней делать.
А вообще ID типа integer (и к тому же инкрементные) удобны только в начале жизненного цикла приложения. Относительно простого.

[KVA]

А вообще ID типа integer (и к тому же инкрементные) удобны только в начале жизненного цикла приложения. Относительно простого.

А почему это? И что не так с инкрементными ID типа integer?

[Andrey Strelnikov]

А вообще ID типа integer (и к тому же инкрементные) удобны только в начале жизненного цикла приложения. Относительно простого.

А почему это? И что не так с инкрементными ID типа integer?

Ну вот версии у вас появятся. Поле отдельное прийдется таскать всюду.
Длины поля скорее всего хватит на жизнь приложения - но тоже потенциальная опасность.
Или вдруг прийдется на несколько серверов БД жить. Или просто сливать в централизованную БД. Уже немасштабируемо просто так.
Вообщем не надо из базы выдавать брать ID.

[KVA]

А понятно, premature optimization и постоянное беспокойство по жизни.

[iDesperado]

Ну вот версии у вас появятся. Поле отдельное прийдется таскать всюду.
Длины поля скорее всего хватит на жизнь приложения - но тоже потенциальная опасность.
Или вдруг прийдется на несколько серверов БД жить. Или просто сливать в централизованную БД. Уже немасштабируемо просто так.
Вообщем не надо из базы выдавать брать ID.

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

[Andrey Strelnikov]

Ну вот версии у вас появятся. Поле отдельное прийдется таскать всюду.
Длины поля скорее всего хватит на жизнь приложения - но тоже потенциальная опасность.
Или вдруг прийдется на несколько серверов БД жить. Или просто сливать в централизованную БД. Уже немасштабируемо просто так.
Вообщем не надо из базы выдавать брать ID.

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

Те прямо в продакшн базу будет лить? Без ETL минимального? Всю команду перед этим расстреляют и сожгут всю документацию на систему?
Хотя это только мое мнение и с Вашим я заранее согласен
Но если ваши ID расползутся по куче других систем, то с ними и прийдется жить. Хотя можно все и переписать

[iDesperado]

Те прямо в продакшн базу будет лить? Без ETL минимального? Всю команду перед этим расстреляют и сожгут всю документацию на систему?
Хотя это только мое мнение и с Вашим я заранее согласен

не понял вопроса. а на чем по вашему пишутся взрослые ETL ?

[Andrey Strelnikov]

Те прямо в продакшн базу будет лить? Без ETL минимального? Всю команду перед этим расстреляют и сожгут всю документацию на систему?
Хотя это только мое мнение и с Вашим я заранее согласен

не понял вопроса. а на чем по вашему пишутся взрослые ETL ?

Понял. Мы про разные масштабы говорим. Я по простому и по старинке. Как сейчас в толстых корпоративах незнаю. Видимо везьде автоинкремент?

[Helmsman]

Где как, очевидно. У нас в одних таблицах sequence, в других max(id) + 1 (обычно secondary id). Разве что oracle вместо sql server, но тут однохренственно.

[KVA]

Ну а если серьезно по масштабному мыслить.

Вот есть несколько полей определяющих bank account:

Bank Name
Account Number
Account Type
Account Code
и т.д.

Как например без AccountID передавать это все в другие системы? Что по-вашему будет уникально определять bank account? Как эта другая система определит что пришел новый или обновился существующий? Только не говорите мне что комбинация всех этих (или нескольких) полей будет ключём. Меняется _все_ ... со временем.

[Andrey Strelnikov]

Ну а если серьезно по масштабному мыслить.

Вот есть несколько полей определяющих bank account:

Bank Name
Account Number
Account Type
Account Code
и т.д.

Как например без AccountID передавать это все в другие системы? Что по-вашему будет уникально определять bank account? Как эта другая система определит что пришел новый или обновился существующий? Только не говорите мне что комбинация всех этих (или нескольких) полей будет ключём. Меняется _все_ ... со временем.

AccountID будет autoincrement или сложносочиненным long(big)integer в этом случае?

[KVA]

А чем разница когда AccountID уже попал в базу? Ну допустим мы может рассмотреть оба случая.