DeadLock / Microsoft SQL Server

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / DeadLock

13 сообщений из 13, страница 1 из 1

DeadLock

#40114441

PaulWist

Участник

Сообщения: 2 607

Рейтинг: 0 / 0

Дано:

Microsoft SQL Server 2012 (SP4-GDR) (KB4583465) - 11.0.7507.2 (X64) Nov 1 2020 00:48:37 Copyright (c) Microsoft Corporation Standard Edition (64-bit) on Windows NT 6.3 <X64> (Build 9600: ) (Hypervisor)

Табличка (1.5 млн записей):

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.

CREATE TABLE [dbo].[ART_PARAMS](
	[ART_ID] [int] NOT NULL,
	[CODE_INFOR_ERP] [varchar](47) NULL,
	[STATUS] [varchar](20) NULL,
	[ALTERN_D2] [varchar](47) NULL,
	[IZGOTOVITEL] [varchar](252) NULL,
 CONSTRAINT [PK_ART_PARAMS] PRIMARY KEY CLUSTERED 
(
	[ART_ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

GO

ALTER TABLE [dbo].[ART_PARAMS]  WITH CHECK ADD  CONSTRAINT [FK_ARTPARAMS] FOREIGN KEY([ART_ID])
REFERENCES [dbo].[ARTICLES] ([ART_ID])
GO

ALTER TABLE [dbo].[ART_PARAMS] CHECK CONSTRAINT [FK_ARTPARAMS]
GO

CREATE NONCLUSTERED INDEX [ART_PARAMS_CODE_INFOR_ERP_NDX] ON [dbo].[ART_PARAMS]
(
	[CODE_INFOR_ERP] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO

Граф:

<deadlock>
<victim-list>
<victimProcess id="processd3f90d0c8" />
</victim-list>
<process-list>
<process id="processd3f90d0c8" taskpriority="0" logused="0" waitresource="PAGE: 5:1:66942918 " waittime="7999" ownerId="1926158621" transactionname="UPDATE" lasttranstarted="2021-11-23T14:00:09.610" XDES="0x6cb7343a8" lockMode="U" schedulerid="16" kpid="5140" status="suspended" spid="2474" sbid="0" ecid="0" priority="0" trancount="2" lastbatchstarted="2021-11-23T14:00:04.163" lastbatchcompleted="2021-11-23T14:00:04.163" lastattention="1900-01-01T00:00:00.163" clientapp="SQLAgent - TSQL JobStep (Job 0x82306FD409770E46904B4506C3629CE4 : Step 2)" hostname="NEM-PDM-01" hostpid="5620" loginname="NEM\admin_sql_pdm" isolationlevel="read committed (2)" xactid="1926158621" currentdb="7" lockTimeout="4294967295" clientoption1="673185824" clientoption2="128056">
<executionStack>
<frame procname="INTEGRATION.dbo.GAL_CREATE_CODEREQUEST_NEW_02D2" line="91" stmtstart="9180" stmtend="9596" sqlhandle="0x03000700e54db542359f110147ad000001000000000000000000000000000000000000000000000000000000">
UPDATE Search.dbo.ART_PARAMS SET STATUS='+' where STATUS='+++'
-- </frame>
<frame procname="adhoc" line="4" stmtstart="162" sqlhandle="0x01000700e9c23a2040c6b5ce0700000000000000000000000000000000000000000000000000000000000000">
exec GAL_CREATE_CODEREQUEST_NEW_02D2 </frame>
</executionStack>
<inputbuf>
exec GAL_CREATE_CODEREQUEST_NEW_02D2 </inputbuf>
</process>
<process id="processd3f064cf8" taskpriority="0" logused="100992" waitresource="PAGE: 5:1:66942916 " waittime="4952" ownerId="1926129050" transactionname="user_transaction" lasttranstarted="2021-11-23T13:59:57.573" XDES="0x416c396a8" lockMode="IU" schedulerid="11" kpid="7048" status="suspended" spid="695" sbid="0" ecid="0" priority="0" trancount="2" lastbatchstarted="2021-11-23T14:00:12.757" lastbatchcompleted="2021-11-23T14:00:12.757" lastattention="1900-01-01T00:00:00.757" hostpid="468" loginname="sysdba" isolationlevel="read uncommitted (1)" xactid="1926129050" currentdb="5" lockTimeout="4294967295" clientoption1="32" clientoption2="16416">
<executionStack>
<frame procname="adhoc" line="1" stmtstart="50" sqlhandle="0x02000000369e5a02b9522aaf10631005de1c1d05920e689f0000000000000000000000000000000000000000">
UPDATE [ART_PARAMS] set

Код: _INFOR_ERP

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.

 = @1  WHERE [ART_ID]=@2    </frame>
    <frame procname="adhoc" line="1" sqlhandle="0x02000000e9418d387c53824cff658a37934691d223d11f440000000000000000000000000000000000000000">
UPDATE ART_PARAMS SET CODE_INFOR_ERP = 'D2122001.0.11.026671' WHERE ART_ID = 1171866    </frame>
   </executionStack>
   <inputbuf>
UPDATE ART_PARAMS SET CODE_INFOR_ERP = 'D2122001.0.11.026671' WHERE ART_ID = 1171866   </inputbuf>
  </process>
 </process-list>
 <resource-list>
  <pagelock fileid="1" pageid="66942918" dbid="5" subresource="FULL" objectname="search.dbo.ART_PARAMS" id="lockb863c9c80" mode="IX" associatedObjectId="72057597674586112">
   <owner-list>
    <owner id="processd3f064cf8" mode="IX" />
   </owner-list>
   <waiter-list>
    <waiter id="processd3f90d0c8" mode="U" requestType="wait" />
   </waiter-list>
  </pagelock>
  <pagelock fileid="1" pageid="66942916" dbid="5" subresource="FULL" objectname="search.dbo.ART_PARAMS" id="lock50d027f00" mode="U" associatedObjectId="72057597674586112">
   <owner-list>
    <owner id="processd3f90d0c8" mode="U" />
   </owner-list>
   <waiter-list>
    <waiter id="processd3f064cf8" mode="IU" requestType="wait" />
   </waiter-list>
  </pagelock>
 </resource-list>
</deadlock>

 

По графу (слева направо):

Процесс process id="processd3f90d 0c8 ", spid="2474" выполняет сканирование "таблички" и обновление:
 
 [code=sql]
UPDATE Search.dbo.ART_PARAMS SET STATUS='+' where STATUS='+++'

на страницу PAGE: 5:1:6694291 6 получил mode="U", затребовал получение lockMode="U" на страницу PAGE: 5:1:6694291 8 - тут всё понятно!!!

Процесс process id="processd3f064 cf8 , spid="695" обновляет по первичному кластерному индексу одну запись:

Код: sql

UPDATE ART_PARAMS SET CODE_INFOR_ERP = 'D2122001.0.11.026671' WHERE ART_ID = 1171866

причём на страницу PAGE: 5:1:6694291 8 получил mode="IX" и затребовал на страницу PAGE: 5:1:6694291 6 получение lockMode="IU".

Как бы DeadLock налицо.

Вопрос: нафига process id="processd3f064 cf8 , spid="695" получил mode="IX" на страницу PAGE: 5:1:6694291 8 ведь он обновляет запись по кластерному индексу ???

...

Рейтинг:

0 / 0

24.11.2021, 10:09

| Ответить | Цитировать | Написать

DeadLock

#40114447

Владислав Колосов

Участник

Сообщения: 9 447

Рейтинг: 0 / 0

PaulWist,

надо смотреть - что находится на этой странице. Иначе можно долго гадать :)

...

Рейтинг:

0 / 0

24.11.2021, 10:46

| Ответить | Цитировать | Написать

DeadLock

#40114449

PaulWist

Участник

Сообщения: 2 607

Рейтинг: 0 / 0

Владислав Колосов,

Как посмотреть и что надо искать???

...

Рейтинг:

0 / 0

24.11.2021, 10:52

| Ответить | Цитировать | Написать

DeadLock

#40114457

msLex

Участник

Сообщения: 8 523

Рейтинг: 0 / 0

PaulWist

Вопрос: нафига process id="processd3f064 cf8 , spid="695" получил mode="IX" на страницу PAGE: 5:1:6694291 8 ведь он обновляет запись по кластерному индексу ???

А вы знаете для чего нужны I(ntent) lock-и?

При наложении любой "обычной" блокировки, на все объекты большей гранулярности накладывают соответствующие Intent блокировки. Например, при X блокировки на ключ, накладываются IX блокировки на страницу и таблицы.

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

Пример

1-й процесс запустил массовое удаление записей, и SQL Engine "решил" не блокировать отдельные записи, а блокировать целиком страницы, т.е. накладывать X блокировки на PAGE

2-й процесс запустил изменение 1 записи по ключу, и хочет наложить X блокировку на KEY

Если бы не было Intent блокировок, 2-му процессу пришлось бы проверять наличие несовместимый блокировок всех уровней (PAGE, TABLE), а 1-му, помимо проверки верхних уровней (TABLE), нужно проверять все "подобъекты", т.е. нет ли несовместимых KEY блокировок на каждой записи на странице?

Что будет, если какой-то процесс захочет наложить блокировку на уровне терабайтной таблицы можно приставить.

Вместо этого, любой lock дублируется I lock на уровне выше, и все сравнения допустимости блокировок сводятся к проверки в рамках конкретного объекта.

...

Рейтинг:

0 / 0

24.11.2021, 11:11

| Ответить | Цитировать | Написать

DeadLock

#40114469

PaulWist

Участник

Сообщения: 2 607

Рейтинг: 0 / 0

msLex

Пример

1-й процесс запустил массовое удаление записей, и SQL Engine "решил" не блокировать отдельные записи, а блокировать целиком страницы, т.е. накладывать X блокировки на PAGE

2-й процесс запустил изменение 1 записи по ключу, и хочет наложить X блокировку на KEY

Если бы не было Intent блокировок, 2-му процессу пришлось бы проверять наличие несовместимый блокировок всех уровней (PAGE, TABLE), а 1-му, помимо проверки верхних уровней (TABLE), нужно проверять все "подобъекты", т.е. нет ли несовместимых KEY блокировок на каждой записи на странице?

Что будет, если какой-то процесс захочет наложить блокировку на уровне терабайтной таблицы можно приставить.

Вместо этого, любой lock дублируется I lock на уровне выше, и все сравнения допустимости блокировок сводятся к проверки в рамках конкретного объекта.

ОК.

Давайте рассмотрим "Ваш пример" на конкретном, приведенном deadlock, первый процесс (тот который слева, отстреленный), обновляет сканируя таблицу, те идёт по листовому уровню кластерного индекса получая U блокировку и натыкается на страницу листового уровня, которую заблокировал IX второй процесс обновляющий по кластерному ключу.

По логике, второй процесс должен был наложить IX блокировку на таблицу, но не как не на листовую страницу.

Вот нафига, второму процессу блокировать две страницы листового уровня???

...

Рейтинг:

0 / 0

24.11.2021, 11:39

| Ответить | Цитировать | Написать

DeadLock

#40114488

msLex

Участник

Сообщения: 8 523

Рейтинг: 0 / 0

PaulWist

msLex

кластерный и некластерный индекс

...

Рейтинг:

0 / 0

24.11.2021, 12:49

| Ответить | Цитировать | Написать

DeadLock

#40114501

PaulWist

Участник

Сообщения: 2 607

Рейтинг: 0 / 0

msLex

кластерный и некластерный индекс

Ааа, Семён Семёныч (с) Брил. рука

Спасибо!!!

...

Рейтинг:

0 / 0

24.11.2021, 13:27

| Ответить | Цитировать | Написать

DeadLock

#40114505

felix_ff

Участник

Откуда: Moscow

Сообщения: 1 982

Рейтинг: 0 / 0

PaulWist,

только партиция одинаковая.

что показывает:

Код: sql

select object_name(object_id), object_id, index_id, partition_number from sys.partitions where partition_id = 72057597674586112

add:
да и в принципе можно заголовок страниц :

Код: sql

1.
2.

dbcc page (5, 1, 66942918, 0) with tableresults;
dbcc page (5, 1, 66942916, 0) with tableresults;

...

Рейтинг:

0 / 0

24.11.2021, 13:34

| Ответить | Цитировать | Написать

DeadLock

#40114534

PaulWist

Участник

Сообщения: 2 607

Рейтинг: 0 / 0

felix_ff

PaulWist,

только партиция одинаковая.

что показывает:

Код: sql

select object_name(object_id), object_id, index_id, partition_number from sys.partitions where partition_id = 72057597674586112

object_name object_id index_idpartition_numberART_PARAMS 1868689855 1 1

???

...

Рейтинг:

0 / 0

24.11.2021, 14:46

| Ответить | Цитировать | Написать

DeadLock

#40114545

felix_ff

Участник

Откуда: Moscow

Сообщения: 1 982

Рейтинг: 0 / 0

PaulWist,

предположу что у вас
страница 66942916 m_type=2
страница 66942918 m_type = 1

...

Рейтинг:

0 / 0

24.11.2021, 15:03

| Ответить | Цитировать | Написать

DeadLock

#40114547

PaulWist

Участник

Сообщения: 2 607

Рейтинг: 0 / 0

felix_ff

PaulWist,

предположу что у вас
страница 66942916 m_type=2
страница 66942918 m_type = 1

Я тоже сначала так предположил, НО m_type = 1 для обоих страниц.

Картинка не пристёгивается :(

...

Рейтинг:

0 / 0

24.11.2021, 15:19

| Ответить | Цитировать | Написать

DeadLock

#40114585

invm

Участник

Откуда: Москва

Сообщения: 9 956

Рейтинг: 0 / 0

PaulWist

Код: sql

UPDATE ART_PARAMS SET CODE_INFOR_ERP = 'D2122001.0.11.026671' WHERE ART_ID = 1171866

Похоже, что в этой транзакции есть ранее еще такой же апдейт с ART_ID, большим 1171866

...

Рейтинг:

0 / 0

24.11.2021, 16:27

| Ответить | Цитировать | Написать

DeadLock

#40114735

PaulWist

Участник

Сообщения: 2 607

Рейтинг: 0 / 0

invm

Похоже, что в этой транзакции есть ранее еще такой же апдейт с ART_ID, большим 1171866

Мда, другого логического объяснения пока не вижу.

Спасибо.

...

Рейтинг:

0 / 0

25.11.2021, 07:58

| Ответить | Цитировать | Написать

13 сообщений из 13, страница 1 из 1

Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / DeadLock

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=46&fpage=9&tid=1684076]:	0ms
get settings:	8ms
get forum list:	12ms
check forum access:	4ms
check topic access:	4ms
track hit:	29ms
get topic data:	8ms
get forum data:	1ms
get page messages:	46ms
get tp. blocked users:	1ms
others:	247ms

total:	360ms