Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Доброго времени суток! Есть хранимка Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. Поменять порядок в ней сейчас будет крайне тяжело. Проблема в том, что эта хранимка может выполняться параллельно и к моменту объявления транзакции в tbGroup может уже не быть части строк, что были на момент заполнения #tbGroup - но они и не нужны. Я могу внутри транзакции каскадно удалить записи из #tbGroup и дочерних временных таблиц. Проблема в том, что и во время выполнения транзакции конкурентами могут быть удалены записи из tbGroup (вообще-то они тоже не нужны) И тут 2 пути: 1. В каждой из 30 MERGE инструкций делать проверку на существование строки в tbGroup (и чет мне уже не кажется это решение не совсем правильным) 2. Заблокировать в начале транзакции tbGroup (желательно не всю, а только те строки, что есть в #tbGroup) Как я себе это представляю - нарисовал выше. Вот правильно ли? Про уровни изоляции и блокировки читал, но в реале использовал 1 раз. Так что не пинайте сильно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2018, 19:42 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Ну, вставьте эксклюзивный апплок в начале процедуры сериализовав таким образом ее выполнение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2018, 19:58 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
О чем вы, Сергей Алексеевич? Да и не нужно мне блокировать таблицу в начале хранимки, нужно только в начале транзакции ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2018, 20:27 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Я так понимаю вы имели в виду sys.sp_getapplock чтобы реализовать синглтон. Но это совсем не то, что мне нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2018, 21:04 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Шамиль ФаридовичЗаблокировать в начале транзакции tbGroup (желательно не всю, а только те строки, что есть в #tbGroup) Как я себе это представляю - нарисовал выше. Вот правильно ли?Представляете правильно. Нарисовали не совсем правильно - желаемый результат не гарантирован. Чтобы максимально приблизится к "желательно не всю, а только те строки, что есть в #tbGroup", у tblGroup должен быть индекс по Id и запрос написан так: Код: sql 1. 2. 3. 4. 5. 6. Плюс в этом запросе придется обеспечить сканирование #tblGroup в порядке id, иначе можете получить дедлок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2018, 23:28 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
invm, спасибо за ответ invmПлюс в этом запросе придется обеспечить сканирование #tblGroup в порядке id, иначе можете получить дедлок. 1. На #tbGroup есть кластерный PK по полю Id. Больше индексов нет. Этого будет достаточно? 2. #tbGroup может быть достаточно большой, и гонять tbGroup (сейчас 2M записей) вложенными циклами не самый лучший вариант. В tbGroup есть проиндексированное поле OrgId. Можно в этом случае инициировать блокировку не конкретных строк, а диапазона ключей, как-то так: Код: sql 1. 2. 3. ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2018, 00:06 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Шамиль Фаридович, авторво время выполнения транзакции конкурентами могут быть удалены записи из tbGroup Ну и что? Код: sql 1. 2. 3. 4. 5. это прекрасно переживёт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2018, 13:49 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Владислав Колосов, не переживет именно MERGE (во временнных таблицах будут ссылки на не существующие в tbGroup записи invm дал ответ на мой первый вопрос. Сейчас меня интересует Код: sql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2018, 15:08 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Шамиль Фаридович Код: sql 1. holdlock ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2018, 15:42 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Наколько я понял из статьи уровни гранулярности , блокировка по отдельным строкам и по диапазону ключей индекса - это одно и то же. Т.о. если я хочу заблокировать только те строки, что относятся к определенной организации, то я должен выполнить следующее: Код: sql 1. 2. 3. ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2018, 16:10 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Шамиль Фаридович, и подумать о эскалации ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2018, 16:32 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Шамиль Фаридовичблокировка по отдельным строкам и по диапазону ключей индекса - это одно и то жеНе совсем. Но для вашей задачи можете так считать. При ограничении OrgId = @OrgId можете написать вот так: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. В худшем случае (если не будет выбран NL для соединения таблиц) - получите блокировку всех строк в tbGroup для OrgId = @OrgId. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2018, 17:23 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
invmВ худшем случае (если не будет выбран NL для соединения таблиц) - получите блокировку всех строк в tbGroup для OrgId = @OrgId , а в лучшем, блокировку только тех, что есть в #tbGroup - красивое решение! TaPaKи подумать о эскалации Отсюда мне стало известно, что порог укрупнения блокировок по умолчанию равен 5000 строк. Т.о. для топ-50 моих организаций сервер будет пытаться автоматически укрупнить блокировку до уровня таблицы. 1. Можно ли увеличить этот порог для одной (можно и всех) таблиц в рамках одной транзакции скажем до 100 000? (для меня важным моментом является возможность параллельной работы 2 пользователей из разных организаций) 2. При каком количестве строк (а наверное занимаемых ими страниц) лучше сразу указывать PAGELOCK вместо ROWLOCK? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2018, 18:22 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Шамиль Фаридович, а где вы там "5000 строк" увидели ? и да отключение эскалации там описано ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2018, 18:24 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
ну и все эти ваши танцы, особенно с длинной транзакцией, в итоге приведут вас к дедлокам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2018, 18:25 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
TaPaK, я увидел там 5000 блокировок. Если у меня в таблице #tbGroup 5001 строка и стоит tbGroup with (rowlock), разве это не вызовет попытку укрупнения блокировки до уровня таблицы? TaPaKи да отключение эскалации там описано Мне нужно не отключение, а перенастройка эскалации, причем желательно для одной таблицы в рамках одной транзакции. Я так понимаю, увеличить порог укрупнения только для текущего соединения навряд ли получится, а тем более для одной таблицы Поэтому видимо придется остановится на отключении эскалации: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Хотя по идее можно SET LOCK_ESCALATION = DISABLE засунуть внутрь транзакции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2018, 19:19 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Шамиль ФаридовичХотя по идее можно SET LOCK_ESCALATION = DISABLE засунуть внутрь транзакции. Это заблокирует таблицу вообще до конца транзакции Причем даже для селекта, и даже с nolock-м ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2018, 19:36 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Шамиль Фаридович, У вас конкурентный доступ к ресурсу с несовместимыми блокировками. Откуда тут взяться эскалации? Лучше уберите rowlock и позвольте серверу самому управлять гранулярностью блокировок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2018, 19:48 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Шамиль Фаридович, все равно не понял. Вас merge попытается из таблицы #tbGroup вернуть записи в tbGroup, которые были удалены другими процессами? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2018, 11:17 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
invmШамиль Фаридович, У вас конкурентный доступ к ресурсу с несовместимыми блокировками. Откуда тут взяться эскалации? Лучше уберите rowlock и позвольте серверу самому управлять гранулярностью блокировок. это здесь у него конкурентный доступ с несовместимыми блокировками? Код: sql 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2018, 11:19 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
TaPaKэто здесь у него конкурентный доступ с несовместимыми блокировками?Да. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2018, 11:50 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
invmTaPaKэто здесь у него конкурентный доступ с несовместимыми блокировками?Да. ну ок ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2018, 11:58 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
TaPaK, Вообще-то, при updlock любая конкурентная блокировка на таблице будет препятствовать эскалации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2018, 12:37 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
invmTaPaK, Вообще-то, при updlock любая конкурентная блокировка на таблице будет препятствовать эскалации. а откуда она возьмётся? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2018, 12:38 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39616970&tid=1689980]: |
0ms |
get settings: |
7ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
98ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
39ms |
get tp. blocked users: |
1ms |
| others: | 275ms |
| total: | 453ms |

| 0 / 0 |
