ReSQL.ru
     
powered by simpleCommunicator - 2.0.52     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Оптимальна ли блокировка RangeS-U для ресурса (ffffffffffff)?
13 сообщений из 13, страница 1 из 1
Оптимальна ли блокировка RangeS-U для ресурса (ffffffffffff)?
    #40008304
ddzia
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ddzia
Гость
Имеется таблица со следующей схемой и данными:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
create database Example
go

use Example
create table Orders
(
	[Id] INT NOT NULL
	,[Description] VARCHAR(48) NOT NULL

	,CONSTRAINT PK_Orders_Id PRIMARY KEY ([Id])
)
go

insert into Orders values (1, '1 desc'), (2, '2 desc')
go



Выполним следующий скрипт:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
use Example
begin tran
	select * from orders with(updlock, serializable, index(PK_Orders_Id)) where id = 12 -- такой записи(ресурса) не существует
	select
		resource_type
		,resource_description
		,request_mode
		,request_type
		,request_status
	from sys.dm_tran_locks
		where resource_type <> 'DATABASE'
		AND resource_database_id = DB_ID('Example')
rollback
go



Выполнив запрос, были получены следующие блокировки:


Вопрос : правильно ли я понимаю, что блокировка RangeS-U , для несуществующих записей, всегда установливает блокировку для ресурса (ffffffffffff) ? Если да, тогда получаем что, транзакции выполняющие вставку новых записей, предварительно выполнив блокировку RangeS-U , всегда будут конкурировать за блокировку одного и того-же ресурса (ffffffffffff) (что должно привести к "просадке" производительности)? Кстати, что это за такой ресурс (ffffffffffff) ?
...
Рейтинг: 0 / 0
14.10.2020, 01:47
| Ответить | Цитировать | Написать  
Оптимальна ли блокировка RangeS-U для ресурса (ffffffffffff)?
    #40008305
Гавриленко Сергей Алексеевич
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гавриленко Сергей Алексеевич
Участник
А вы вообще в курсе, зачем нужен IL = serializable?
...
Рейтинг: 0 / 0
14.10.2020, 02:05
| Ответить | Цитировать | Написать  
Оптимальна ли блокировка RangeS-U для ресурса (ffffffffffff)?
    #40008306
ddzia
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ddzia
Гость
Гавриленко Сергей Алексеевич, почему вы решили что "нет"? Лучше конечно ответьте на мой основной вопрос, если знаете ответ, или поправьте меня, если я где-то не прав в описаниях своих.
...
Рейтинг: 0 / 0
14.10.2020, 02:12
| Ответить | Цитировать | Написать  
Оптимальна ли блокировка RangeS-U для ресурса (ffffffffffff)?
    #40008307
Гавриленко Сергей Алексеевич
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гавриленко Сергей Алексеевич
Участник
ddzia
Гавриленко Сергей Алексеевич, почему вы решили что "нет"?
Потому что вы задаете вопросы, которые сигнализируют, что вы не понимаете о чем речь.
ddzia
Лучше конечно ответьте на мой основной вопрос
Я лучше посплю пойду, чем буду ломать голову над тем, который же их ваших трех заданных вопросов является "основным".
ddzia
если знаете ответ.
А вот этот вот развод на "слабо" вы лучше для преподавателя вашего оставьте, ага.
...
Рейтинг: 0 / 0
14.10.2020, 02:19
| Ответить | Цитировать | Написать  
Оптимальна ли блокировка RangeS-U для ресурса (ffffffffffff)?
    #40008308
ddzia
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ddzia
Гость
Попрвьате, если не прав:

на самом деле (ffffffffffff) не ресурс, а функция блокировки диапазона ключей индекса, для которых была взята блокировка из первого select, хинтом serializable .
...
Рейтинг: 0 / 0
14.10.2020, 02:23
| Ответить | Цитировать | Написать  
Оптимальна ли блокировка RangeS-U для ресурса (ffffffffffff)?
    #40008310
felix_ff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
felix_ff
Участник
ddzia,

(ffffffffffff) - это максимальное значение диапазона возможных ключей.

при TIL seriazlizable ключевое слово "диапазон"


посмотрите как будут меняться блокировки в таком варианте тогда поймете почему блокируется предельное значение
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
delete from Orders;
insert into Orders values (1, '1 desc'), (2, '2 desc'), (3, '3 desc');

begin tran
select %%lockres%%, [Id], [Description] from [Orders] with (serializable) where [Id] <= 1;
select * from sys.dm_tran_locks where request_session_id = @@SPID and [resource_type] = 'KEY';

select %%lockres%%, [Id], [Description] from [Orders] with (serializable) where [Id] <= 2;
select * from sys.dm_tran_locks where request_session_id = @@SPID and [resource_type] = 'KEY';

select %%lockres%%, [Id], [Description] from [Orders] with (serializable) where [Id] <= 3;
select * from sys.dm_tran_locks where request_session_id = @@SPID and [resource_type] = 'KEY';

commit;
...
Рейтинг: 0 / 0
14.10.2020, 03:32
| Ответить | Цитировать | Написать  
Оптимальна ли блокировка RangeS-U для ресурса (ffffffffffff)?
    #40008408
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владислав Колосов
Участник
felix_ff,

а почему "прихватывается" ключ, который не требуется для защиты диапазона?
...
Рейтинг: 0 / 0
14.10.2020, 12:57
| Ответить | Цитировать | Написать  
Оптимальна ли блокировка RangeS-U для ресурса (ffffffffffff)?
    #40008413
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
msLex
Участник
Владислав Колосов
felix_ff,

а почему "прихватывается" ключ, который не требуется для защиты диапазона?

В каком случае?
...
Рейтинг: 0 / 0
14.10.2020, 13:00
| Ответить | Цитировать | Написать  
Оптимальна ли блокировка RangeS-U для ресурса (ffffffffffff)?
    #40008423
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владислав Колосов
Участник
msLex,

например:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
delete from Orders;
insert into Orders values (2, '1 desc'), (3, '2 desc'), (5, '3 desc');

begin tran
-- блокируется 2
select %%lockres%%, [Id], [Description] from [Orders] with (serializable) where [Id] < 1;
select * from sys.dm_tran_locks where request_session_id = @@SPID and [resource_type] = 'KEY';

-- блокируется 2
select %%lockres%%, [Id], [Description] from [Orders] with (serializable) where [Id] < 2;
select * from sys.dm_tran_locks where request_session_id = @@SPID and [resource_type] = 'KEY';

-- блокируется 2,3,5
select %%lockres%%, [Id], [Description] from [Orders] with (serializable) where [Id] < 5;
select * from sys.dm_tran_locks where request_session_id = @@SPID and [resource_type] = 'KEY';

commit;
...
Рейтинг: 0 / 0
14.10.2020, 13:14
| Ответить | Цитировать | Написать  
Оптимальна ли блокировка RangeS-U для ресурса (ffffffffffff)?
    #40008424
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
invm
Участник
Владислав Колосов,

Потому что используется единый механизм для уникальных и неуникальных индексов.
А в случае неуникального индекса, из-за наличия уникализатора, обязательно нужно блокировать следующий диапазон.
...
Рейтинг: 0 / 0
14.10.2020, 13:18
| Ответить | Цитировать | Написать  
Оптимальна ли блокировка RangeS-U для ресурса (ffffffffffff)?
    #40008426
felix_ff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
felix_ff
Участник
Владислав Колосов,

Так это и есть смысл блокировки "диапазона ключей"

он должен обеспечить гарантию защиты все диапазона. верхняя его планка будет не значением условно последней строки вашего предиката а значением большим на 1.


ну к примеру: (я сейчас образно нарисую что бы не рисовать "ключи" в виде хексов)


есть у вас таблица
id lockres11000210103102041030

если вы напишите
Код: sql
1.
select [id] from [tbl] with(serializable) where [id] < 3



Вам возвратится 2 id: 1, 2
при этом ключи будут заблокированы по диапазону 1000-1020
почему спросите блокируется ключ 1020 если он не попадает в предикат?
а представьте такую ситуацию

Код: sql
1.
2.
3.
    begin tran
       select [id] from [tbl] with (serializable) where [id] < 3;
       insert into [tbl] values (2); --в этой или какой либо другой сессии



сразу опускаем условие что используется первичный ключ
должна будет появится новая строка у которой [id] попадает под защиту "диапазона", что бы гарантировать такую защиту SQL не может явно взять только блокировки на 1000-1010, он должен потенциально защитится от новых вставок и что бы обеспечить такую защиту он берет блокировку на ключ больший
...
Рейтинг: 0 / 0
14.10.2020, 13:25
| Ответить | Цитировать | Написать  
Оптимальна ли блокировка RangeS-U для ресурса (ffffffffffff)?
    #40008433
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владислав Колосов
Участник
Спасибо, понятно. Упустил из вида, что сервер занимается "приписками" для уникальности. То есть возможна ситуация, когда вставляемая двойка может быть больше, чем уже вставленная, но меньше тройки.
...
Рейтинг: 0 / 0
14.10.2020, 13:45
| Ответить | Цитировать | Написать  
Оптимальна ли блокировка RangeS-U для ресурса (ffffffffffff)?
    #40008437
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
invm
Участник
felix_ff
он должен обеспечить гарантию защиты все диапазона. верхняя его планка будет не значением условно последней строки вашего предиката а значением большим на 1.
В случае уникального индекса этого не требуется, ибо диапазон ключей всегда (предыдущий ключ, ключ].

В данном конкретном случае такой эффект связан с направлением сканирования индекса.
Если напишите
Код: sql
1.
select %%lockres%%, [Id], [Description] from [Orders] with (serializable) where [Id] <= 1 order by id desc

будет заблокирован только один диапазон
...
Рейтинг: 0 / 0
14.10.2020, 13:49
| Ответить | Цитировать | Написать  
13 сообщений из 13, страница 1 из 1
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Оптимальна ли блокировка RangeS-U для ресурса (ffffffffffff)?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=46&msg=40008437&tid=1685537]:
 0ms
get settings:
 12ms
get forum list:
 14ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 31ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 53ms
get tp. blocked users:
 2ms
others: 17ms
total:  149ms
созд. / загр.: 149ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]