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

Откуда: Москва
Сообщений: 5645
есть таблица - документ, которая делает движения по другой таблице - движения.
соответственно у таблицы движения есть колонка дата, ссылка на документ, и номер строки документа, номенклатура и количество (типичная 1с 8ая версия). есть индекс на дату, ссылку, номер строкию
смотрю какие блокировки вешаются на таблицу в момент записи двух разных документов (resource_type везде 'KEY'):
_AccumReg13	_AccumReg13_ByPeriod_TRN	52	(3e0329c9b4b9)	72057594043957248	RangeS-U	GRANT
_AccumReg13 _AccumReg13_ByPeriod_TRN 52 (b3032cfbf769) 72057594043957248 RangeS-S GRANT
_AccumReg13 _AccumReg13_ByPeriod_TRN 54 (b3032cfbf769) 72057594043957248 RangeI-N CONVERT
_AccumReg13 _AccumReg13_ByPeriod_TRN 54 (b3032cfbf769) 72057594043957248 RangeS-S GRANT
_AccumReg13 _AccumReg13_ByPeriod_TRN 54 (3e0329c9b4b9) 72057594043957248 RangeS-S GRANT
в итоге блокировка теста вставки ожидает RangeI-N конвертирование в RangeS-U я так понимаю, и почемуто не получает, как следствие вылетает по ошибке. ладно бы всегда так, но:
теперь провожу еще один документ, который проводится
_AccumReg13	_AccumReg13_ByPeriod_TRN	52	(1b03d6188807)	72057594043957248	RangeS-S	GRANT
_AccumReg13 _AccumReg13_ByPeriod_TRN 52 (3e0329c9b4b9) 72057594043957248 RangeS-U GRANT
_AccumReg13 _AccumReg13_ByPeriod_TRN 54 (1b03d6188807) 72057594043957248 RangeS-U GRANT
_AccumReg13 _AccumReg13_ByPeriod_TRN 54 (3e0329c9b4b9) 72057594043957248 RangeS-S GRANT
никакой блокировки RangeI-N не вешается, и в итоге взаимного ожидания не происходит и оба документа проводятся..

запросы по выборке SELECT * FROM (SERIALIZABLE, UPDLOCK) where ссылка = GUID. и все.


для спящего время бодрствования равносильно сну
15 дек 09, 18:21    [8071321]     Ответить | Цитировать Сообщить модератору
 Re: и снова изучение блокировок  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
разобрался откуда блокировки вешались.
сортировать по кластерному ключу не надо, тогда RangeS-S вешаться не будут.

для спящего время бодрствования равносильно сну
15 дек 09, 20:13    [8071679]     Ответить | Цитировать Сообщить модератору
 Re: и снова изучение блокировок  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74927
автор
смотрю какие блокировки вешаются на таблицу в момент записи двух разных документов


как смотрите?

автор
никакой блокировки RangeI-N не вешается


И эти два документа проводятся одинаковым набором инструкций (по профайлеру)? Раз Вы говорите о регистре движений, то не происходит ли ситуации, когда в первом случае необходима вставка в таблицу движений, а во втором апдейт?
15 дек 09, 20:15    [8071696]     Ответить | Цитировать Сообщить модератору
 Re: и снова изучение блокировок  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74927
Алексей2003
разобрался откуда блокировки вешались.
сортировать по кластерному ключу не надо, тогда RangeS-S вешаться не будут.


Будут, так как у Вас SERIALIZABLE, а вот на какой индекс...
15 дек 09, 20:18    [8071710]     Ответить | Цитировать Сообщить модератору
 Re: и снова изучение блокировок  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
2pkarklin
вешались блокировки RangeS-S на ВСЕ записи таблицы. а если делать выборку по другому чуток, то только на те записи, которые в выборке...

для спящего время бодрствования равносильно сну
16 дек 09, 11:16    [8073541]     Ответить | Цитировать Сообщить модератору
 Re: и снова изучение блокировок  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
правильно ли я понимаю что блокировка
(ffffffffffff) 72057595468644352 RangeX-X
по кластерному индексу на таблицу - блокировка тупо на весь диапазон?

для спящего время бодрствования равносильно сну
16 дек 09, 11:26    [8073654]     Ответить | Цитировать Сообщить модератору
 Re: и снова изучение блокировок  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
pkarklin
автор
смотрю какие блокировки вешаются на таблицу в момент записи двух разных документов


как смотрите?

автор
никакой блокировки RangeI-N не вешается


И эти два документа проводятся одинаковым набором инструкций (по профайлеру)? Раз Вы говорите о регистре движений, то не происходит ли ситуации, когда в первом случае необходима вставка в таблицу движений, а во втором апдейт?

тут я уже разобрался. в момент проведения вешались блокировки на таблицу на все строки RangeS-S. при проведении некоторых документов осуществлялась вставка в таблицу, при проведении другой половины записи уже были и вставка не осуществлялась. в итоге блокировка на вставку вешалась как раз на первую половину и все документы отфутболивались. а те, по которым запись уже была - они нормально схлопывались по RangeS-S и RangeS-U так как они совместимы...
16 дек 09, 11:29    [8073697]     Ответить | Цитировать Сообщить модератору
 Re: и снова изучение блокировок  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
pkarklin
автор
смотрю какие блокировки вешаются на таблицу в момент записи двух разных документов


как смотрите?

тупо не завершаю транзакцию прямо в самом конце "проведения" документа и смотрю таблицу Sys.dm_tran_locks
16 дек 09, 11:30    [8073715]     Ответить | Цитировать Сообщить модератору
 Re: и снова изучение блокировок  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
есть таблица с кластерным индексом по нескольким полям (кол1, кол2, кол3)
почему при выборке с serializable если выбирать конкретные строки по (кол1, кол2) то вешается ffffffffffffffff блокировка на все записи RangeS-S?

для спящего время бодрствования равносильно сну
16 дек 09, 13:27    [8075001]     Ответить | Цитировать Сообщить модератору
 Re: и снова изучение блокировок  [new]
Glory
Member

Откуда:
Сообщений: 104760
Алексей2003
есть таблица с кластерным индексом по нескольким полям (кол1, кол2, кол3)
почему при выборке с serializable если выбирать конкретные строки по (кол1, кол2) то вешается ffffffffffffffff блокировка на все записи RangeS-S?

Ну так кол1, кол2 - это же несколько записей, т.е. даиапазон
16 дек 09, 13:31    [8075029]     Ответить | Цитировать Сообщить модератору
 Re: и снова изучение блокировок  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
а почему бы не вешать только на этот диапазон индекса такую блокировку? а не всю таблицу...
т.е.
А1 Б1 В1
А1 Б1 В2
А2 Б1 В1
А2 Б1 В2
я выбираю А1 + Б1
в итоге залочить KEY по А1 Б1 В1 и А1 Б1 В2, а не всю таблицу...

для спящего время бодрствования равносильно сну
16 дек 09, 13:42    [8075121]     Ответить | Цитировать Сообщить модератору
 Re: и снова изучение блокировок  [new]
Glory
Member

Откуда:
Сообщений: 104760
Алексей2003
а почему бы не вешать только на этот диапазон индекса такую блокировку? а не всю таблицу...
т.е.
А1 Б1 В1
А1 Б1 В2
А2 Б1 В1
А2 Б1 В2
я выбираю А1 + Б1
в итоге залочить KEY по А1 Б1 В1 и А1 Б1 В2, а не всю таблицу...


Какой диапазон попал под скан при serializable, такой и заблокировался. Потому что serializable как раз и требует такого обращения с данными
16 дек 09, 13:48    [8075173]     Ответить | Цитировать Сообщить модератору
 Re: и снова изучение блокировок  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
а если при этом был Clustered Seek?
StmtText                                                                                                                                                                                                                                                                                                             
Top(TOP EXPRESSION:((20000)))
|--Clustered Index Seek(OBJECT:([ddd].[dbo].[_InfoReg17664].[_InfoR17664_ByPeriod_TR]), SEEK:([ddd].[dbo].[_InfoReg17664].[_Period]=[@P1] AND [ddd].[dbo].[_InfoReg17664].[_Fld17665_TYPE]=[@P2] AND [ddd].[dbo].[_InfoReg17664].[_Fld17665_RTRef]=[@P3] AND [ddd].[dbo].[_InfoReg17664].[_Fld17665_RRRef]=[@P4]) ORDERED FORWARD)
exec sp_executesql N'SELECT TOP 20000
_InfoReg17664._Period AS f_1,
_InfoReg17664._Fld17665_TYPE AS f_2,
_InfoReg17664._Fld17665_RTRef AS f_3,
_InfoReg17664._Fld17665_RRRef AS f_4,
_InfoReg17664._Fld17667 AS f_5,
_InfoReg17664._Fld20435RRef AS f_6
FROM
_InfoReg17664 WITH(SERIALIZABLE)
WHERE
_InfoReg17664._Period = @P1 AND _InfoReg17664._Fld17665_TYPE = @P2 AND _InfoReg17664._Fld17665_RTRef = @P3 AND _InfoReg17664._Fld17665_RRRef = @P4
ORDER BY
_InfoReg17664._Period,
_InfoReg17664._Fld17665_TYPE,
_InfoReg17664._Fld17665_RTRef,
_InfoReg17664._Fld17665_RRRef',N'@P1 datetime,@P2 varbinary(1),@P3 varbinary(4),@P4 varbinary(16)',''2009-12-16 14:09:36:000'',0x08,0x000001F5,0x8F9E00248CE6CA5111DEC2356C2BDF7C
вешается блокировка ffffffffffffffff сразу и привет. все что в отборе - кластерный индекс...

для спящего время бодрствования равносильно сну
16 дек 09, 14:11    [8075352]     Ответить | Цитировать Сообщить модератору
 Re: и снова изучение блокировок  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
ЗЫ при этом записей в таблице НЕТУ... поэтому и блок на всю таблицу, да?

для спящего время бодрствования равносильно сну
16 дек 09, 14:15    [8075396]     Ответить | Цитировать Сообщить модератору
 Re: и снова изучение блокировок  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
точнее нет на указанную дату

для спящего время бодрствования равносильно сну
16 дек 09, 14:18    [8075423]     Ответить | Цитировать Сообщить модератору
 Re: и снова изучение блокировок  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74927
Алексей2003
ЗЫ при этом записей в таблице НЕТУ... поэтому и блок на всю таблицу, да?



C чего Вы решили, что блок на всю таблицу?! Блокируется диапазон, что не дает возможности вставить записи, которые могли бы попасть в этот диапазон.
16 дек 09, 14:21    [8075450]     Ответить | Цитировать Сообщить модератору
 Re: и снова изучение блокировок  [new]
Glory
Member

Откуда:
Сообщений: 104760
Алексей2003
ЗЫ при этом записей в таблице НЕТУ... поэтому и блок на всю таблицу, да?

для спящего время бодрствования равносильно сну

serializable требует, чтобы запрос на протяжении всей транзакции всегда возвращал одинаковый результат. И блокировки нужны именно для того, чтобы единожды прочитанные данные никто не мог изменить. В том числе и через добавление в прочитанный диапазон новых записей
16 дек 09, 14:22    [8075453]     Ответить | Цитировать Сообщить модератору
 Re: и снова изучение блокировок  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
pkarklin
Алексей2003
ЗЫ при этом записей в таблице НЕТУ... поэтому и блок на всю таблицу, да?



C чего Вы решили, что блок на всю таблицу?! Блокируется диапазон, что не дает возможности вставить записи, которые могли бы попасть в этот диапазон.

диапазон fffffffffffffffff - вся таблица...
16 дек 09, 14:29    [8075524]     Ответить | Цитировать Сообщить модератору
 Re: и снова изучение блокировок  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
Glory
Алексей2003
ЗЫ при этом записей в таблице НЕТУ... поэтому и блок на всю таблицу, да?

для спящего время бодрствования равносильно сну

serializable требует, чтобы запрос на протяжении всей транзакции всегда возвращал одинаковый результат. И блокировки нужны именно для того, чтобы единожды прочитанные данные никто не мог изменить. В том числе и через добавление в прочитанный диапазон новых записей

понял. буду учитывать.
16 дек 09, 14:30    [8075537]     Ответить | Цитировать Сообщить модератору
 Re: и снова изучение блокировок  [new]
daw
Member

Откуда: Муром -> Москва
Сообщений: 7381

> диапазон fffffffffffffffff - вся таблица...

с чего вы взяли?
каждая Range блокировка, она между двумя соседними ключами всегда.
включая конечный и не включая начальный.
а fffffffffffffffff означает, что конечного просто нет.
то есть блокируется диапазон больше максимального значения в индексе.

Posted via ActualForum NNTP Server 1.4

16 дек 09, 14:41    [8075660]     Ответить | Цитировать Сообщить модератору
 Re: и снова изучение блокировок  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
daw

> диапазон fffffffffffffffff - вся таблица...

с чего вы взяли?
каждая Range блокировка, она между двумя соседними ключами всегда.
включая конечный и не включая начальный.
а fffffffffffffffff означает, что конечного просто нет.
то есть блокируется диапазон больше максимального значения в индексе.

ага, уже яснее. т.е. если я заведомо сделаю в таблице запись старше диапазона, то блокировок удастся избежать..
16 дек 09, 14:47    [8075719]     Ответить | Цитировать Сообщить модератору
 Re: и снова изучение блокировок  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74927
Алексей2003
диапазон fffffffffffffffff - вся таблица...


В первом коннекте:

USE tempdb
GO

CREATE TABLE T1(col1 int NOT NULL PRIMARY KEY CLUSTERED)
GO

INSERT T1 VALUES(1)
INSERT T1 VALUES(2)
INSERT T1 VALUES(3)
INSERT T1 VALUES(4)
GO
BEGIN TRAN
SELECT
  *
FROM
  T1 WITH(SERIALIZABLE)
WHERE
  col1 >5

EXEC sp_lock @@spid

spiddbidObjIdIndIdTypeResourceModeStatus
52221210585921PAG1:174ISGRANT
52221210585921KEY(ffffffffffff)RangeS-SGRANT
52221210585920TABISGRANT
52111151510180TABISGRANT


Во втором:

INSERT T1 VALUES(-1)
GO
SELECT * FROM T1

col1
-1
1
2
3
4


В первом:

COMMIT 
GO
DROP TABLE T1
16 дек 09, 14:49    [8075740]     Ответить | Цитировать Сообщить модератору
 Re: и снова изучение блокировок  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
pkarklin
Алексей2003
диапазон fffffffffffffffff - вся таблица...


В первом коннекте:

USE tempdb
GO

CREATE TABLE T1(col1 int NOT NULL PRIMARY KEY CLUSTERED)
GO

INSERT T1 VALUES(1)
INSERT T1 VALUES(2)
INSERT T1 VALUES(3)
INSERT T1 VALUES(4)
GO
BEGIN TRAN
SELECT
  *
FROM
  T1 WITH(SERIALIZABLE)
WHERE
  col1 >5

EXEC sp_lock @@spid

spiddbidObjIdIndIdTypeResourceModeStatus
52221210585921PAG1:174ISGRANT
52221210585921KEY(ffffffffffff)RangeS-SGRANT
52221210585920TABISGRANT
52111151510180TABISGRANT


Во втором:

INSERT T1 VALUES(-1)
GO
SELECT * FROM T1

col1
-1
1
2
3
4


В первом:

COMMIT 
GO
DROP TABLE T1

да я уже понял. и нашел как можно "обойти" эту проблему со вставкой в таблицу...
16 дек 09, 14:52    [8075784]     Ответить | Цитировать Сообщить модератору
 Re: и снова изучение блокировок  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
всем спасибо =)

для спящего время бодрствования равносильно сну
16 дек 09, 14:54    [8075807]     Ответить | Цитировать Сообщить модератору
 Re: и снова изучение блокировок  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
в resource_description хранится хэш диапазона я так понимаю.. значение этого диапазона никак не посмотреть кроме как построчной выборкой?

для спящего время бодрствования равносильно сну
16 дек 09, 16:13    [8076518]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить