Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 помогите с deadlock  [new]
EvAlex
Member

Откуда: Israel
Сообщений: 1001
Есть табличка, такая (упрощённый вариант)
CREATE TABLE [dbo].[T_CLIP] (
	[Id] [int] IDENTITY (1, 1) NOT NULL ,
	[ClipId] [uniqueidentifier] NULL ,
	[StartPageIndex] [int] NULL ,
	[StartContainerId] [uniqueidentifier] NULL ,
	[EndPageIndex] [int] NULL ,
	[EndContainerId] [uniqueidentifier] NULL ,
) ON [PRIMARY]
GO

ALTER TABLE [dbo].[T_CLIP] WITH NOCHECK ADD 
	CONSTRAINT [PK_T_CLIP] PRIMARY KEY  CLUSTERED 
	(
		[Id]
	)  ON [PRIMARY] 
GO

 CREATE  INDEX [IX_T_CLIP_ClipId] ON [dbo].[T_CLIP]([ClipId]) ON [PRIMARY]
GO

 CREATE  INDEX [IX_T_CLIP_C1] ON [dbo].[T_CLIP]([StartContainerId], [StartPageIndex]) ON [PRIMARY]
GO

Есть процедура UPDATE
CREATE PROCEDURE P_CLIP_OPEN
	@ClipId 		UNIQUEIDENTIFIER,
	@StartContainerId	UNIQUEIDENTIFIER,
	@StartPageIndex	INT
AS
BEGIN
	UPDATE
		T_CLIP WITH(ROWLOCK)
	SET
		ClipId 			= @ClipId,
		StartContainerId		= @StartContainerId,
		StartPageIndex		= @StartPageIndex
	WHERE
		[Id] = (SELECT TOP 1 [Id] FROM T_CLIP NOLOCK WHERE ClipId IS NULL)
END
GO
И есть вот такой deadlock :(
2005-12-22 16:41:52.60 spid4                                                                                                                                                                                                                                    0
Deadlock encountered .... Printing deadlock information                                                                                                                                                                                                         0
2005-12-22 16:41:52.60 spid4                                                                                                                                                                                                                                    0
2005-12-22 16:41:52.60 spid4     Wait-for graph                                                                                                                                                                                                                 0
2005-12-22 16:41:52.60 spid4                                                                                                                                                                                                                                    0
2005-12-22 16:41:52.60 spid4     Node:1                                                                                                                                                                                                                         0
2005-12-22 16:41:52.60 spid4     KEY: 6:1993058136:1 (010086470766) CleanCnt:2 Mode: X Flags: 0x0                                                                                                                                                               0
2005-12-22 16:41:52.60 spid4      Grant List 0::                                                                                                                                                                                                                0
2005-12-22 16:41:52.60 spid4        Owner:0x1aea4160 Mode: X        Flg:0x0 Ref:0 Life:02000000 SPID:63 ECID:0                                                                                                                                                  0
2005-12-22 16:41:52.60 spid4        SPID: 63 ECID: 0 Statement Type: UPDATE Line #: 14                                                                                                                                                                          0
2005-12-22 16:41:52.60 spid4        Input Buf: RPC Event: P_CLIP_OPEN;1                                                                                                                                                                                         0
2005-12-22 16:41:52.60 spid4      Requested By:                                                                                                                                                                                                                 0
2005-12-22 16:41:52.60 spid4        ResType:LockOwner Stype:'OR' Mode: U SPID:61 ECID:0 Ec:(0x1ACBB578) Value:0x1aea4140 Cost:(0/0)                                                                                                                             0
2005-12-22 16:41:52.60 spid4                                                                                                                                                                                                                                    0
2005-12-22 16:41:52.60 spid4     Node:2                                                                                                                                                                                                                         0
2005-12-22 16:41:52.60 spid4     KEY: 6:1993058136:3 (0300e73ca1fb) CleanCnt:2 Mode: S Flags: 0x0                                                                                                                                                               0
2005-12-22 16:41:52.60 spid4      Grant List 0::                                                                                                                                                                                                                0
2005-12-22 16:41:52.60 spid4        Owner:0x1aea4080 Mode: S        Flg:0x0 Ref:1 Life:00000000 SPID:61 ECID:0                                                                                                                                                  0
2005-12-22 16:41:52.60 spid4        SPID: 61 ECID: 0 Statement Type: UPDATE Line #: 14                                                                                                                                                                          0
2005-12-22 16:41:52.60 spid4        Input Buf: RPC Event: P_CLIP_OPEN;1                                                                                                                                                                                         0
2005-12-22 16:41:52.60 spid4      Requested By:                                                                                                                                                                                                                 0
2005-12-22 16:41:52.60 spid4        ResType:LockOwner Stype:'OR' Mode: X SPID:63 ECID:0 Ec:(0x1ACB5578) Value:0x1afa3fa0 Cost:(0/8C)                                                                                                                            0
2005-12-22 16:41:52.60 spid4     Victim Resource Owner:                                                                                                                                                                                                         0
2005-12-22 16:41:52.60 spid4      ResType:LockOwner Stype:'OR' Mode: U SPID:61 ECID:0 Ec:(0x1ACBB578) Value:0x1aea4140 Cost:(0/0)                                                                                                                               0
А сам сервер это
Microsoft SQL Server  2000 - 8.00.2039 (Intel X86) 
	May  3 2005 23:18:38 
	Copyright (c) 1988-2003 Microsoft Corporation
	Desktop Engine on Windows NT 5.1 (Build 2600: Service Pack 2)

Эта процедура единственная, которая обращается к этой таблице.
Не часто - менее 10 раз секунду в наихудщем варианте.
В таблице 1000 строк.

И это я думаю тоже поможет
select object_name(1993058136)
-------
T_CLIP
Моя догадка что модицикация таблицы не происходит до тех пор пока не закончится вложенный запрос и это как-то мешает другому вызову.
22 дек 05, 19:04    [2200781]     Ответить | Цитировать Сообщить модератору
 Re: помогите с deadlock  [new]
fte
Member

Откуда: Moscow
Сообщений: 386
а так?
CREATE PROCEDURE P_CLIP_OPEN
	@ClipId 		UNIQUEIDENTIFIER,
	@StartContainerId	UNIQUEIDENTIFIER,
	@StartPageIndex	INT
AS
BEGIN
        SET ROWCOUNT 1
	UPDATE
		T_CLIP WITH(ROWLOCK)
	SET
		ClipId 			= @ClipId,
		StartContainerId		= @StartContainerId,
		StartPageIndex		= @StartPageIndex
	WHERE
		ClipId IS NULL
        SET ROWCOUNT 0
END
GO
22 дек 05, 19:46    [2200904]     Ответить | Цитировать Сообщить модератору
 Re: помогите с deadlock  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Во-первых там с синтаксисом вопрос БОЛЬШОЙ! Вместо

[Id] = (SELECT TOP 1 [Id] FROM T_CLIP NOLOCK WHERE ClipId IS NULL)

надо

[Id] = (SELECT TOP 1 [Id] FROM T_CLIP WITH (NOLOCK) WHERE ClipId IS NULL)

Во-вторых уже подсказали более разумный вариант с rowcount
В-третьих порекомендую

UPDATE
T_CLIP WITH(ROWLOCK, XLOCK)

ибо дедлоки на конверсии U -> X
ставим сходу X и получаем тупое ожидание вместо дедлоков
22 дек 05, 20:11    [2200949]     Ответить | Цитировать Сообщить модератору
 Re: помогите с deadlock  [new]
EvAlex
Member

Откуда: Israel
Сообщений: 1001
а это был мой изначальный вариант.
Но так как SET ROWCOUNT 1 MS SQL при постоении плана вроде учитывает(ИМХО), но строит какой-то неэфективный план и когда таблица вырастает, начинает жутко тормозить...


Старый способ, без поиска по Id
Table 'T_CLIP'. Scan count 3, logical reads 12, physical reads 0, read-ahead reads 0.
Table 'Worktable'. Scan count 2, logical reads 5, physical reads 0, read-ahead reads 0.

StmtText                                                                                                                                                                                                                                               
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 
       |--Sequence
            |--Index Update(OBJECT:([LoggerDb].[dbo].[T_CLIP].[IX_T_CLIP_ClipId]), SET:([Id1007]=[T_CLIP].[Id], [ClipId1006]=[T_CLIP].[ClipId], [IdxBmk1005]=RaiseIfNull([Bmk1003])))
            |    |--Sort(ORDER BY:([T_CLIP].[ClipId] ASC, [T_CLIP].[Id] ASC, [Bmk1003] ASC, [Act1004] ASC))
            |         |--Table Spool
            |              |--Split
            |                   |--Clustered Index Update(OBJECT:([LoggerDb].[dbo].[T_CLIP].[PK_T_CLIP]), SET:([T_CLIP].[StartContainerId]=[@StartContainerId], [T_CLIP].[StartPageIndex]=[@StartPageIndex], [T_CLIP].[ClipId]=[@ClipId]))
            |                        |--Top(ROWCOUNT est 0)
            |                             |--Clustered Index Scan(OBJECT:([LoggerDb].[dbo].[T_CLIP].[PK_T_CLIP]), WHERE:([T_CLIP].[ClipId]=NULL) ORDERED)
            |--Index Update(OBJECT:([LoggerDb].[dbo].[T_CLIP].[IX_T_CLIP_C1]), SET:([Id1011]=[T_CLIP].[Id], [StartPageIndex1010]=[T_CLIP].[StartPageIndex], [StartContainerId1009]=[T_CLIP].[StartContainerId], [IdxBmk1008]=RaiseIfNull([Bmk1003])))
                 |--Sort(ORDER BY:([T_CLIP].[StartContainerId] ASC, [T_CLIP].[StartPageIndex] ASC, [T_CLIP].[Id] ASC, [Bmk1003] ASC, [Act1004] ASC))
                      |--Table Spool



Текущий способ, с поиском по Id
Table 'T_CLIP'. Scan count 2, logical reads 12, physical reads 0, read-ahead reads 0.

StmtText                                                                                                                                                                                                           
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 
       |--Clustered Index Update(OBJECT:([LoggerDb].[dbo].[T_CLIP].[PK_T_CLIP]), SET:([T_CLIP].[StartContainerId]=[@StartContainerId], [T_CLIP].[StartPageIndex]=[@StartPageIndex], [T_CLIP].[ClipId]=[@ClipId]))
            |--Top(1)
                 |--Nested Loops(Inner Join, OUTER REFERENCES:([NOLOCK].[Id]))
                      |--Top(1)
                      |    |--Index Seek(OBJECT:([LoggerDb].[dbo].[T_CLIP].[IX_T_CLIP_ClipId] AS [NOLOCK]), SEEK:([NOLOCK].[ClipId]=NULL) ORDERED FORWARD)
                      |--Clustered Index Seek(OBJECT:([LoggerDb].[dbo].[T_CLIP].[PK_T_CLIP]), SEEK:([T_CLIP].[Id]=[NOLOCK].[Id]) ORDERED FORWARD)
22 дек 05, 20:22    [2200980]     Ответить | Цитировать Сообщить модератору
 Re: помогите с deadlock  [new]
EvAlex
Member

Откуда: Israel
Сообщений: 1001
2Crimean c ROWCOUNT сильно ухудшилась производительность.
Тут я подумал насчёт синтаксиса... (даже стыдно стало NOLOCK = AS NOLOCK)
WITH(ROWLOCK, XLOCK) проверю...
22 дек 05, 20:37    [2201008]     Ответить | Цитировать Сообщить модератору
 Re: помогите с deadlock  [new]
Crimean
Member

Откуда:
Сообщений: 13148
EvAlex
2CrimeanТут я подумал насчёт синтаксиса... (даже стыдно стало NOLOCK = AS NOLOCK)


это не оно
было бы S -> X , а так U -> X . хинт должен помочь
дело в том , что для UPDATE берется некластерный индекс , на него U ессно . а когда доходит дело до изменения данных то надо U -> X произвести . а если "двое нас", то U -> X + U -> X и будет дедлок . делаешь X сразу и все ок
22 дек 05, 20:39    [2201015]     Ответить | Цитировать Сообщить модератору
 Re: помогите с deadlock  [new]
aleks2
Guest
Проще надо быть.
CREATE PROCEDURE P_CLIP_OPEN
	@ClipId 		UNIQUEIDENTIFIER,
	@StartContainerId	UNIQUEIDENTIFIER,
	@StartPageIndex	INT
AS
BEGIN
	UPDATE T
	SET
		ClipId 			= @ClipId,
		StartContainerId		= @StartContainerId,
		StartPageIndex		= @StartPageIndex
	FROM (select TOP 1 * FROM T_CLIP WHERE ClipId IS NULL) T
END
23 дек 05, 06:36    [2201790]     Ответить | Цитировать Сообщить модератору
 Re: помогите с deadlock  [new]
Crimean
Member

Откуда:
Сообщений: 13148
aleks2
Проще надо быть.


ой ли
или найти тему насчет дедлоков в двух паралельно выполняющихся UPDATE?
23 дек 05, 11:14    [2202534]     Ответить | Цитировать Сообщить модератору
 Re: помогите с deadlock  [new]
EvAlex
Member

Откуда: Israel
Сообщений: 1001
2Aleks синтакс мне понравился, но
The derived table 'T' is not updatable because the definition contains the TOP clause.

+ то что сказал Crimean
25 дек 05, 12:02    [2207142]     Ответить | Цитировать Сообщить модератору
 Re: помогите с deadlock  [new]
ilnev
Member

Откуда:
Сообщений: 52
Можно так
DECLARE cursor_name CURSOR 
FOR select TOP 1 * FROM T_CLIP WHERE ClipId IS NULL
FOR  UPDATE 
open cursor_name
fetch next from cursor_name
if @@Fetch_Status = 0
  update T_CLIP SET
		ClipId 			= @ClipId,
		StartContainerId		= @StartContainerId,
		StartPageIndex		= @StartPageIndex
  where 	current of cursor_name
close 	cursor_name
deallocate cursor_name
25 дек 05, 21:09    [2207738]     Ответить | Цитировать Сообщить модератору
 Re: помогите с deadlock  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Так шо, XLOCK помог?
26 дек 05, 11:29    [2208695]     Ответить | Цитировать Сообщить модератору
 Re: помогите с deadlock  [new]
Рита К
Guest
Может быть, поменять местами select и update? Сначала считать Id той строчки, которую будем менять, в переменную @IDupdate, а потом сделать update:
UPDATE
T_CLIP
SET
ClipId = @ClipId,
StartContainerId= @StartContainerId,
StartPageIndex= @StartPageIndex
WHERE id=@IDupdate
26 дек 05, 22:50    [2210948]     Ответить | Цитировать Сообщить модератору
 Re: помогите с deadlock  [new]
EvAlex
Member

Откуда: Israel
Сообщений: 1001
Crimean
Так шо, XLOCK помог?

да, спасибо!
27 дек 05, 14:54    [2213121]     Ответить | Цитировать Сообщить модератору
 Re: помогите с deadlock  [new]
EvAlex
Member

Откуда: Israel
Сообщений: 1001
Рита К
Может быть, поменять местами select и update? Сначала считать Id той строчки, которую будем менять, в переменную @IDupdate, а потом сделать update:

Замечательно, но что гарантирует что не произойдёт такого сценария:
первый update выбрал id, но ещё не произвел модификацию. В то же время второй update выбрал то же id что и первый, и получается, что второй update перезапишет строку первого.
Может xlock, holdlock во время select, но ...
27 дек 05, 14:58    [2213165]     Ответить | Цитировать Сообщить модератору
 Re: помогите с deadlock  [new]
SanyL
Member

Откуда: Москва
Сообщений: 4540
кстати вы заметили что у вас блокировки на разных индексах висят? может стоит строго прописать хинты дабы определить порядок наложения блокировок, и ненакладывать блокировок самому?
27 дек 05, 15:34    [2213362]     Ответить | Цитировать Сообщить модератору
 Re: помогите с deadlock  [new]
Crimean
Member

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


1 и 3 имелось в виду? Так 1 = кластерный = сама таблица. Так что реально только индекс 3 пользуется.

а на самом деле беда была вовсе не в том, о чем все думали (хинты, индексы, локи, ...), а в описке

(SELECT TOP 1 [Id] FROM T_CLIP NOLOCK WHERE ClipId IS NULL)

достаточно ИМХО было бы заменить это на WITH (NOLOCK)
но XLOCK там тоже не помешает, хотя в данном конкретном случае (после прописывания правильно хинта), возможно, и не поможет.
27 дек 05, 16:20    [2213571]     Ответить | Цитировать Сообщить модератору
 Re: помогите с deadlock  [new]
SanyL
Member

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

пользуются оба! а порядок доступа разный! отсюда и дедлок

Node1 ставит эксклюзивную блокировку на индекс 1 и запрашивает значение на индексе 3 чтобы поставить эксклюзивную блокировку, а в это время Node2 поставил шаред блокировку на значение которое нужно Node1 и запосил занятое значение Node1 под шаред блокировку = вот замкнутый цикл в графе = дедлок.... и в нем участвуют два индекса...
27 дек 05, 16:43    [2213682]     Ответить | Цитировать Сообщить модератору
 Re: помогите с deadlock  [new]
SanyL
Member

Откуда: Москва
Сообщений: 4540
Crimean
а на самом деле беда была вовсе не в том, о чем все думали (хинты, индексы, локи, ...), а в описке

(SELECT TOP 1 [Id] FROM T_CLIP NOLOCK WHERE ClipId IS NULL)

достаточно ИМХО было бы заменить это на WITH (NOLOCK)
но XLOCK там тоже не помешает, хотя в данном конкретном случае (после прописывания правильно хинта), возможно, и не поможет.


а если так то будет дедлок на техже индексах между эксклюзивными блокировками...
27 дек 05, 16:45    [2213689]     Ответить | Цитировать Сообщить модератору
 Re: помогите с deadlock  [new]
Crimean
Member

Откуда:
Сообщений: 13148
> а если так то будет дедлок на техже индексах между эксклюзивными блокировками...

а доказать? :)

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

непосредственно тут помогло прописывание XLOCK в одном месте и исправление описки с WITH (NOLOCK) в другом.

если есть возражения - вэлкам, но с примерами :)

Еще раз по графу дедлока.

Node:1
KEY: 6:1993058136:1 (010086470766) CleanCnt:2 Mode: X Flags: 0x0
Grant List 0::
Owner:0x1aea4160 Mode: X Flg:0x0 Ref:0 Life:02000000 SPID:63 ECID:0
SPID: 63 ECID: 0 Statement Type: UPDATE Line #: 14
Input Buf: RPC Event: P_CLIP_OPEN;1
Requested By:
ResType:LockOwner Stype:'OR' Mode: U SPID:61 ECID:0 Ec:(0x1ACBB578) Value:0x1aea4140 Cost:(0/0)

Кластерный индекс. Уже залокан как X 63 процессом. Просится на U 61 процессом.

Node:2
KEY: 6:1993058136:3 (0300e73ca1fb) CleanCnt:2 Mode: S Flags: 0x0
Grant List 0::
Owner:0x1aea4080 Mode: S Flg:0x0 Ref:1 Life:00000000 SPID:61 ECID:0
SPID: 61 ECID: 0 Statement Type: UPDATE Line #: 14
Input Buf: RPC Event: P_CLIP_OPEN;1
Requested By:
ResType:LockOwner Stype:'OR' Mode: X SPID:63 ECID:0 Ec:(0x1ACB5578) Value:0x1afa3fa0 Cost:(0/8C)

Некластерный индекс. Уже залокан как S 61 и просится на X 63

Ессно, 63 меняет таблицу, а 61 только хочет. Поэтому 61 и просит на U кластерный - он по нему ищет. UPDATE написан с WHERE по полю Id, на который у нас PRIMARY KEY CLUSTERED. А вот поиск в подзапросе БЕЗ NOLOCK (!) делается по ClipId IS NULL, а на ClipId у нас некластерный индекс, он-то и берется на S при поиске, а потом просится на X при изменении. В отличие от кластерного, который по U на WHERE от UPDATE, а потом на X при самом UPDATE

Фух.

Соответственно, если ставим хинт XLOCK на UPDATE, то кластерный уже в WHERE попросится на X. И дальше U->X не произойдет. Ну на если NOLOCK заменим на WITH (NOLOCK) то S исчезнет и будет заменено грязным чтением (что само по себе не есть здорово, между прочим!). В итоге проблема исчезнет (что и произошло).

P.S.Но я бы поигрался с ROWCOUNT, если честно... Или написал бы транзакцию - сначала с XLOCK вычитал TOP 1 Id, а потом UPDATE ее со всей пролетарской, COMMIT :)
27 дек 05, 18:10    [2214229]     Ответить | Цитировать Сообщить модератору
 Re: помогите с deadlock  [new]
SanyL
Member

Откуда: Москва
Сообщений: 4540
Да я понимаю о чем вы, у меня такой пример (к сожалению тут не погу сэмитировать)

UPDATE и SELECT в данном случае выполняется в одной транзакции... SELECT может наложить X блокировки (XLOCK) на несколько записей... и подобная операция происходит на другом клиенте.... когда интервалы SELECTов пересекутся будет дедлок = но пока не готов утверждать - завтра посмотрю и попытаюсь потестить при наличии времени...
27 дек 05, 22:43    [2214701]     Ответить | Цитировать Сообщить модератору
 Re: помогите с deadlock  [new]
Crimean
Member

Откуда:
Сообщений: 13148
SanyL
Да я понимаю о чем вы, у меня такой пример (к сожалению тут не погу сэмитировать)

UPDATE и SELECT в данном случае выполняется в одной транзакции... SELECT может наложить X блокировки (XLOCK) на несколько записей... и подобная операция происходит на другом клиенте.... когда интервалы SELECTов пересекутся будет дедлок = но пока не готов утверждать - завтра посмотрю и попытаюсь потестить при наличии времени...


классика. ORDER BY вам в помощь. и дедллок исчезнет. но - иногда ценой курсоров :( у самого было подобное.
сделать пример, действительно, достаточно сложно. но и тут примера не было. просто повезло, что продакшен код небольшой и показательный.
или ложите нужные блокировки СРАЗУ после начала транзакции. у вас дедлок, возможно, из-за того, что по ходу выполнения транзакция ДОБИРАЕТ блокировок. если бы она взяла все сразу - никаких дедлоков, только ожидания.
27 дек 05, 23:49    [2214783]     Ответить | Цитировать Сообщить модератору
 Re: помогите с deadlock  [new]
EvAlex
Member

Откуда: Israel
Сообщений: 1001
Если интересно, то финальный (на сегодня) такой вариант:
CREATE PROCEDURE P_CLIP_OPEN
	@ClipId 		UNIQUEIDENTIFIER,
	@StartContainerId	UNIQUEIDENTIFIER,
	@StartPageIndex	INT
AS
BEGIN TRAN
	DECLARE @Id INT
	SELECT TOP 1
		@Id = Id
	FROM
		T_CLIP WITH(UPDLOCK, READPAST) 
	WHERE 
		ClipId IS NULL

	UPDATE
		T_CLIP WITH(ROWLOCK, XLOCK)
	SET
		ClipId 			= @ClipId,
		StartContainerId	= @StartContainerId,
		StartPageIndex		= @StartPageIndex
	WHERE
		[Id] = @Id
COMMIT
GO
29 янв 06, 12:54    [2298286]     Ответить | Цитировать Сообщить модератору
 Re: помогите с deadlock  [new]
Crimean
Member

Откуда:
Сообщений: 13148
> Если интересно, то финальный (на сегодня) такой вариант

а то , что SELECT с READPAST может _не вернуть_ записей вас , видимо , не волнует ...

и - да - ROWLOCK + XLOCK ... а оно вам надо ?
в смысле ROWLOCK
или у вас ресурсов переизбыток?
30 янв 06, 10:27    [2299446]     Ответить | Цитировать Сообщить модератору
 Re: помогите с deadlock  [new]
EvAlex
Member

Откуда: Israel
Сообщений: 1001
Crimean
>
а то , что SELECT с READPAST может _не вернуть_ записей вас , видимо , не волнует ...

Волнует, здесь не полный код, в оргинале есть проверка @@rowcount и raiseerror в случае если не нашлось записей, дальше это уже аппликативная проблема.
Crimean

и - да - ROWLOCK + XLOCK ... а оно вам надо ?
в смысле ROWLOCK
или у вас ресурсов переизбыток?

Можно насчёт ROWLOCK подробней? Я знаю что ROWLOCK используется для того чтобы блокировать строку, а не page или table, что вроде бы и требуется так как меняется только одна запись. А вот насчёт ресурсоёмкости?
30 янв 06, 11:41    [2299868]     Ответить | Цитировать Сообщить модератору
 Re: помогите с deadlock  [new]
Crimean
Member

Откуда:
Сообщений: 13148
> Можно насчёт ROWLOCK подробней

сервер сам решает что выгоднее - ROW / PAGE / EXT / TABLE / DB
не стоит ИМХО без _ОСОБОЙ_ необходимости лишать его этой привилегии
читать для понимания про эскалацию блокировок и в БОЛ и на форуме
30 янв 06, 12:06    [2300019]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить