Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Оптимальна ли блокировка RangeS-U для ресурса (ffffffffffff)? / 13 сообщений из 13, страница 1 из 1
14.10.2020, 01:47
    #40008304
ddzia
ddzia
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимальна ли блокировка RangeS-U для ресурса (ffffffffffff)?
Имеется таблица со следующей схемой и данными:

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

на самом деле (ffffffffffff) не ресурс, а функция блокировки диапазона ключей индекса, для которых была взята блокировка из первого select, хинтом serializable .
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
14.10.2020, 03:32
    #40008310
felix_ff
felix_ff
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимальна ли блокировка RangeS-U для ресурса (ffffffffffff)?
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, 12:57
    #40008408
Владислав Колосов
Владислав Колосов
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимальна ли блокировка RangeS-U для ресурса (ffffffffffff)?
felix_ff,

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

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

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

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

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

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

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

будет заблокирован только один диапазон
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Оптимальна ли блокировка RangeS-U для ресурса (ffffffffffff)? / 13 сообщений из 13, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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