Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
lock
|
|||
|---|---|---|---|
|
#18+
Никак не могу понять как в скл сервере работают блокировки. Допустим есть таблица T с 3 полями INT A, B, C. Без индексов. И там 4 записи, у двух например в поле А значение 1. Уровень транзакций - READ COMMITTED. Что происходит при выполнении запроса: Код: sql 1. ? Допустим каждая запись это ROW. Начинается TABLE SCAN. 1.Попытка установить блокировку U на ROW1. Если успешно идем дальше, нет - ждем. 2.Аналогично для ROW2 3.Аналогично для ROW3 4.Аналогично для ROW4 То есть в какой то момент на всех записях стоит U? Либо на каждом шаге проверяется условие и только тогда ставится U? В какой момент она заменятся на Х? перед самым коммитом? Собственно если параллельно выполнить запрос Код: sql 1. То при условии что записи будут блокироваться в разном порядке возможен дедлок? Селект наткнулся на ROW на котором апдейт уже оставил U, в то же время апдейт не сможет сделать из U->X тк на записи стоит S от селекта? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2019, 21:58 |
|
||
|
lock
|
|||
|---|---|---|---|
|
#18+
no56892 Либо на каждом шаге проверяется условие и только тогда ставится U? В какой момент она заменятся на Х? перед самым коммитом? В вашем конкретном случае сканирования кучи, упрощенно: - на строку ставится U - если строка удовлетворяет предикату, U конвертируется в X и значение столбца обновляется, иначе U снимается. И так для каждой сканируемой строки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2019, 22:31 |
|
||
|
lock
|
|||
|---|---|---|---|
|
#18+
no56892 Собственно если параллельно выполнить запрос Код: sql 1. То при условии что записи будут блокироваться в разном порядке возможен дедлок? Селект наткнулся на ROW на котором апдейт уже оставил U, в то же время апдейт не сможет сделать из U->X т.к. на записи стоит S от селекта? Если select в serializable, а update по-прежнему в read committed, deadlock тоже не случается: select не снимает наложенный S-lock до завершения транзакции, но update снимает X-lock после каждого изменения. Что бы ни делал update, select рано или поздно прочитает всё что ему нужно и снимет свой S-lock, после чего update сможет продолжить и завершить свою работу. Deadlock-и возникают, когда оба конкурирующих процесса в repeatable read и выше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2019, 01:16 |
|
||
|
lock
|
|||
|---|---|---|---|
|
#18+
no56892, добавлю к ответившим: что бы лучше понять механизм блокировок запустите на тестовых вариациях запросов трассироку/xevent на события lock:aquired/lock:released. тогда вы будете видеть наглядную картину что происходит в момент наложения/снятия блокировок ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2019, 03:35 |
|
||
|
lock
|
|||
|---|---|---|---|
|
#18+
no56892, Дополню. Дедлочность select- update (в смысле читатель - писатель) зависит от множества факторов: наличия индексов, TIL читателя, хинтов в запросе, порядка просмотра записей. Утверждение Gerros Deadlock-и возникают, когда оба конкурирующих процесса в repeatable read и выше. Дедлочить может и когда читатель на read committed. Для писателя же TIL практически не важен. В вашем конкретном случае (таблица-куча без индексов) дедлока не будет, потому что читатель не накладывает более одной блокировки при обработке строки и не удерживает ее до конца транзакции. Изучать процессы блокирования с помощью Extended Events, ИМХО, слишком накладно. Гораздо проще в SSMS вот так (само-собой в тестовом окружении): Код: 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. 30. 31. 32. 33. Результаты будут на вкладке messages ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2019, 14:21 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39887035&tid=1686988]: |
0ms |
get settings: |
7ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
140ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
35ms |
get tp. blocked users: |
1ms |
| others: | 234ms |
| total: | 443ms |

| 0 / 0 |
