Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Управление блокировками RID/KEY  [new]
LIKAN_BLK
Member

Откуда:
Сообщений: 9
В SQL новичек, так что не бить. Изучаю уровни изолированности. Так вот разбираясь с "потерянными обновлениями" обнаружил одну забавную штуку. Когда одна транзакция делает update на одну строку, то другая транзакция вынуждена ждать, хотя делает update совсем другой строки. В Activity Monitor посмотрел, и увидел что тип монопольной блокировки, которую ставит 1-ая транзакиця - KEY. На форуме уже было пару тем, о том как устанавливать построчные блокировки, но ответа я так и не нашел. with (rowlock) не помогло, как и не помогло отключение опции "Use page locks when accessing the index". Как я понял блокировка устанавливается на весь узел дерева, а так как табличка очень маленькая(~10 записей), то он вся расположена в одном узле(Я верно понял?). Так вот собственно вопрос, есть ли в такой ситуации способ понизить уровень гранулярности?
30 ноя 12, 22:18    [13559392]     Ответить | Цитировать Сообщить модератору
 Re: Управление блокировками RID/KEY  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37202
Какая структура у таблицы?
Какой план у обоих апдейтов?
Какую блокировку пытается наложить ожидающий апдейт?
30 ноя 12, 22:40    [13559478]     Ответить | Цитировать Сообщить модератору
 Re: Управление блокировками RID/KEY  [new]
Crimean
Member

Откуда:
Сообщений: 13147
а вы нас не обманываете? готовим данные:

-- drop table dbo.a1
-- create table dbo.a1 ( id int primary key , flag int )
-- insert into dbo.a1 select 1, 1
-- insert into dbo.a1 select 2, 2
-- insert into dbo.a1 select 3, 3


кверя 1:

begin tran
update dbo.a1 set flag = flag * 10 where id = 1


кверя 2:

begin tran
update dbo.a1 set flag = flag / 10 where id = 2


обе квери:

(1 row(s) affected)

(1 row(s) affected)

теперь спокойно делаем commit в обоих и видим:

select * from dbo.a1

id          flag        
----------- ----------- 
          1          10 
          2           0 
          3           3 

(3 row(s) affected)


как видите - никто никого не ждет
30 ноя 12, 22:46    [13559509]     Ответить | Цитировать Сообщить модератору
 Re: Управление блокировками RID/KEY  [new]
LIKAN_BLK
Member

Откуда:
Сообщений: 9
Эмм, чем я могу подтвердить свою добросовестность? Мне видео снимать?
На таблице сравнительно большого размера кстати все работало на ура.
1 дек 12, 20:55    [13562553]     Ответить | Цитировать Сообщить модератору
 Re: Управление блокировками RID/KEY  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31824
LIKAN_BLK
Эмм, чем я могу подтвердить свою добросовестность? Мне видео снимать?
Лучше показать скрипты создания таблиц, запросы на обновление и данные о блокировках для этих двух коненктов.
1 дек 12, 20:59    [13562567]     Ответить | Цитировать Сообщить модератору
 Re: Управление блокировками RID/KEY  [new]
LIKAN_BLK
Member

Откуда:
Сообщений: 9
Ну вот собственно скриншоты.
http://rghost.ru/41937928
Устройство таблицы, её заполнение, ну и собственно процесс, первый клиент выполняет update, получает отчет об успешном выполнении, второй клиент делает update на другую строку, ничего не получает, ну и блокировки, которые накладывает первый процесс, и пытается наложить второй, вроде все.
1 дек 12, 21:21    [13562619]     Ответить | Цитировать Сообщить модератору
 Re: Управление блокировками RID/KEY  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37202
LIKAN_BLK
Ну вот собственно скриншоты.
http://rghost.ru/41937928
Устройство таблицы, её заполнение, ну и собственно процесс, первый клиент выполняет update, получает отчет об успешном выполнении, второй клиент делает update на другую строку, ничего не получает, ну и блокировки, которые накладывает первый процесс, и пытается наложить второй, вроде все.
А текстовыми скриптами прямо в форум слабо?
1 дек 12, 22:25    [13562836]     Ответить | Цитировать Сообщить модератору
 Re: Управление блокировками RID/KEY  [new]
Crimean
Member

Откуда:
Сообщений: 13147
*телепатствую*: там конкурентное изменение индексированного поля. явное или неявное
1 дек 12, 23:02    [13562920]     Ответить | Цитировать Сообщить модератору
 Re: Управление блокировками RID/KEY  [new]
SIMPLicity_
Member

Откуда: (((@)))
Сообщений: 8836
... неа, там круче - в обоих запросах идентичной where - услови на апдейт.
Странно было бу если бы скуль таки просрался...

PS Хотя, скорее всего, ТС просто неправильный скриншот закинул в архив...
PPS Ну и нет развёртки вкладки с ключами на таблице ТС...
PPPS И вообще, скуль мог вздрючить блокировку (например, поднять до уровня таблицы), если это ему выгодно...
1 дек 12, 23:20    [13562958]     Ответить | Цитировать Сообщить модератору
 Re: Управление блокировками RID/KEY  [new]
LIKAN_BLK
Member

Откуда:
Сообщений: 9
Мне сказали скринами, я делаю скринами, сказали б скриптами сделал бы скриптами
1 дек 12, 23:28    [13562978]     Ответить | Цитировать Сообщить модератору
 Re: Управление блокировками RID/KEY  [new]
LIKAN_BLK
Member

Откуда:
Сообщений: 9
Я конечно же прошу прощения за косяк, но вы тоже могли бы не злорадствовать, там не where одинаковые, там скрины одинаковые, могли бы заметить
Вот тут все ок http://rghost.ru/41941250
1 дек 12, 23:35    [13563001]     Ответить | Цитировать Сообщить модератору
 Re: Управление блокировками RID/KEY  [new]
LIKAN_BLK
Member

Откуда:
Сообщений: 9
create table Магазин(
Номер_магазина int not null IDENTITY,
Название_магазина varchar(40) not null,
Адрес_магазина varchar(100) not null,
Дата_начала_сотрудничества datetime null,
Наиболее_ходовой_товар varchar(20) null,
Частота_оформления_требований int null,
primary key(Номер_магазина),
unique(Адрес_магазина)
);

Поле неиндексируемое.
Я прошу прощения за безграмотность, но что такое скуль?
1 дек 12, 23:58    [13563069]     Ответить | Цитировать Сообщить модератору
 Re: Управление блокировками RID/KEY  [new]
Гость333
Member

Откуда:
Сообщений: 3683
LIKAN_BLK,
Смотрите, что происходит. Вы апдейтите неиндексированное поле. Согласно плану запроса, делается Clustered Index Scan таблицы Магазин с условием "where Название_магазина = @переменная". Это значит, что MSSQL последовательно перебирает (сканирует) все строки таблицы и проверяет, не подходит ли текущая строка под условие WHERE. Первый запрос просканировал все строки таблицы, проапдейтил строку с названием магазина = fifth и блокирует её (поскольку транзакция не завершена). Второй запрос также сканирует строки таблицы. Дойдя до строки 5, запрос не может прочитать Название_магазина (не может проверить условие WHERE Название_магазина = first), т.к. блокировка ещё не снята. Поэтому и повисает ожидание.

LIKAN_BLK
В Activity Monitor посмотрел, и увидел что тип монопольной блокировки, которую ставит 1-ая транзакиця - KEY. На форуме уже было пару тем, о том как устанавливать построчные блокировки, но ответа я так и не нашел. with (rowlock) не помогло

Судя по этому тексту и по заголовку темы, построчная блокировка в вашем понимании -- это RID? Ну тогда сообщу новость, что KEY -- это тоже строчная блокировка. Кстати, в данном случае блокировку по RID'у никак не получить, потому что RID -- это идентификатор строки в таблице-куче (heap). А у вас таблица с кластерным индексом, для неё строчные блокировки могут быть только по KEY.

LIKAN_BLK
что такое скуль?

"скуль" = "SQL". Жаргон такой кулхацкерский. Не обращайте внимания.
2 дек 12, 20:56    [13565321]     Ответить | Цитировать Сообщить модератору
 Re: Управление блокировками RID/KEY  [new]
Абалдей
Guest
Гость333,
и как быть в этом случае?
15 апр 13, 23:25    [14184519]     Ответить | Цитировать Сообщить модератору
 Re: Управление блокировками RID/KEY  [new]
edyaN
Member

Откуда: Berlin
Сообщений: 185
Абалдей
Гость333,
и как быть в этом случае?
позволю себе ответить:
надо построить такой индекс, чтобы не было необходимости читать залоченные данные.
пример Crimean'a это наглядно показал.
16 апр 13, 14:52    [14187325]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить