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

Откуда:
Сообщений: 14
Коллеги,

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

Deadlock encountered .... Printing deadlock information
2006-02-16 10:35:51.49 spid4
2006-02-16 10:35:51.49 spid4 Wait-for graph
2006-02-16 10:35:51.49 spid4
2006-02-16 10:35:51.49 spid4 Node:1
2006-02-16 10:35:51.49 spid4 KEY: 7:1846323129:1 (11007c4279f1) CleanCnt:1 Mode: X Flags: 0x0
2006-02-16 10:35:51.49 spid4 Grant List 0::
2006-02-16 10:35:51.49 spid4 Owner:0x19509a20 Mode: X Flg:0x0 Ref:0 Life:02000000 SPID:55 ECID:0
2006-02-16 10:35:51.49 spid4 SPID: 55 ECID: 0 Statement Type: SELECT Line #: 1
2006-02-16 10:35:51.49 spid4 Input Buf: RPC Event: sp_executesql;1
2006-02-16 10:35:51.49 spid4 Requested By:
2006-02-16 10:35:51.49 spid4 ResType:LockOwner Stype:'OR' Mode: S SPID:52 ECID:0 Ec:(0x19527568) Value:0x19509360 Cost:(0/272C)
2006-02-16 10:35:51.49 spid4
2006-02-16 10:35:51.49 spid4 Node:2
2006-02-16 10:35:51.49 spid4 RID: 7:3:1127:12 CleanCnt:1 Mode: X Flags: 0x2
2006-02-16 10:35:51.49 spid4 Grant List 0::
2006-02-16 10:35:51.49 spid4 Owner:0x193a3dc0 Mode: X Flg:0x0 Ref:0 Life:02000000 SPID:52 ECID:0
2006-02-16 10:35:51.49 spid4 SPID: 52 ECID: 0 Statement Type: SELECT Line #: 1
2006-02-16 10:35:51.49 spid4 Input Buf: RPC Event: sp_executesql;1
2006-02-16 10:35:51.49 spid4 Requested By:
2006-02-16 10:35:51.49 spid4 ResType:LockOwner Stype:'OR' Mode: S SPID:55 ECID:0 Ec:(0x19925568) Value:0x19509cc0 Cost:(0/744)
2006-02-16 10:35:51.49 spid4 Victim Resource Owner:
2006-02-16 10:35:51.49 spid4 ResType:LockOwner Stype:'OR' Mode: S SPID:55 ECID:0 Ec:(0x19925568) Value:0x19509cc0 Cost:(0/744)
2006-02-16 10:35:57.49 spid4

RID: 7:3:1127:12 - таблица ASSTEDCTX_5 (есть некластерный РК)

KEY: 7:1846323129:1 - кластерный индекс (по USERID) для таблицы AR_ASSET_5 (есть некластерный РК)

изоляция red committed

обе транзакции в файле

Гена

К сообщению приложен файл (deadlock.sql - 28Kb) cкачать
16 фев 06, 14:14    [2362980]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock без прямого пересечения по данным  [new]
Crimean
Member

Откуда:
Сообщений: 13148
нет желания разбираться в этом хаосе
пустите трасер со "стейтмент стартед", чтобы точно знать какие команды пересеклись между собой

и ответьте - задлянафига вы там rowlock влепили?
16 фев 06, 15:11    [2363348]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock без прямого пересечения по данным  [new]
`
Guest
а вы не слышали про дедлок индекса и таблицы?
примерная сутуация - один процес - индекс скан- блокировка индеса -блокировка строки(страницы)
другой процес - фулл скан -блокировка строки(страницы) -блокировка индекса - вот вам и дедлок
16 фев 06, 15:27    [2363473]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock без прямого пересечения по данным  [new]
NGL
Member

Откуда:
Сообщений: 14
в аттаче и есть результат трэйса

победитель
....
INSERT INTO ASSTEDCTX_5
.....
SELECT assets.STATE, assets.USERID, assetdata.ASSETDAT FROM AR_ASSET_5 assets, AR_ASSETDAT_5 assetdata WHERE assets.ASSETID = assetdata.ASSETID AND assets.ASSETSRCID = assetdata.ASSETSRCID AND assets.ASSETID = @0 AND assets.ASSETSRCID = @1

селект по некластерному РК (ASSETSRCID, ASSETID)
----------------------------------------

жертва
....
UPDATE AR_ASSET_5 SET COMPLETER = @0, COMPLETE = @1 WHERE ASSETID = @2 AND ASSETSRCID = @3
...
SELECT * FROM ASSTEDCTX_5 WHERE ASSTID = @0
селект по некластерному уникальному индексу


Про ROWLOCK - когда-то читал, что MS SQL 2000 под нагрузкой может при инсерте блокировать всю страницу.
16 фев 06, 15:42    [2363614]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock без прямого пересечения по данным  [new]
Crimean
Member

Откуда:
Сообщений: 13148
`
а вы не слышали про дедлок индекса и таблицы?
примерная сутуация - один процес - индекс скан- блокировка индеса -блокировка строки(страницы)
другой процес - фулл скан -блокировка строки(страницы) -блокировка индекса - вот вам и дедлок


слышали и, не поверите, видели. правда местами и издали

однако вернемся к нашим баранам, то есть дедлокам, то есть графам дедлоков

у нас есть два конфликтующих процесса, 55 и 52. оба "стоят" _сейчас_ на SELECT, Line#1

и там и там SELECT запросы держут X локи (уже интересно, правда?)

процесс 55 держит X на KEY: 7:1846323129:1
процесс 55 хочет S на RID: 7:3:1127:12

процесс 52 держит X на RID: 7:3:1127:12
процесс 52 хочет S на KEY: 7:1846323129:1

вопрос: с какого перепугу они взялись? в смысле X локи? если заявлен обычный рид коммитед и внешне не видно транзакций?

ответ: нас обманули и там есть транзакции, которые нам не показали. иначе я никак не могу объяснить наличие X локов во владении у этих процессов. а то, что селекты просют S локи - коню понятно, там для пафоса еще и WITH (ROWLOCK) прописано :)

вот в этих транзакциях надо или переставить команды местами (если возможно) или сразу завесить X локи на необходимые ресурсы, в общем читайте БОЛ про борьбу с дедлоками, там все написано.
16 фев 06, 15:44    [2363626]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock без прямого пересечения по данным  [new]
NGL
Member

Откуда:
Сообщений: 14
Конечно транзакции есть. В аттаче приведен полный лог обеих транзакций. Я понимаю, что транзакции очень длинные и что лучше локировать то, что будешь менять, заранее. Вопрос в другом. Обе транзакции меняют РАЗНЫЕ записи, они нигде не конкурируют за одну и ту же запись.
16 фев 06, 15:49    [2363663]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock без прямого пересечения по данным  [new]
Glory
Member

Откуда:
Сообщений: 104760
NGL
Конечно транзакции есть. В аттаче приведен полный лог обеих транзакций. Я понимаю, что транзакции очень длинные и что лучше локировать то, что будешь менять, заранее. Вопрос в другом. Обе транзакции меняют РАЗНЫЕ записи, они нигде не конкурируют за одну и ту же запись.

Ну как же не конкурируют если Crimean вам написал

"процесс 55 держит X на KEY: 7:1846323129:1
процесс 55 хочет S на RID: 7:3:1127:12

процесс 52 держит X на RID: 7:3:1127:12
процесс 52 хочет S на KEY: 7:1846323129:1"
16 фев 06, 15:52    [2363684]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock без прямого пересечения по данным  [new]
NGL
Member

Откуда:
Сообщений: 14
Я вижу конкуренцию из лога MS SQL сервера, но я не могу понять, чем она вызвана, так как транзакции меняют РАЗНЫЕ данные. В это и есть корень проблемы.

А чем плох ROWLOCK ?
16 фев 06, 15:57    [2363722]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock без прямого пересечения по данным  [new]
Glory
Member

Откуда:
Сообщений: 104760
NGL
Я вижу конкуренцию из лога MS SQL сервера, но я не могу понять, чем она вызвана, так как транзакции меняют РАЗНЫЕ данные. В это и есть корень проблемы.

Что такое "разные данные". Вообще смотрели что за объекты расположены
в KEY: 7:1846323129:1 и RID: 7:3:1127:12 ?
16 фев 06, 15:59    [2363738]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock без прямого пересечения по данным  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
BOL->Deadlocking

ТАм даже рисуночек есть, который Вам все объяснит.
16 фев 06, 15:59    [2363739]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock без прямого пересечения по данным  [new]
NGL
Member

Откуда:
Сообщений: 14
конечно, смотри первый пост

RID: 7:3:1127:12 - таблица ASSTEDCTX_5 (есть некластерный РК)

KEY: 7:1846323129:1 - кластерный индекс (по USERID) для таблицы AR_ASSET_5 (есть некластерный РК по ASSETSRCID, ASSETID)
16 фев 06, 16:04    [2363761]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock без прямого пересечения по данным  [new]
NGL
Member

Откуда:
Сообщений: 14
"разные данные" - нет ни одной записи, которая была бы добавлена/прочитана/изменена/удалена сразу в двух транзакциях.
16 фев 06, 16:08    [2363791]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock без прямого пересечения по данным  [new]
NGL
Member

