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

REATE TABLE [dbo].[GlobalVarsRepository] (
[ID] [int] IDENTITY (1, 1) NOT NULL ,
[id_sess] [int] NOT NULL ,
[id_access] [int] NOT NULL ,
[id_inner] [int] NOT NULL ,
[var_name] [varchar] (100) COLLATE Cyrillic_General_CI_AS NOT NULL ,
[var_value] [varchar] (4000) COLLATE Cyrillic_General_CI_AS NOT NULL ,
[time_to_live] [int] NULL ,
[last_access] [datetime] NOT NULL
) ON [PRIMARY]
GO

CREATE CLUSTERED INDEX [lalala] ON [dbo].[GlobalVarsRepository]([id_sess], [id_access], [id_inner], [var_name]) ON [PRIMARY]
GO

Многократно запускаем php-скрипт, активно работающего с данной таблицей(через ODBC). Не используются никакие транзакции, хранимые процедуры, триггера. Получаем дедлоки.
Трейс номер раз:
Deadlock encountered .... Printing deadlock information
2004-06-21 18:56:46.04 spid4
2004-06-21 18:56:46.04 spid4 Wait-for graph
2004-06-21 18:56:46.04 spid4
2004-06-21 18:56:46.04 spid4 Node:1
2004-06-21 18:56:46.04 spid4 KEY: 17:1854629650:1 (ac033130cb26) CleanCnt:1 Mode: X Flags: 0x0
2004-06-21 18:56:46.04 spid4 Grant List 0::
2004-06-21 18:56:46.04 spid4 Owner:0x48c22680 Mode: X Flg:0x0 Ref:0 Life:02000000 SPID:67 ECID:0
2004-06-21 18:56:46.04 spid4 SPID: 67 ECID: 0 Statement Type: DELETE Line #: 1
2004-06-21 18:56:46.04 spid4 Input Buf: Language Event: DELETE GlobalVarsRepository WHERE id_sess = 1168875080 AND id_access = 123 AND id_inner = 213260226
2004-06-21 18:56:46.04 spid4 Requested By:
2004-06-21 18:56:46.04 spid4 ResType:LockOwner Stype:'OR' Mode: X SPID:65 ECID:0 Ec:(0x4B3AF4E0) Value:0x45752800 Cost:(0/130)
2004-06-21 18:56:46.04 spid4
2004-06-21 18:56:46.04 spid4 Node:2
2004-06-21 18:56:46.04 spid4 KEY: 17:1854629650:1 (c702a86ac18e) CleanCnt:1 Mode: X Flags: 0x0
2004-06-21 18:56:46.04 spid4 Grant List 0::
2004-06-21 18:56:46.04 spid4 Owner:0x42bc6920 Mode: X Flg:0x0 Ref:0 Life:02000000 SPID:65 ECID:0
2004-06-21 18:56:46.04 spid4 SPID: 65 ECID: 0 Statement Type: DELETE Line #: 1
2004-06-21 18:56:46.04 spid4 Input Buf: Language Event: DELETE GlobalVarsRepository WHERE id_sess = 1168875080 AND id_access = 123 AND id_inner = 213260226
2004-06-21 18:56:46.04 spid4 Requested By:
2004-06-21 18:56:46.04 spid4 ResType:LockOwner Stype:'OR' Mode: X SPID:67 ECID:0 Ec:(0x4B6174E0) Value:0x48c224a0 Cost:(0/0)
2004-06-21 18:56:46.04 spid4 Victim Resource Owner:
2004-06-21 18:56:46.04 spid4 ResType:LockOwner Stype:'OR' Mode: X SPID:67 ECID:0 Ec:(0x4B6174E0) Value:0x48c224a0 Cost:(0/0)
2004-06-21 18:56:51.06 spid4

Правильно ли я понимаю, что каким-то образом два процесса получили эксклюзивную блокировку на на один и тот же ресурс? Если да, то КАК такое вышло?Если нет, в чем же проблема?

Трейс номер два:
Deadlock encountered .... Printing deadlock information
2004-06-21 18:56:51.06 spid4
2004-06-21 18:56:51.06 spid4 Wait-for graph
2004-06-21 18:56:51.06 spid4
2004-06-21 18:56:51.06 spid4 Node:1
2004-06-21 18:56:51.06 spid4 KEY: 17:1854629650:1 (c702a86ac18e) CleanCnt:2 Mode: X Flags: 0x0
2004-06-21 18:56:51.06 spid4 Wait List:
2004-06-21 18:56:51.06 spid4 Owner:0x45b91a80 Mode: X Flg:0x0 Ref:1 Life:02000000 SPID:75 ECID:0
2004-06-21 18:56:51.06 spid4 SPID: 75 ECID: 0 Statement Type: DELETE Line #: 1
2004-06-21 18:56:51.06 spid4 Input Buf: Language Event: DELETE GlobalVarsRepository WHERE id_sess = 1168875080 AND id_access = 123 AND id_inner = 213260226
2004-06-21 18:56:51.06 spid4 Requested By:
2004-06-21 18:56:51.06 spid4 ResType:LockOwner Stype:'OR' Mode: U SPID:65 ECID:0 Ec:(0x4B3AF4E0) Value:0x48c22520 Cost:(0/3B0)
2004-06-21 18:56:51.06 spid4
2004-06-21 18:56:51.06 spid4 Node:2
2004-06-21 18:56:51.06 spid4 KEY: 17:1854629650:1 (c702a86ac18e) CleanCnt:2 Mode: X Flags: 0x0
2004-06-21 18:56:51.06 spid4 Grant List 0::
2004-06-21 18:56:51.06 spid4 Owner:0x42bd78a0 Mode: X Flg:0x0 Ref:0 Life:02000000 SPID:77 ECID:0
2004-06-21 18:56:51.06 spid4 SPID: 77 ECID: 0 Statement Type: DELETE Line #: 1
2004-06-21 18:56:51.06 spid4 Input Buf: Language Event: DELETE GlobalVarsRepository WHERE id_sess = 1168875080 AND id_access = 123 AND id_inner = 213260226
2004-06-21 18:56:51.06 spid4 Requested By:
2004-06-21 18:56:51.06 spid4 ResType:LockOwner Stype:'OR' Mode: X SPID:75 ECID:0 Ec:(0x4B4F54E0) Value:0x45b91a80 Cost:(0/0)
2004-06-21 18:56:51.06 spid4
2004-06-21 18:56:51.06 spid4 Node:3
2004-06-21 18:56:51.06 spid4 KEY: 17:1854629650:1 (aa033bbd5b00) CleanCnt:2 Mode: X Flags: 0x0
2004-06-21 18:56:51.06 spid4 Wait List:
2004-06-21 18:56:51.06 spid4 Owner:0x45cecbc0 Mode: U Flg:0x0 Ref:1 Life:02000000 SPID:76 ECID:0
2004-06-21 18:56:51.06 spid4 SPID: 76 ECID: 0 Statement Type: EXECUTE Line #: 1
2004-06-21 18:56:51.06 spid4 Input Buf: RPC Event: sp_cursoropen;1
2004-06-21 18:56:51.06 spid4 Requested By:
2004-06-21 18:56:51.06 spid4 ResType:LockOwner Stype:'OR' Mode: X SPID:77 ECID:0 Ec:(0x4B2774E0) Value:0x42bd62c0 Cost:(0/0)
2004-06-21 18:56:51.06 spid4
2004-06-21 18:56:51.06 spid4 Node:4
2004-06-21 18:56:51.06 spid4 KEY: 17:1854629650:1 (aa033bbd5b00) CleanCnt:2 Mode: X Flags: 0x0
2004-06-21 18:56:51.06 spid4 Grant List 0::
2004-06-21 18:56:51.06 spid4 Owner:0x42bcf120 Mode: X Flg:0x0 Ref:0 Life:02000000 SPID:65 ECID:0
2004-06-21 18:56:51.06 spid4 SPID: 65 ECID: 0 Statement Type: EXECUTE Line #: 1
2004-06-21 18:56:51.06 spid4 Input Buf: RPC Event: sp_cursoropen;1
2004-06-21 18:56:51.06 spid4 Requested By:
2004-06-21 18:56:51.06 spid4 ResType:LockOwner Stype:'OR' Mode: U SPID:76 ECID:0 Ec:(0x4B50B4E0) Value:0x45cecbc0 Cost:(0/0)
2004-06-21 18:56:51.06 spid4 Victim Resource Owner:
2004-06-21 18:56:51.06 spid4 ResType:LockOwner Stype:'OR' Mode: U SPID:76 ECID:0 Ec:(0x4B50B4E0) Value:0x45cecbc0 Cost:(0/0)

Тут вообще непонятно, что за процедура принимает участие(sp_cursoropen). Системная? Или как?

Помогите пожалуйста советом.
21 июн 04, 20:37    [755651]     Ответить | Цитировать Сообщить модератору
 Re: непонятна причина дедлока  [new]
Glory
Member

Откуда:
Сообщений: 104760
https://www.sql.ru/forum/actualthread.aspx?bid=1&tid=83697
21 июн 04, 21:09    [755673]     Ответить | Цитировать Сообщить модератору
 Re: непонятна причина дедлока  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Сколько процессоров на сервере?
21 июн 04, 21:20    [755680]     Ответить | Цитировать Сообщить модератору
 Re: непонятна причина дедлока  [new]
Trace
Guest
Да, топик изучался, но ведь тут немного другая ситуация(объясните пожалуйста, если ошибаюсь):

Deadlock encountered .... Printing deadlock information
2004-06-21 18:56:46.04 spid4
2004-06-21 18:56:46.04 spid4 Wait-for graph
2004-06-21 18:56:46.04 spid4
2004-06-21 18:56:46.04 spid4 Node:1
2004-06-21 18:56:46.04 spid4 KEY: 17:1854629650:1 (ac033130cb26) CleanCnt:1 Mode: X Flags: 0x0
2004-06-21 18:56:46.04 spid4 Grant List 0::
2004-06-21 18:56:46.04 spid4 Owner:0x48c22680 Mode: X Flg:0x0 Ref:0 Life:02000000 SPID:67 ECID:0
2004-06-21 18:56:46.04 spid4 SPID: 67 ECID: 0 Statement Type: DELETE Line #: 1
2004-06-21 18:56:46.04 spid4 Input Buf: Language Event: DELETE GlobalVarsRepository WHERE id_sess = 1168875080 AND id_access = 123 AND id_inner = 213260226
2004-06-21 18:56:46.04 spid4 Requested By:
2004-06-21 18:56:46.04 spid4 ResType:LockOwner Stype:'OR' Mode: X SPID:65 ECID:0 Ec:(0x4B3AF4E0) Value:0x45752800 Cost:(0/130)
2004-06-21 18:56:46.04 spid4
2004-06-21 18:56:46.04 spid4 Node:2
2004-06-21 18:56:46.04 spid4 KEY: 17:1854629650:1 (c702a86ac18e) CleanCnt:1 Mode: X Flags: 0x0
2004-06-21 18:56:46.04 spid4 Grant List 0::
2004-06-21 18:56:46.04 spid4 Owner:0x42bc6920 Mode: X Flg:0x0 Ref:0 Life:02000000 SPID:65 ECID:0
2004-06-21 18:56:46.04 spid4 SPID: 65 ECID: 0 Statement Type: DELETE Line #: 1
2004-06-21 18:56:46.04 spid4 Input Buf: Language Event: DELETE GlobalVarsRepository WHERE id_sess = 1168875080 AND id_access = 123 AND id_inner = 213260226
2004-06-21 18:56:46.04 spid4 Requested By:
2004-06-21 18:56:46.04 spid4 ResType:LockOwner Stype:'OR' Mode: X SPID:67 ECID:0 Ec:(0x4B6174E0) Value:0x48c224a0 Cost:(0/0)

2004-06-21 18:56:46.04 spid4 Victim Resource Owner:
2004-06-21 18:56:46.04 spid4 ResType:LockOwner Stype:'OR' Mode: X SPID:67 ECID:0 Ec:(0x4B6174E0) Value:0x48c224a0 Cost:(0/0)
2004-06-21 18:56:51.06 spid4

Оба процесса владеют Х-блокировкой, и оба ее же запрашивают. Или нет?

ЗЫ: код, который выполняется(в соответствии с топиком вставлены updlock-хинты)

SELECT var_value FROM GlobalVarsRepository with(updlock) WHERE id_sess = 1965875128 AND id_access = 123 AND id_inner = 1234567890 AND var_name = 'tek_sort_field'

SELECT var_value FROM GlobalVarsRepository with(updlock) WHERE id_sess = 1965875128 AND id_access = 123 AND id_inner = 1234567890 AND var_name = 'tek_sort_type'

SELECT var_value FROM GlobalVarsRepository with(updlock) WHERE id_sess = 1965875128 AND id_access = 123 AND id_inner = 1234567890 AND var_name = 'tek_page'

SELECT var_value FROM GlobalVarsRepository with(updlock) WHERE id_sess = 1965875128 AND id_access = 123 AND id_inner = 1234567890 AND var_name = 'filter_type'

SELECT var_value FROM GlobalVarsRepository with(updlock) WHERE id_sess = 1965875128 AND id_access = 123 AND id_inner = 1234567890 AND var_name = 'filter_field'

SELECT var_value FROM GlobalVarsRepository with(updlock) WHERE id_sess = 1965875128 AND id_access = 123 AND id_inner = 1234567890 AND var_name = 'filter_value'

DELETE GlobalVarsRepository WHERE id_sess = 1965875128 AND id_access = 123 AND id_inner = 213260226

SELECT TOP 2147483647 ID FROM GlobalVarsRepository with(updlock) WHERE id_sess = 1965875128 AND id_access = 123 AND id_inner = 213260226 AND var_name = 'tek_sort_field'

INSERT INTO GlobalVarsRepository (id_sess, id_access, id_inner, var_name, var_value, time_to_live, last_access) VALUES (1965875128, 123, 213260226, 'tek_sort_field', 'NULL', 0, CURRENT_TIMESTAMP)

SELECT TOP 2147483647 ID FROM GlobalVarsRepository with(updlock) WHERE id_sess = 1965875128 AND id_access = 123 AND id_inner = 213260226 AND var_name = 'tek_sort_type'

INSERT INTO GlobalVarsRepository (id_sess, id_access, id_inner, var_name, var_value, time_to_live, last_access) VALUES (1965875128, 123, 213260226, 'tek_sort_type', 'NULL', 0, CURRENT_TIMESTAMP)

SELECT TOP 2147483647 ID FROM GlobalVarsRepository with(updlock) WHERE id_sess = 1965875128 AND id_access = 123 AND id_inner = 213260226 AND var_name = 'tek_page'

INSERT INTO GlobalVarsRepository (id_sess, id_access, id_inner, var_name, var_value, time_to_live, last_access) VALUES (1965875128, 123, 213260226, 'tek_page', '1', 0, CURRENT_TIMESTAMP)

SELECT TOP 2147483647 ID FROM GlobalVarsRepository with(updlock) WHERE id_sess = 1965875128 AND id_access = 123 AND id_inner = 213260226 AND var_name = 'filter_type'

INSERT INTO GlobalVarsRepository (id_sess, id_access, id_inner, var_name, var_value, time_to_live, last_access) VALUES (1965875128, 123, 213260226, 'filter_type', '', 0, CURRENT_TIMESTAMP)

SELECT TOP 2147483647 ID FROM GlobalVarsRepository with(updlock) WHERE id_sess = 1965875128 AND id_access = 123 AND id_inner = 213260226 AND var_name = 'filter_field'

INSERT INTO GlobalVarsRepository (id_sess, id_access, id_inner, var_name, var_value, time_to_live, last_access) VALUES (1965875128, 123, 213260226, 'filter_field', '', 0, CURRENT_TIMESTAMP)

SELECT TOP 2147483647 ID FROM GlobalVarsRepository with(updlock) WHERE id_sess = 1965875128 AND id_access = 123 AND id_inner = 213260226 AND var_name = 'filter_value'

INSERT INTO GlobalVarsRepository (id_sess, id_access, id_inner, var_name, var_value, time_to_live, last_access) VALUES (1965875128, 123, 213260226, 'filter_value', '', 0, CURRENT_TIMESTAMP)

UPDATE GlobalVarsRepository with(updlock) SET time_to_live = 0, last_access = CURRENT_TIMESTAMP WHERE id_sess = 1965875128 AND id_access = 123 AND id_inner = 213260226
21 июн 04, 21:21    [755681]     Ответить | Цитировать Сообщить модератору
 Re: непонятна причина дедлока  [new]
Trace
Guest
2 Crimean: два
21 июн 04, 21:24    [755684]     Ответить | Цитировать Сообщить модератору
 Re: непонятна причина дедлока  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
С sp_cursoropen, думаю, проблема в том, что ODBC для возврата данных на клиента делает серверный курсор. Вот тут про это более-менее написано - API Server Cursors
22 июн 04, 10:42    [756278]     Ответить | Цитировать Сообщить модератору
 Re: непонятна причина дедлока  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Trace
в соответствии с топиком вставлены updlock-хинты

Мнэээ. Вот что бывает, когда лепят хинты, не глядя в трейс дедлока.

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

DELETE GlobalVarsRepository WHERE id_sess = 1168875080 AND id_access = 123 AND id_inner = 213260226.

Ну и где потом ваши хинты в коде, приведенном тут??? На delete кто будет хинт ставить?
22 июн 04, 10:52    [756321]     Ответить | Цитировать Сообщить модератору
 Re: непонятна причина дедлока  [new]
Trace
Guest
Вставка updlock(правильно?)-хинта на delete вроде убрала проблему дедлока delete-delete. Но осталась проблема №2(с sp_cursoropen).Причем дедлоки возникают самые разнообразные(их двух, трех узлов, с UDDATE либо DELETE, но всегда с этим вот sp_cursoropen ).Как бороться?
22 июн 04, 11:52    [756618]     Ответить | Цитировать Сообщить модератору
 Re: непонятна причина дедлока  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Вообще мне кажется, что в том топике был прав sadmin, говоря, что хинт надо ставить не updlock, а holdlock. По смыслу-то это и нужно - сказать, чтобы локи держались до конца транзакции/стейтмента.

Что касается ODBC курсоров. К данному дедлоку приводит какой именно код? Все тот же, что вы уже показывали? Если другой, то выложите его.
22 июн 04, 12:14    [756710]     Ответить | Цитировать Сообщить модератору
 Re: непонятна причина дедлока  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Если тот же самый, то возникает вопрос - зачем вам столько select'ов в одном батче? Вы их действительно обрабатываете на клиенте? Множественные рекордсеты? Вопрос второй: приведенный код - это действительно один батч?
22 июн 04, 12:23    [756768]     Ответить | Цитировать Сообщить модератору
 Re: непонятна причина дедлока  [new]
Trace
Guest
Код тот же.
По поводу топика:получается, delete тоже не сразу накладывает эксклюзивную блокировку?
Еще вопрос: как себя ведет SQL Server в случае, если соединение не завершилось корректно? Откатывает незавершенную транзакцию(в данном случае стейтмент)?
22 июн 04, 12:28    [756788]     Ответить | Цитировать Сообщить модератору
 Re: непонятна причина дедлока  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Ну, насчет HOLDLOCK вопрос тот еще

HOLDLOCK

Hold a shared lock until completion of the transaction instead of releasing the lock as soon as the required table, row, or data page is no longer required. HOLDLOCK is equivalent to SERIALIZABLE.

UPDLOCK

Use update locks instead of shared locks while reading a table, and hold locks until the end of the statement or transaction. UPDLOCK has the advantage of allowing you to read data (without blocking other readers) and update it later with the assurance that the data has not changed since you last read it.

А не в s -> x была ли у нас причина дедлока? :)
22 июн 04, 12:33    [756804]     Ответить | Цитировать Сообщить модератору
 Re: непонятна причина дедлока  [new]
Trace
Guest
Приведенный код - это набор запросов, выполняемый в рамках скрипта, множественный запуск которого и приводит к появлению дедлоков. Транзакций нет.
22 июн 04, 12:43    [756874]     Ответить | Цитировать Сообщить модератору
 Re: непонятна причина дедлока  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
2Trace: жду ответа на это
22 июн 04, 12:55    [756947]     Ответить | Цитировать Сообщить модератору
 Re: непонятна причина дедлока  [new]
Trace
Guest
2GreenSunrise:Таблица представляет собой что-то вроде хранилица временных переменных пользователя, вот они с различными целями оттуда и выбираются
22 июн 04, 13:07    [757025]     Ответить | Цитировать Сообщить модератору
 Re: непонятна причина дедлока  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Повторю вопрос - вы действительно в одном батче выбираете несколько рекордсетов и действительно обрабатываете это на клиенте?
22 июн 04, 14:53    [757509]     Ответить | Цитировать Сообщить модератору
 Re: непонятна причина дедлока  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
И стопудово рекордсеты нужны именно серверные?
22 июн 04, 15:01    [757555]     Ответить | Цитировать Сообщить модератору
 Re: непонятна причина дедлока  [new]
Trace
Guest
Объясните тогда что Вы имеете в виду под батчем. Наверное, я не совсем вас понимаю. Стандартно вызывается селект-получить рекордсет-обработать в своих целях-освободить рекордсет.Использование серверных курсоров выставляется в настройках odbc?
22 июн 04, 16:05    [757862]     Ответить | Цитировать Сообщить модератору
 Re: непонятна причина дедлока  [new]
Trace
Guest
ODBC automatically opens a cursor for every result set returned from an SQL statement.
...
The server cursors implemented in Microsoft® SQL Server™ support the functionality of the ODBC cursor model. The SQL Server ODBC driver uses server cursors to support the cursor functionality of the ODBC API.

значит ли это, что серверные курсоры используются всегда? И что же все-таки делать с дедлоками?
22 июн 04, 16:09    [757886]     Ответить | Цитировать Сообщить модератору
 Re: непонятна причина дедлока  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
BOL: A batch is a group of one or more Transact-SQL statements sent at one time from an application to Microsoft® SQL Server™ for execution.

То есть что я хочу от вас добиться - вот эта куча операций выполняется целиком сразу за одно обращение к серверу? Или это несколько последовательных вызовов?

Вы не волнуйтесь :-) Щас до дедлоков дойдем. Откуда они берутся, понятно. Вот выясним детали, будем их лечить.

Trace
delete тоже не сразу накладывает эксклюзивную блокировку?

Сначала любая операция делает вычитку записей, которые удовлетворяют условиям и накладывает блокировки. Какие именно - зависит от уровня изоляции, самого стейтмента и т.д. Потом уже начинается изменение данных и индексов, если это необходимо. Собственно, updlock говорит именно о том, что читать таким образом залоченные ресурсы можно, а наложить exclusive или update блокировку - нет.

Когда вы удаляете записи, вы тем самым затрагиваете два типа ресурсов - строки с данными и индексы. Select'ы ваши тоже накладывают блокировки. Чему был посвящен топик, ссылку на который вам дали с самого начала? Тому, что SQL Server при апдейте слишком быстро отпускает блокировки на индексы.

Trace
как себя ведет SQL Server в случае, если соединение не завершилось корректно? Откатывает незавершенную транзакцию(в данном случае стейтмент)?

Да.

Теперь к вопросу о ваших дедлоках. Поскольку вы меняли хинты, то скиньте сейчас реально работающий и приводящий к дедлокам код, а также распечатку дедлока, как это было в вашем первом посте.

К сожалению, у меня нет опыта работы с ODBC, но судя по тому, какой код в профайлере реально отправляется на сервер, мне кажется, что изменение типа курсора на клиентский должно помочь. Либо еще давайте играться с хинтами. В любом случае код и трейс - сюда.
22 июн 04, 16:48    [758085]     Ответить | Цитировать Сообщить модератору
 Re: непонятна причина дедлока  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Кстати, какая у вас версия сервера? select @@version

Какие еще параметры курсора устанавливаются?

Например, в этой статье FIX: UPDLOCK Locking Option Sets Only Shared Lock with sp_cursor интересная инфа про updlock хинт. Правда, вроде бы относится только к версии 6.5
22 июн 04, 17:46    [758340]     Ответить | Цитировать Сообщить модератору
 Re: непонятна причина дедлока  [new]
Trace
Guest
Прошу прощения, были проблемы с интернетом.

Вообще возникает вопрос, не влияет ли в данной ситуации факт доступа к ms sql через odbc на поведение при блокировках? Ведь, например, начало-конец транзакции осуществляются средствами odbc.

Версия сервера:
Microsoft SQL Server 2000 - 8.00.760 (Intel X86)
Dec 17 2002 14:22:05
Copyright (c) 1988-2003 Microsoft Corporation
Enterprise Edition on Windows NT 5.0 (Build 2195: Service Pack 4)

Хуже всего то, что возникающие дедлоки потрясающе многообразны. Только что последний запуск с целью запостить трейс и код снова выявил блокировку delete-delete...и наличие апдлока не помогло(см. трейс).

Deadlock encountered .... Printing deadlock information
2004-06-22 17:07:01.62 spid4
2004-06-22 17:07:01.62 spid4 Wait-for graph
2004-06-22 17:07:01.62 spid4
2004-06-22 17:07:01.62 spid4 Node:1
2004-06-22 17:07:01.62 spid4 KEY: 17:1854629650:1 (7a02285db75a) CleanCnt:1 Mode: X Flags: 0x0
2004-06-22 17:07:01.62 spid4 Grant List 0::
2004-06-22 17:07:01.62 spid4 Owner:0x42bc5320 Mode: X Flg:0x0 Ref:0 Life:02000000 SPID:75 ECID:0
2004-06-22 17:07:01.62 spid4 SPID: 75 ECID: 0 Statement Type: DELETE Line #: 1
2004-06-22 17:07:01.62 spid4 Input Buf: Language Event: DELETE GlobalVarsRepository with(updlock) WHERE id_sess = 1917043999 AND id_access = 123 AND id_inner = 631439723
2004-06-22 17:07:01.62 spid4 Requested By:
2004-06-22 17:07:01.62 spid4 ResType:LockOwner Stype:'OR' Mode: X SPID:65 ECID:0 Ec:(0x60EEF4E0) Value:0x45745e40 Cost:(0/0)
2004-06-22 17:07:01.62 spid4
2004-06-22 17:07:01.62 spid4 Node:2
2004-06-22 17:07:01.62 spid4 KEY: 17:1854629650:1 (61034f1874f9) CleanCnt:1 Mode: X Flags: 0x0
2004-06-22 17:07:01.62 spid4 Grant List 0::
2004-06-22 17:07:01.62 spid4 Owner:0x42bc8580 Mode: X Flg:0x0 Ref:1 Life:02000000 SPID:65 ECID:0
2004-06-22 17:07:01.62 spid4 SPID: 65 ECID: 0 Statement Type: DELETE Line #: 1
2004-06-22 17:07:01.62 spid4 Input Buf: Language Event: DELETE GlobalVarsRepository with(updlock) WHERE id_sess = 1917043999 AND id_access = 123 AND id_inner = 631439723
2004-06-22 17:07:01.62 spid4 Requested By:
2004-06-22 17:07:01.62 spid4 ResType:LockOwner Stype:'OR' Mode: X SPID:75 ECID:0 Ec:(0x610634E0) Value:0x48c22300 Cost:(0/110)
2004-06-22 17:07:01.62 spid4 Victim Resource Owner:
2004-06-22 17:07:01.62 spid4 ResType:LockOwner Stype:'OR' Mode: X SPID:65 ECID:0 Ec:(0x60EEF4E0) Value:0x45745e40 Cost:(0/0)

Трейс 2:

Deadlock encountered .... Printing deadlock information
2004-06-22 17:06:59.26 spid4
2004-06-22 17:06:59.26 spid4 Wait-for graph
2004-06-22 17:06:59.26 spid4
2004-06-22 17:06:59.26 spid4 Node:1
2004-06-22 17:06:59.26 spid4 KEY: 17:1854629650:1 (7a02285db75a) CleanCnt:2 Mode: X Flags: 0x0
2004-06-22 17:06:59.26 spid4 Wait List:
2004-06-22 17:06:59.26 spid4 Owner:0x45d51580 Mode: X Flg:0x0 Ref:1 Life:02000000 SPID:77 ECID:0
2004-06-22 17:06:59.26 spid4 SPID: 77 ECID: 0 Statement Type: DELETE Line #: 1
2004-06-22 17:06:59.26 spid4 Input Buf: Language Event: DELETE GlobalVarsRepository with(updlock) WHERE id_sess = 1917043999 AND id_access = 123 AND id_inner = 631439723
2004-06-22 17:06:59.26 spid4 Requested By:
2004-06-22 17:06:59.26 spid4 ResType:LockOwner Stype:'OR' Mode: X SPID:65 ECID:0 Ec:(0x60EEF4E0) Value:0x45745e40 Cost:(0/0)
2004-06-22 17:06:59.26 spid4
2004-06-22 17:06:59.26 spid4 Node:2
2004-06-22 17:06:59.26 spid4 KEY: 17:1854629650:1 (7a02285db75a) CleanCnt:2 Mode: X Flags: 0x0
2004-06-22 17:06:59.26 spid4 Grant List 0::
2004-06-22 17:06:59.26 spid4 Owner:0x42bc5320 Mode: X Flg:0x0 Ref:0 Life:02000000 SPID:75 ECID:0
2004-06-22 17:06:59.26 spid4 SPID: 75 ECID: 0 Statement Type: DELETE Line #: 1
2004-06-22 17:06:59.26 spid4 Input Buf: Language Event: DELETE GlobalVarsRepository with(updlock) WHERE id_sess = 1917043999 AND id_access = 123 AND id_inner = 631439723
2004-06-22 17:06:59.26 spid4 Requested By:
2004-06-22 17:06:59.26 spid4 ResType:LockOwner Stype:'OR' Mode: X SPID:77 ECID:0 Ec:(0x610E74E0) Value:0x45d51580 Cost:(0/0)
2004-06-22 17:06:59.26 spid4
2004-06-22 17:06:59.26 spid4 Node:3
2004-06-22 17:06:59.26 spid4 KEY: 17:1854629650:1 (61034f1874f9) CleanCnt:1 Mode: X Flags: 0x0
2004-06-22 17:06:59.26 spid4 Grant List 0::
2004-06-22 17:06:59.26 spid4 Owner:0x42bc8580 Mode: X Flg:0x0 Ref:1 Life:02000000 SPID:65 ECID:0
2004-06-22 17:06:59.26 spid4 SPID: 65 ECID: 0 Statement Type: DELETE Line #: 1
2004-06-22 17:06:59.26 spid4 Input Buf: Language Event: DELETE GlobalVarsRepository with(updlock) WHERE id_sess = 1917043999 AND id_access = 123 AND id_inner = 631439723
2004-06-22 17:06:59.26 spid4 Requested By:
2004-06-22 17:06:59.26 spid4 ResType:LockOwner Stype:'OR' Mode: X SPID:75 ECID:0 Ec:(0x610634E0) Value:0x48c22300 Cost:(0/110)
2004-06-22 17:06:59.26 spid4 Victim Resource Owner:
2004-06-22 17:06:59.26 spid4 ResType:LockOwner Stype:'OR' Mode: X SPID:77 ECID:0 Ec:(0x610E74E0) Value:0x45d51580 Cost:(0/0)
2004-06-22 17:07:00.51 spid4



Код:

SELECT var_value FROM GlobalVarsRepository with(updlock) WHERE id_sess = 1917043999 AND id_access = 123 AND id_inner = 1234567890 AND var_name = 'tek_sort_field'

SELECT var_value FROM GlobalVarsRepository with(updlock) WHERE id_sess = 1917043999 AND id_access = 123 AND id_inner = 1234567890 AND var_name = 'tek_sort_type'

SELECT var_value FROM GlobalVarsRepository with(updlock) WHERE id_sess = 1917043999 AND id_access = 123 AND id_inner = 1234567890 AND var_name = 'tek_page'

SELECT var_value FROM GlobalVarsRepository with(updlock) WHERE id_sess = 1917043999 AND id_access = 123 AND id_inner = 1234567890 AND var_name = 'filter_type'

SELECT var_value FROM GlobalVarsRepository with(updlock) WHERE id_sess = 1917043999 AND id_access = 123 AND id_inner = 1234567890 AND var_name = 'filter_field'

SELECT var_value FROM GlobalVarsRepository with(updlock) WHERE id_sess = 1917043999 AND id_access = 123 AND id_inner = 1234567890 AND var_name = 'filter_value'

DELETE GlobalVarsRepository with(updlock) WHERE id_sess = 1917043999 AND id_access = 123 AND id_inner = 631439723

SELECT TOP 2147483647 ID FROM GlobalVarsRepository with(updlock) WHERE id_sess = 1917043999 AND id_access = 123 AND id_inner = 631439723 AND var_name = 'tek_sort_field'

INSERT INTO GlobalVarsRepository with(updlock) (id_sess, id_access, id_inner, var_name, var_value, time_to_live, last_access) VALUES (1917043999, 123, 631439723, 'tek_sort_field', 'NULL', 0, CURRENT_TIMESTAMP)

SELECT TOP 2147483647 ID FROM GlobalVarsRepository with(updlock) WHERE id_sess = 1917043999 AND id_access = 123 AND id_inner = 631439723 AND var_name = 'tek_sort_type'

INSERT INTO GlobalVarsRepository with(updlock) (id_sess, id_access, id_inner, var_name, var_value, time_to_live, last_access) VALUES (1917043999, 123, 631439723, 'tek_sort_type', 'NULL', 0, CURRENT_TIMESTAMP)

SELECT TOP 2147483647 ID FROM GlobalVarsRepository with(updlock) WHERE id_sess = 1917043999 AND id_access = 123 AND id_inner = 631439723 AND var_name = 'tek_page'

INSERT INTO GlobalVarsRepository with(updlock) (id_sess, id_access, id_inner, var_name, var_value, time_to_live, last_access) VALUES (1917043999, 123, 631439723, 'tek_page', '1', 0, CURRENT_TIMESTAMP)

SELECT TOP 2147483647 ID FROM GlobalVarsRepository with(updlock) WHERE id_sess = 1917043999 AND id_access = 123 AND id_inner = 631439723 AND var_name = 'filter_type'

INSERT INTO GlobalVarsRepository with(updlock) (id_sess, id_access, id_inner, var_name, var_value, time_to_live, last_access) VALUES (1917043999, 123, 631439723, 'filter_type', '', 0, CURRENT_TIMESTAMP)

SELECT TOP 2147483647 ID FROM GlobalVarsRepository with(updlock) WHERE id_sess = 1917043999 AND id_access = 123 AND id_inner = 631439723 AND var_name = 'filter_field'

INSERT INTO GlobalVarsRepository with(updlock) (id_sess, id_access, id_inner, var_name, var_value, time_to_live, last_access) VALUES (1917043999, 123, 631439723, 'filter_field', '', 0, CURRENT_TIMESTAMP)

SELECT TOP 2147483647 ID FROM GlobalVarsRepository with(updlock) WHERE id_sess = 1917043999 AND id_access = 123 AND id_inner = 631439723 AND var_name = 'filter_value'

INSERT INTO GlobalVarsRepository with(updlock) (id_sess, id_access, id_inner, var_name, var_value, time_to_live, last_access) VALUES (1917043999, 123, 631439723, 'filter_value', '', 0, CURRENT_TIMESTAMP)

UPDATE GlobalVarsRepository with(updlock) SET time_to_live = 0, last_access = CURRENT_TIMESTAMP WHERE id_sess = 1917043999 AND id_access = 123 AND id_inner = 631439723


Чувствую, скоро полезу на стенку.
22 июн 04, 18:21    [758489]     Ответить | Цитировать Сообщить модератору
 Re: непонятна причина дедлока  [new]
Trace
Guest
Информация насчет updlock очень интересная... а что интересно в 2000 по этому поводу?
22 июн 04, 18:23    [758497]     Ответить | Цитировать Сообщить модератору
 Re: непонятна причина дедлока  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Trace
не влияет ли в данной ситуации факт доступа к ms sql через odbc на поведение при блокировках?

Ну дык я вам о чем твержу все это время? :-) Что способ доступа, который применяет ODBC, важен. Потому и пытаюсь добиться всяческих подробностей.

Не, мне совсем не впадлу задать следующие вопросы еще и еще раз:

То есть что я хочу от вас добиться - вот эта куча операций выполняется целиком сразу за одно обращение к серверу? Или это несколько последовательных вызовов?

Кстати, какая у вас версия сервера? select @@version

Какие еще параметры курсора устанавливаются?
22 июн 04, 18:32    [758516]     Ответить | Цитировать Сообщить модератору
 Re: непонятна причина дедлока  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
По поводу вашего кода.

Поправьте меня, если я ошибаюсь, но select with (updlock) в отсутствии транзакции смысла не имеет.

В чем козырность вот этого финта (не путать с хинтом ;-)) - SELECT TOP 2147483647 ID ?

Еще я не понимаю, в чем козырность создания кластерного индекса на 4 поля. Primary key'я на ID identity нету, зато есть кластерный индекс на 4 поля... Меня это изрядно смущает.

Crimean, присоединяйтесь! Чего я в одиночестве отдуваюсь? Вместе мы счас эти дедлоки в момент заломаем!
22 июн 04, 18:52    [758560]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить