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

Откуда:
Сообщений: 681
deadlock graph вот такой:
<deadlock-list>
<deadlock victim="processaf3dc8">
<process-list>
<process id="processaf3dc8" taskpriority="0" logused="24204" waitresource="KEY: 7:72057595015856128 (a80278ca2a04)" waittime="4996" ownerId="1376904438" transactionname="user_transaction" lasttranstarted="2012-01-30T09:56:41.213" XDES="0x16671b5970" lockMode="U" schedulerid="10" kpid="6028" status="suspended" spid="100" sbid="0" ecid="0" priority="0" trancount="2" lastbatchstarted="2012-01-30T09:56:41.233" lastbatchcompleted="2012-01-30T09:56:41.230" clientapp="1CV81 Server" hostname="server2" hostpid="2496" loginname="1c" isolationlevel="read committed (2)" xactid="1376904438" currentdb="7" lockTimeout="20000" clientoption1="671219744" clientoption2="128056">
<executionStack>
<frame procname="adhoc" line="1" stmtstart="1154" sqlhandle="0x02000000b3f6102a9b2c3f1176a30018c9adf401e6cae035">
UPDATE _ReferenceChangeRec504
SET
_MessageNo = CAST(@P1 AS NUMERIC(10,0))
FROM _ReferenceChangeRec504 WITH(REPEATABLEREAD)
WHERE
_ReferenceChangeRec504._IDRRef = @P2 AND _ReferenceChangeRec504._NodeTRef = @P3 AND _ReferenceChangeRec504._NodeRRef IN (@P4,@P5,@P6,@P7,@P8,@P9,@P10,@P11,
@P12,@P13,@P14,@P15,@P16,@P17,@P18,@P19,
@P20,@P21,@P22,@P23,@P24,@P25,@P26,@P27,
@P28,@P29,@P30,@P31) </frame>
<frame procname="unknown" line="1" sqlhandle="0x000000000000000000000000000000000000000000000000">
unknown </frame>
</executionStack>
<inputbuf>
(@P1 numeric(1),@P2 varbinary(16),@P3 varbinary(4),@P4 varbinary(16),@P5 varbinary(16),@P6 varbinary(16),@P7 varbinary(16),@P8 varbinary(16),@P9 varbinary(16),@P10 varbinary(16),@P11 varbinary(16),@P12 varbinary(16),@P13 varbinary(16),@P14 varbinary(16),@P15 varbinary(16),@P16 varbinary(16),@P17 varbinary(16),@P18 varbinary(16),@P19 varbinary(16),@P20 varbinary(16),@P21 varbinary(16),@P22 varbinary(16),@P23 varbinary(16),@P24 varbinary(16),@P25 varbinary(16),@P26 varbinary(16),@P27 varbinary(16),@P28 varbinary(16),@P29 varbinary(16),@P30 varbinary(16),@P31 varbinary(16))UPDATE _ReferenceChangeRec504
SET
_MessageNo = CAST(@P1 AS NUMERIC(10,0))
FROM _ReferenceChangeRec504 WITH(REPEATABLEREAD)
WHERE
_ReferenceChangeRec504._IDRRef = @P2 AND _ReferenceChangeRec504._NodeTRef = @P3 AND _ReferenceChangeRec504._NodeRRef IN (@P4,@P5,@P6,@P7,@P8,@P9,@P10,@P11,
@P12,@P13,@P14,@P15,@P16,@P17,@P18,@P19,
@P20,@P21,@P22,@P23,@P24,@P25,@P26,@P27,
@P28,@P29,@P30,@P31) </inputbuf>
</process>
<process id="process8cf0988" taskpriority="0" logused="2208636" waitresource="KEY: 7:72057594168082432 (5d018d74d1d8)" waittime="900" ownerId="1376894037" transactionname="user_transaction" lasttranstarted="2012-01-30T09:56:31.167" XDES="0x7727b3970" lockMode="S" schedulerid="18" kpid="6448" status="suspended" spid="89" sbid="0" ecid="0" priority="0" trancount="1" lastbatchstarted="2012-01-30T09:56:45.333" lastbatchcompleted="2012-01-30T09:56:45.327" clientapp="1CV81 Server" hostname="server2" hostpid="2680" loginname="1c" isolationlevel="repeatable read (3)" xactid="1376894037" currentdb="7" lockTimeout="20000" clientoption1="671219744" clientoption2="128056">
<executionStack>
<frame procname="adhoc" line="1" stmtstart="38" sqlhandle="0x0200000029c7f7028f40be9e6ea54a690b0b597c2c5ddd7f">
SELECT
_Reference39._IDRRef AS f_1,
CAST(_Reference39._Version AS BINARY(8)) AS f_2,
_Reference39._Marked AS f_3,
_Reference39._IsMetadata AS f_4,
_Reference39._OwnerIDRRef AS f_5,
_Reference39._ParentIDRRef AS f_6,
_Reference39._Folder AS f_7,
_Reference39._Description AS f_8,
_Reference39._Fld494RRef AS f_9,
_Reference39._Fld495 AS f_10,
_Reference39._Fld496 AS f_11,
_Reference39._Fld497 AS f_12,
_Reference39._Fld498 AS f_13,
_Reference39._Fld499 AS f_14,
_Reference39._Fld500 AS f_15
FROM
_Reference39 WITH(REPEATABLEREAD)
WHERE
_Reference39._IDRRef = @P1 </frame>
<frame procname="unknown" line="1" sqlhandle="0x000000000000000000000000000000000000000000000000">
unknown </frame>
</executionStack>
<inputbuf>
(@P1 varbinary(16))SELECT
_Reference39._IDRRef AS f_1,
CAST(_Reference39._Version AS BINARY(8)) AS f_2,
_Reference39._Marked AS f_3,
_Reference39._IsMetadata AS f_4,
_Reference39._OwnerIDRRef AS f_5,
_Reference39._ParentIDRRef AS f_6,
_Reference39._Folder AS f_7,
_Reference39._Description AS f_8,
_Reference39._Fld494RRef AS f_9,
_Reference39._Fld495 AS f_10,
_Reference39._Fld496 AS f_11,
_Reference39._Fld497 AS f_12,
_Reference39._Fld498 AS f_13,
_Reference39._Fld499 AS f_14,
_Reference39._Fld500 AS f_15
FROM
_Reference39 WITH(REPEATABLEREAD)
WHERE
_Reference39._IDRRef = @P1 </inputbuf>
</process>
</process-list>
<resource-list>
<keylock hobtid="72057595015856128" dbid="7" objectname="DB2.dbo._ReferenceChangeRec504" indexname="_Referen504_ByDataKey_RR" id="lock116cde4080" mode="X" associatedObjectId="72057595015856128">
<owner-list>
<owner id="process8cf0988" mode="X"/>
</owner-list>
<waiter-list>
<waiter id="processaf3dc8" mode="U" requestType="wait"/>
</waiter-list>
</keylock>
<keylock hobtid="72057594168082432" dbid="7" objectname="DB2.dbo._Reference39" indexname="PK___Referen__AC8ED0C401892CED" id="lock134b85ae00" mode="X" associatedObjectId="72057594168082432">
<owner-list>
<owner id="processaf3dc8" mode="X"/>
</owner-list>
<waiter-list>
<waiter id="process8cf0988" mode="S" requestType="wait"/>
</waiter-list>
</keylock>
</resource-list>
</deadlock>
</deadlock-list>
30 янв 12, 10:52    [11994601]     Ответить | Цитировать Сообщить модератору
 Re: Помогите проанализировать deadlock graph  [new]
WarAnt
Member

Откуда: Питер
Сообщений: 2423
beaver06,

и чего вам тут не понятно?
REPEATABLEREAD и update создают ядерную смесь блокировок, которая и выражается в дедлоке
30 янв 12, 11:11    [11994759]     Ответить | Цитировать Сообщить модератору
 Re: Помогите проанализировать deadlock graph  [new]
beaver06
Member

Откуда:
Сообщений: 681
WarAnt,
это-то понятно, просто хочется понять как это перевести на русский язык. Т.е. например такой-то запрос блокирует такой-то ресурс и т.д.
30 янв 12, 11:28    [11994911]     Ответить | Цитировать Сообщить модератору
 Re: Помогите проанализировать deadlock graph  [new]
beaver06
Member

Откуда:
Сообщений: 681
и хотелось бы понять всю цепочку происходящего
30 янв 12, 11:34    [11994950]     Ответить | Цитировать Сообщить модератору
 Re: Помогите проанализировать deadlock graph  [new]
WarAnt
Member

Откуда: Питер
Сообщений: 2423
beaver06
и хотелось бы понять всю цепочку происходящего


для понятия цепочки данных маловато, надо структуру этих таблиц как минимум
30 янв 12, 11:52    [11995093]     Ответить | Цитировать Сообщить модератору
 Re: Помогите проанализировать deadlock graph  [new]
beaver06
Member

Откуда:
Сообщений: 681
WarAnt,
а из графа можно ведь понять хотя бы скелет происходящего?
Т.е. вот что я понял отсюда:
при SELECT from _Reference39 WITH(REPEATABLEREAD) происходит монопольная блокировка ресурса _Reference39 ("process8cf0988" mode="X"), при этом идет попытка UPDATE _ReferenceChangeRec504 FROM _ReferenceChangeRec504 WITH(REPEATABLEREAD) (id="processaf3dc8" mode="U" requestType="wait").
Параллельно с этим происходит другой процесс: UPDATE _ReferenceChangeRec504 FROM _ReferenceChangeRec504 WITH(REPEATABLEREAD) (id="processaf3dc8" mode="X") и SELECT from _Reference39 WITH(REPEATABLEREAD) (id="process8cf0988" mode="S" requestType="wait").

Я не прав?
30 янв 12, 12:20    [11995310]     Ответить | Цитировать Сообщить модератору
 Re: Помогите проанализировать deadlock graph  [new]
denis2710
Member

Откуда: Москва
Сообщений: 3384
beaver06,
У запроса SPID =100 (UPDATE _ReferenceChangeRec504 SET _MessageNo = CAST(@P1 AS NUMERIC(10,0))
FROM _ReferenceChangeRec504 WITH(REPEATABLEREAD) WHERE ...)
есть х-блокировка(эксклюзивная) на ключ из PK___Referen__AC8ED0C401892CED DB2.dbo._Reference39

У запроса SPID=89(SELECT
_Reference39._IDRRef AS f_1,
CAST(_Reference39._Version AS BINARY(8)) AS f_2 ... FROM _Reference39 WITH(REPEATABLEREAD) ...)
есть х-блокировка(эксклюзивная) на ключ из _Referen504_ByDataKey_RR DB2.dbo._ReferenceChangeRec504

SPID =100 запрашивает блокировку на update ключа индекса из _Referen504_ByDataKey_RR DB2.dbo._ReferenceChangeRec504,на котором х-блокировка SPID=89.
А SPID=89 запрашивает совмещенную блокировку на ключ из PK___Referen__AC8ED0C401892CED DB2.dbo._Reference39, на котором х-блокировка SPID=100. WITH(REPEATABLEREAD) удерживает блокировки на соотв. ресурсах до окончания транзакции,и по тайм ауту сервер срубает deadlock/
Классика жанра :)
Зачем и почему это к 1С.
30 янв 12, 12:23    [11995340]     Ответить | Цитировать Сообщить модератору
 Re: Помогите проанализировать deadlock graph  [new]
beaver06
Member

Откуда:
Сообщений: 681
denis2710,
Спасибо большое
30 янв 12, 12:27    [11995375]     Ответить | Цитировать Сообщить модератору
 Re: Помогите проанализировать deadlock graph  [new]
beaver06
Member

Откуда:
Сообщений: 681
denis2710
beaver06,
У запроса SPID =100 (UPDATE _ReferenceChangeRec504 SET _MessageNo = CAST(@P1 AS NUMERIC(10,0))
FROM _ReferenceChangeRec504 WITH(REPEATABLEREAD) WHERE ...)
есть х-блокировка(эксклюзивная) на ключ из PK___Referen__AC8ED0C401892CED DB2.dbo._Reference39

У запроса SPID=89(SELECT
_Reference39._IDRRef AS f_1,
CAST(_Reference39._Version AS BINARY(8)) AS f_2 ... FROM _Reference39 WITH(REPEATABLEREAD) ...)
есть х-блокировка(эксклюзивная) на ключ из _Referen504_ByDataKey_RR DB2.dbo._ReferenceChangeRec504

SPID =100 запрашивает блокировку на update ключа индекса из _Referen504_ByDataKey_RR DB2.dbo._ReferenceChangeRec504,на котором х-блокировка SPID=89.
А SPID=89 запрашивает совмещенную блокировку на ключ из PK___Referen__AC8ED0C401892CED DB2.dbo._Reference39, на котором х-блокировка SPID=100. WITH(REPEATABLEREAD) удерживает блокировки на соотв. ресурсах до окончания транзакции,и по тайм ауту сервер срубает deadlock/
Классика жанра :)
Зачем и почему это к 1С.


Это же по любому ненормально и требует устранения? Или deadlock в каких-то случаях может быть осознанным и не требует устранения проблемы?
30 янв 12, 12:58    [11995613]     Ответить | Цитировать Сообщить модератору
 Re: Помогите проанализировать deadlock graph  [new]
denis2710
Member

Откуда: Москва
Сообщений: 3384
beaver06,
C deadlock'ами надо что-то делать.База давно обслуживалась?
30 янв 12, 13:04    [11995664]     Ответить | Цитировать Сообщить модератору
 Re: Помогите проанализировать deadlock graph  [new]
beaver06
Member

Откуда:
Сообщений: 681
denis2710
beaver06,
C deadlock'ами надо что-то делать.База давно обслуживалась?

Что значит обслуживалась?
Я недавно взялся за эту БД. настроил планы обслуживания: обновление статистики, обслуживание индексов, backup - ы. В данное время принялся за отслеживание и устранение deadlock - ов. За данным deadlock - ом наблюдаю вторую неделю. Он периодически возникает: несколько раз в сутки. Вот сейчас хочу передать проблему 1С - кам.
30 янв 12, 13:08    [11995706]     Ответить | Цитировать Сообщить модератору
 Re: Помогите проанализировать deadlock graph  [new]
denis2710
Member

Откуда: Москва
Сообщений: 3384
beaver06,
beaver06
Что значит обслуживалась? ..обновление статистики, обслуживание индексов..

то и значит :)
Несколько раз сталкивался,что 8.1 работает с большими тормозами(оно так написано),а в 8.2 уже работает более адекватно.
30 янв 12, 13:16    [11995776]     Ответить | Цитировать Сообщить модератору
 Re: Помогите проанализировать deadlock graph  [new]
beaver06
Member

Откуда:
Сообщений: 681
denis2710,
у меня 8.1. Вообщем заставить разобраться с проблемой 1С - ков.
30 янв 12, 13:17    [11995784]     Ответить | Цитировать Сообщить модератору
 Re: Помогите проанализировать deadlock graph  [new]
denis2710
Member

Откуда: Москва
Сообщений: 3384
beaver06
denis2710,
у меня 8.1. Вообщем заставить разобраться с проблемой 1С - ков.

Это видно,что 8.1,по этому и сказал про 8.1 и 8.2
beaver06
clientapp="1CV81 Server"
30 янв 12, 14:19    [11996402]     Ответить | Цитировать Сообщить модератору
 Re: Помогите проанализировать deadlock graph  [new]
beaver06
Member

Откуда:
Сообщений: 681
denis2710
beaver06
denis2710,
у меня 8.1. Вообщем заставить разобраться с проблемой 1С - ков.

Это видно,что 8.1,по этому и сказал про 8.1 и 8.2
beaver06
clientapp="1CV81 Server"

Ну да...
30 янв 12, 16:35    [11997752]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить