Этот баннер — требование Роскомнадзора для исполнения 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 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
TaPaKа откуда она возьмётся?Мы рассматриваем работу в однопользовательском режиме? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2018, 12:52 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
invmTaPaKа откуда она возьмётся?Мы рассматриваем работу в однопользовательском режиме? нет, но ситуация кто первый встал у того и все тапки случится? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2018, 12:56 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
TaPaKinvmпропущено... Мы рассматриваем работу в однопользовательском режиме? нет, но ситуация кто первый встал у того и все тапки случится? При параллельном запуске этого скрипта (даже с непересекающимися ID) эскалация будет невозможна из-за IU на таблице. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2018, 13:09 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
TaPaKно ситуация кто первый встал у того и все тапки случится?Это про эскалацию? Случится, если на уровне таблице, на момент попытки эскалации, не будет ни одной чужой I*. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2018, 13:13 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
invmЭто про эскалацию? Случится, если на уровне таблице, на момент попытки эскалации, не будет ни одной чужой I*. IS допустимы, они вполне с U "уживаются" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2018, 13:14 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
msLexTaPaKпропущено... нет, но ситуация кто первый встал у того и все тапки случится? При параллельном запуске этого скрипта (даже с непересекающимися ID) эскалация будет невозможна из-за IU на таблице. это понятно, но у него немерянная транзакция с какими-то 15 мержами, и первая легко схватит всю таблицу и остальные дружно встанут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2018, 13:20 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
TaPaKи первая легко схватит всю таблицу и остальные дружно встанут если успеет, мы же говорим про параллельное выполнение. к тому же, не каждый же поток будет добираться до 5000 заблокированных строк, так что "маленькие" порции будут намертво блокировать эскалацию ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2018, 13:27 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
TaPaKи первая легко схватит всю таблицуНа основании чего? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2018, 13:27 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
invmTaPaKи первая легко схватит всю таблицуНа основании чего? того что на момент удаления никто больше с ней не конкурирует ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2018, 13:32 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
msLexIS допустимы, они вполне с U "уживаются"Только вот эскалация U будет до X, ибо U на таблицу не бывает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2018, 13:47 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
TaPaKтого что на момент удаления никто больше с ней не конкурируетТ.е. таки рассматриваем вариант вообще без конкуренции, даже без читателей? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2018, 13:52 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
invmTaPaKтого что на момент удаления никто больше с ней не конкурируетТ.е. таки рассматриваем вариант вообще без конкуренции, даже без читателей? ну отсюда не видно что же там ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2018, 13:53 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Доброго времени суток! Подскажите пожалуйста, почему запись вида Код: sql 1. 2. 3. 4. 5. 6. ил просто Код: sql 1. 2. делает кучу блокировок с TYPE = KEY (ровно столько, сколько групп в организации), причем блокируется именно индекс IX_tbGroup_OrgId, вместо того, чтобы сделать 1 блокировку на диапазон. Тем самым запрашиваемый диапазон действительно защищен от удаления и частично от обновления (от обновления поля OrgId), но не защищен от добавления групп в ту же самую организацию (правда пока до конца неизвестно, нужно ли это вообще). И все же интересно, как заставить сервер блокировать именно диапазон ключей индекса, в том числе и от вставки? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2018, 12:54 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
зачем вам нужна блокировка на вставку в некий диапазон ключа? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2018, 12:56 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Шамиль ФаридовичИ все же интересно, как заставить сервер блокировать именно диапазон ключей индекса, в том числе и от вставки? 21268301 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2018, 13:08 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
invmmsLexIS допустимы, они вполне с U "уживаются"Только вот эскалация U будет до X, ибо U на таблицу не бывает. Хмм, действительно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2018, 13:11 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
msLex, спасибо, работает, sp_lock показывает, что сменился режим блокировки на RangeS-U, правда я вижу всю ту же кучу блокировок, вместо одной. Впрочем, у sp_lock в столбце type нет разделения между блокировкой по ключу и диапазону ключей. Интересна еще одна вещь: на тестовых где в таблице tbGroup чуть больше 5000 строк, запрос вида Код: sql 1. 2. вызывает 5000 блокировок с уровнем гранулярности = KEY. Почему сервер не поднимает его до уровня таблицы, ну или хотя бы страниц? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2018, 14:20 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Шамиль Фаридович, Каждая хранимая процедура создаст свой экземпляр #tbGroup. От кого вы хотите заблокировать таблицу, от самого себя? :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2018, 14:31 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Режимы блокировки: https://technet.microsoft.com/ru-ru/library/ms186396(v=sql.105).aspx ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2018, 14:35 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Совместимость блокировок (компонент Database Engine): https://technet.microsoft.com/ru-ru/library/ms186396(v=sql.105).aspx ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2018, 14:35 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Шамиль ФаридовичmsLex, спасибо, работает, sp_lock показывает, что сменился режим блокировки на RangeS-U, правда я вижу всю ту же кучу блокировок, вместо одной. Впрочем, у sp_lock в столбце type нет разделения между блокировкой по ключу и диапазону ключей. Интересна еще одна вещь: на тестовых где в таблице tbGroup чуть больше 5000 строк, запрос вида Код: sql 1. 2. вызывает 5000 блокировок с уровнем гранулярности = KEY. Почему сервер не поднимает его до уровня таблицы, ну или хотя бы страниц? 1. 5к блокировок это нечто вроде "по умолчанию", сервер расчитывает количество от нескольких параметров 2. до страниц эскалации не бывает ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2018, 14:35 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Блокировка диапазона ключей: https://technet.microsoft.com/ru-ru/library/ms191272(v=sql.105).aspx ЗЫ это просто , чтобы народ мог посмотреть как в справочник, если вдруг нить рассуждений в текущем топике потерял ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2018, 14:37 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Шамиль Фаридовичспасибо, работает, sp_lock показывает, что сменился режим блокировки на RangeS-U, правда я вижу всю ту же кучу блокировок, вместо одной Это потому, что реальный ключ неуникального индекса IX_tbGroup_OrgId (OrgId, <clustered index key>) и Range блокировки накладываются именно на него. Шамиль Фаридовичвызывает 5000 блокировок с уровнем гранулярности = KEY. Почему сервер не поднимает его до уровня таблицы, ну или хотя бы страниц? До станицы, как вам уже сказали, сервер не эскаликует блокировки, только если сразу их выберет (можно ему помочь через paglock) А до таблицы мешает любой активный селекет к данным из таблицы (если у вас не RCSI) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2018, 15:32 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Шамиль ФаридовичИ все же интересно, как заставить сервер блокировать именно диапазон ключей индекса, в том числе и от вставки?Не бывает блокировки диапазона в таком виде, в каком вы его себе представляете - одна блокировка на произвольный диапазон ключей. Блокировка диапазона в MSSQL - это блокировка (предыдущий ключ, ключ] и применяется исключительно для защиты от добавления строк в названный диапазон, чтобы обеспечить правильную работу на TIL serialiazable. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2018, 16:18 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Всем спасибо за ответы! Задача немного усложнилась. Всю постановку передавать не буду, сконцентрируюсь на одной из подзадач: необходимо в начале транзакции вставлять в таблицу Код: sql 1. 2. 3. 4. записи из таблицы #tbEventToGroup(EventId int, tbGroupId...) и защитить до конца транзакции tbEventCalculationList от вставки конкурирующими транзакциями строк с EventId из #tbEventToGroup, то есть мне нужно что-то вроде Код: sql 1. 2. 3. 4. Проблема в том, что ругается на подсказку про индекс: Код: sql 1. И я что-то не соображу, как засунуть хинт с индексом в предложение OPTION. Или INSERT вообще не позволяет таких вещей, и я смогу диапазон ключей только после вставки и вызова подходящего предложения SELECT ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2018, 11:12 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Шамиль Фаридович, по EventId уникальный индекс? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2018, 11:17 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Код: sql 1. 2. 3. 4. это ошибка? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2018, 11:18 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Konst_Oneэто ошибка? чукча не читатель? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2018, 11:20 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
ну и вообще авторThe ability to specify the HOLDLOCK, SERIALIZABLE, READCOMMITTED, REPEATABLEREAD, or UPDLOCK hints on tables that are targets of INSERT statements will be removed in a future version of SQL Server. These hints do not affect the performance of INSERT statements. Avoid using them in new development work, and plan to modify applications that currently use them. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2018, 11:27 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
TaPaKKonst_Oneэто ошибка? чукча не читатель? я выделил пробел для ТС, если что. а вы читайте дальше синтаксис неправильный (я только про это, дальше сами занимайтесь маразмом в рамках данной задачи) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2018, 11:31 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Konst_OneTaPaKпропущено... чукча не читатель? я выделил пробел для ТС, если что. а вы читайте дальше синтаксис неправильный (я только про это, дальше сами занимайтесь маразмом в рамках данной задачи) т.е. то что INDEX в хинет на insert вообще не опция(о чём и приведена ошибка), вас конечно не смущает ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2018, 11:35 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
TaPaKKonst_Oneпропущено... я выделил пробел для ТС, если что. а вы читайте дальше синтаксис неправильный (я только про это, дальше сами занимайтесь маразмом в рамках данной задачи) т.е. то что INDEX в хинет на insert вообще не опция(о чём и приведена ошибка), вас конечно не смущает так про это уже до меня сказали. или вы адвокат? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2018, 11:51 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Konst_Oneэто ошибка? Это опечатка, без пробела тоже не работает. Да, необходимо уточнить, что если в 2х параллельных транзакциях записи в таблицах #tbEventToGroup не пересекаются по EventId, то они не должны блокировать друг друга. Konst_Oneпо EventId уникальный индекс? Нет, уникальный индекс только по tbEventCalculationList.Id Вообще эта таблица в разработке, и я могу повесить на EventId кластерный индекс, если это поможет решить задачу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2018, 11:52 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Шамиль Фаридович, Кластерный индекс не делает поле уникальным. Если нет уникальности значения, то надо что бы все сесии знали что же за значения вы вставляете. А вообще бред какой-то, если первая сессия вставляет EventId1 и EventId2, вторая сессия встав EventId3, EventId1 втроую выбрасываем и теряем EventId3? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2018, 11:58 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
TaPaK если первая сессия вставляет EventId1 и EventId2, вторая сессия встав EventId3, EventId1 втроую выбрасываем и теряем EventId3? Почему выбрасываем? вторая сессия просто ждет, пока закончится первая. В то же самое время 3ья сессия с EventId4, EventId5 должна спокойно параллельно выполняться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2018, 12:04 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Шамиль Фаридович, авторвторая сессия просто ждет, пока закончится первая.зачем? в чём перформанс то? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2018, 12:05 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Хотя честно говоря, со второй сессией все так просто. В #tbEventToGroup не зря есть поле DataFormingDate. Если на момент получения блокировки окажется, что в tbEventCalculationList самая последняя запись с EventId1 имеет DataFormingDate >= #tbEventToGroup.DataFormingDate, то строка с EventId1 будет удалена из #tbEventToGroup и данные по EventId1 во второй сессии сохраняться не будут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2018, 12:09 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
TaPaKШамиль Фаридович, авторвторая сессия просто ждет, пока закончится первая.зачем? в чём перформанс то? Тут дело не производительности, а в целостности данных. Если разрешить конкурентам параллельно сохранять данные по одним и тем же EventId, то они моментально ее порушат. А еще могут потереть свежие данные старыми. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2018, 12:13 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Шамиль ФаридовичTaPaKШамиль Фаридович, пропущено... зачем? в чём перформанс то? Тут дело не производительности, а в целостности данных. Если разрешить конкурентам параллельно сохранять данные по одним и тем же EventId, то они моментально ее порушат. А еще могут потереть свежие данные старыми. у вас какая-то странная/не правильная/отвратительная архитектура. Запретите параллельную вставку и не мучайте народ реализацией костыля ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2018, 12:19 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
TaPaK, стадия 1. Отрицание (или запрет). Даже не буду обсуждать требования заказчика. Лучше вернемся к сабжу, расширю постановку. Есть некая процедура по расчету стоимостей/группировке ивентов (примерный макет в первом сообщении - важно отметить, что в ней есть 2 больших блока - расчет данных во временных таблицах и их сохранение, обернутое в транзакцию). Ивент туда может передаться как 1, так и пол таблицы tbEvent (в ней сейчас 6M записей). Естественно, что те вызовы, в которые передали меньшее количество ивентов будут отрабатывать быстрее. Более того, маленькие вызовы чаще всего обладают более актуальными данными, и большой вызов, когда наконец допрется до начала транзакции, не должен перетирать пересчитанные за время его выполнения ивенты своими потерявшими актуальность данными. Для этого я хочу сделать таблицу tbEventCalculationList, в которую каждая транзакция будет класть список пересчитанных ей ивентов. И в начале транзакции пытаться вставить в эту таблицу ивенты из #tbEventToGroup за исключением тех, что потеряли актуальность и защитить этот диапазон от конкурентов. Пока я не придумал, как это реализовать. Есть альтернативный вариант Б: таблица tbEventCalculationState, куда скопируются все строки из tbEvent(и будут далее синхронизироваться), а каждая процедура по расчету будет просто менять DataFormingDate у соответствующих ивентов. Здесь вроде все просто, вешаешь holdlock и никто твои ивенты до конца транзакции не пересчитает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2018, 12:44 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Шамиль ФаридовичБолее того, маленькие вызовы чаще всего обладают более актуальными данными, и большой вызов, когда наконец допрется до начала транзакции, не должен перетирать пересчитанные за время его выполнения ивенты своими потерявшими актуальность данными.Читайте про уровень изоляции SNAPSHOT и как там реализована защита от подобных случаев. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2018, 12:59 |
|
||
|
Заблокировать таблицу от удаления до конца транзакции
|
|||
|---|---|---|---|
|
#18+
Шамиль Фаридович, А почему последовательно не хотите обрабатывать? Отправляйте все запросы в сервис брокер и выбирайте из очереди по одному. Если уж транзакции не устраивают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2018, 13:02 |
|
||
|
|

start [/forum/topic.php?all=1&fid=46&tid=1689980]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
69ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
90ms |
get tp. blocked users: |
2ms |
| others: | 252ms |
| total: | 450ms |

| 0 / 0 |