Откуда:
Сообщений: 14
Еще маленькое добавление - транзакции управляются MSDTC при помощи .NET ServicedComponent. Не думаю, правда, что это имеет значение.
16 фев 06, 16:12    [2363807]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock без прямого пересечения по данным  [new]
ё
Guest
так одна хочет поменять данные в стоке, а другая в ИНДЕКСЕ. они не меняют одну строку, они меняют один ИНДЕКС
16 фев 06, 17:23    [2364289]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock без прямого пересечения по данным  [new]
Crimean
Member

Откуда:
Сообщений: 13148
похоже, читать надо так:

NGL
Не думаю, правда


16 фев 06, 17:39    [2364405]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock без прямого пересечения по данным  [new]
NGL
Member

Откуда:
Сообщений: 14
Исследование показало, что SELECT не использовал индекс по РК, а выполнял полное сканирование таблицы, по-видимому, из-за небольшого количества записей. Добавление хинта решило проблему. В догонку еще вопрос - можно ли в MS SQL указать хинт, не указывая название и ID индекса ? Что-то вроде select * from atable with(<list of fields goes here>) where id = 1 Спасибо.
17 фев 06, 21:25    [2369848]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock без прямого пересечения по данным  [new]
Crimean
Member

Откуда:
Сообщений: 13148
неужели сложно посмотреть синтаксис оператора SELECT ?
17 фев 06, 21:56    [2369882]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock без прямого пересечения по данным  [new]
NGL
Member

Откуда:
Сообщений: 14
Crimean
неужели сложно посмотреть синтаксис оператора SELECT ?


Я уже посмотрел, BOL говорит, что нельзя - только имя или ID индекса. Спрашиваю в надежде, что есть какая-нибудь недокументированная возможность. Для очистки совести, так сказать.
17 фев 06, 22:15    [2369902]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock без прямого пересечения по данным  [new]
NGL
Member

Откуда:
Сообщений: 14
очередная проблема вылезла - MS SQL пытается всегда выполнить или table scan или index scan, в упор игнорируя index seek. Я понимаю, что для таблиц в 10 записей сканирование быстрее, однако оно вызывает блокирование записей, которые используются в других транзакциях. Детальнее проблема выглядит так:

есть табличка
CREATE TABLE [dbo].[ASSTEDCTX_7] (
	[ASSTEDID] [int] NOT NULL ,
	[ASSTEDURN] [varchar] (70)  NULL ,
	[ORGGRPURN] [varchar] (70)  NULL ,
	[ASSTID] [varchar] (100)  NULL ,
	[ASSTNAME] [varchar] (320)  NULL ,
	[ASSTVER] [varchar] (40)  NULL ,
	[NOTES] [image] NULL ,
	[CREATED] [datetime] NULL ,
	[LASTMOD] [datetime] NULL 
) ON [ll_data] TEXTIMAGE_ON [ll_blob]
есть уникальные некластерные индексы по ASSTEDID и ASSTID

такой селект вызывает сканирование таблицы
SELECT * FROM ASSTEDCTX_7 WHERE ASSTID = N'1.0_1140012369823799556279'
SELECT * FROM ASSTEDCTX_7   --with(index(ASIDASSTEDCTX_7))   WHERE  ASSTID = N'1.0_1140012369823799556279'
  |--Compute Scalar(DEFINE:([ASSTEDCTX_7].[NOTES]=[ASSTEDCTX_7].[NOTES]))
       |--Table Scan(OBJECT:([LogicLibrary].[dbo].[ASSTEDCTX_7]), WHERE:(Convert([ASSTEDCTX_7].[ASSTID])='1.0_1140012369823799556279'))

добавление хинта вызывает сканирование индекса
SELECT * FROM ASSTEDCTX_7 with(index(ASIDASSTEDCTX_7)) WHERE  ASSTID = N'1.0_1140012369823799556279'
  |--Compute Scalar(DEFINE:([ASSTEDCTX_7].[NOTES]=[ASSTEDCTX_7].[NOTES]))
       |--Filter(WHERE:(Convert([ASSTEDCTX_7].[ASSTID])='1.0_1140012369823799556279'))
            |--Bookmark Lookup(BOOKMARK:([Bmk1000]), OBJECT:([LogicLibrary].[dbo].[ASSTEDCTX_7]))
                 |--Index Scan(OBJECT:([LogicLibrary].[dbo].[ASSTEDCTX_7].[ASIDASSTEDCTX_7]))
Как получить index seek ?
17 фев 06, 23:39    [2370002]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock без прямого пересечения по данным  [new]
SQLasik
Guest
Попробуй так :
SELECT * FROM ASSTEDCTX_7 WHERE ASSTID = '1.0_1140012369823799556279'
вместо
SELECT * FROM ASSTEDCTX_7 WHERE ASSTID = N'1.0_1140012369823799556279'


Поле ASSTID -> varchar, а не nvarchar.

Я уже видел такую путаницу.
18 фев 06, 13:08    [2370544]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить