Заблокирован отключение

Я запускаю тупик, когда запускается SQL Server Job. Тупик встречается в простой инструкции DELETE. Я бы подумал, что должен быть запущен запрос SELECT /UPDATE, чтобы вызвать тупик? Но выглядит как тупик DELETE /DELETE ...

То, что я ищу, - это то, что я получаю тупик DELETE /DELETE. Это, насколько мне известно, проходит по различным параметрам.

Любые идеи? Спасибо.

deadlock-list
2014-05-20 07:30:09.66 spid25s      deadlock victim=process409048
2014-05-20 07:30:09.66 spid25s       process-list
2014-05-20 07:30:09.66 spid25s        process id=process409048 taskpriority=0 logused=0 waitresource=PAGE: 12:1:7127294 waittime=4352 ownerId=629860973 transactionname=DELETE lasttranstarted=2014-05-20T07:30:05.307 XDES=0x397219620 lockMode=U schedulerid=5 kpid=3792 status=suspended spid=150 sbid=0 ecid=3 priority=0 trancount=0 lastbatchstarted=2014-05-20T07:30:05.307 lastbatchcompleted=2014-05-20T07:30:05.307 clientapp=QSQL25 hostname=MORRIS hostpid=1528 isolationlevel=read committed (2) xactid=629860973 currentdb=12 lockTimeout=4294967295 clientoption1=671088672 clientoption2=128056
2014-05-20 07:30:09.66 spid25s         executionStack
2014-05-20 07:30:09.66 spid25s          frame procname=adhoc line=1 stmtstart=68 sqlhandle=0x020000000b887a18f75d0aa07c25a9b8630fca696aa0e5d2
2014-05-20 07:30:09.66 spid25s     DELETE FROM dbo.UserDetailsData WHERE        (Username = @P1) AND (UserDate = @P2)     
2014-05-20 07:30:09.66 spid25s          frame procname=unknown line=1 sqlhandle=0x000000000000000000000000000000000000000000000000
2014-05-20 07:30:09.66 spid25s     unknown     
2014-05-20 07:30:09.66 spid25s         inputbuf
2014-05-20 07:30:09.66 spid25s        process id=process432e08 taskpriority=0 logused=0 waitresource=PAGE: 12:1:7127916 waittime=2648 ownerId=629859744 transactionname=DELETE lasttranstarted=2014-05-20T07:30:04.833 XDES=0x4c3426b50 lockMode=U schedulerid=6 kpid=5988 status=suspended spid=146 sbid=0 ecid=3 priority=0 trancount=0 lastbatchstarted=2014-05-20T07:30:04.833 lastbatchcompleted=2014-05-20T07:30:04.820 clientapp=QSQL25 hostname=MORRIS hostpid=1528 isolationlevel=read committed (2) xactid=629859744 currentdb=12 lockTimeout=4294967295 clientoption1=671088672 clientoption2=128056
2014-05-20 07:30:09.66 spid25s         executionStack
2014-05-20 07:30:09.66 spid25s          frame procname=adhoc line=1 stmtstart=68 sqlhandle=0x020000000b887a18f75d0aa07c25a9b8630fca696aa0e5d2
2014-05-20 07:30:09.66 spid25s     DELETE FROM dbo.UserDetailsData WHERE        (Username = @P1) AND (UserDate = @P2)     
2014-05-20 07:30:09.66 spid25s          frame procname=unknown line=1 sqlhandle=0x000000000000000000000000000000000000000000000000
2014-05-20 07:30:09.66 spid25s     unknown     
2014-05-20 07:30:09.66 spid25s         inputbuf
2014-05-20 07:30:09.66 spid25s        process id=process39ea562c8 taskpriority=0 logused=0 waitresource=PAGE: 12:1:7127916 waittime=4352 ownerId=629860973 transactionname=DELETE lasttranstarted=2014-05-20T07:30:05.307 XDES=0x13e0e4b50 lockMode=U schedulerid=2 kpid=7124 status=suspended spid=150 sbid=0 ecid=1 priority=0 trancount=0 lastbatchstarted=2014-05-20T07:30:05.307 lastbatchcompleted=2014-05-20T07:30:05.307 clientapp=QSQL25 hostname=MORRIS hostpid=1528 isolationlevel=read committed (2) xactid=629860973 currentdb=12 lockTimeout=4294967295 clientoption1=671088672 clientoption2=128056
2014-05-20 07:30:09.66 spid25s         executionStack
2014-05-20 07:30:09.66 spid25s          frame procname=adhoc line=1 stmtstart=68 sqlhandle=0x020000000b887a18f75d0aa07c25a9b8630fca696aa0e5d2
10 голосов | спросил K09 20 Maypm14 2014, 20:29:35

1 ответ


14
  

То, что я ищу, является причиной того, что я получаю тупик DELETE /DELETE.

Появляется тупик, потому что:

  1. spid 54 ecid 0 получает обновление (U) страница lock on PAGE: 12:1:5147422
  2. spid 166 ecid 3 запрашивает обновление (U) блокировка на той же странице и заблокирована
  3. spid 54 ecid 2 запрашивает обновление (U) страница блокировка на той же странице ...

Страницы запрограммированы для запроса, с блокировками обновления, полученными с помощью ecid 0. Это шаг 1 выше. На шаге 3 дочерний поток одного и того же параллельного запроса (ecid 2) запрашивает одну и ту же блокировку. Обычно это не проблема. SQL Server знает ecid 0 и ecid 2 - это потоки одного и того же родительского процесса. К сожалению, шаг 2 мешает этому, и результат взаимоблокировки.

Тем не менее, вы не должны сильно беспокоиться о том, почему происходит тупик, важный вопрос - как вы его избегаете. Ответ заключается в том, чтобы обеспечить эффективный путь доступа для DELETE. Оператор должен найти строки WHERE Username = @P1 AND UserDate = @P2, поэтому для этих столбцов должен быть указатель.

И, конечно, у вас есть такой индекс. реальный вопрос , почему ваши проблемы возникли после добавления фильтрованных индексов.

Ответ на это - дополнительная информация о столбцах, необходимая для поиска отфильтрованных строк индекса для удаления (и для проверки их предикатов). Если запрос использует узкий /per -роу исполнение , механизм выполнения не может получить дополнительные столбцы в операторе кластеризованного индекса, как это было бы в плане с широким /индексом.

Более подробную информацию об этом можно найти и приведенный ниже пример в этом сообщении в блоге .

В этом случае информация столбца должна поступать из части плана справа от Clustered Index Delete, и поэтому используется параллельное кластерное сканирование индекса, и вы получаете медленный запрос с высоким потенциалом взаимоблокировки.

Ответ заключается в том, чтобы выполнить одно из следующих действий:

  1. Удалить отфильтрованные индексы
  2. Добавить отфильтрованные столбцы индекса /включения /предиката в существующее имя /индекс даты
  3. Использовать широкий план обновления (без поддерживаемого ).
  4. Запустить запрос при изоляции моментальных снимков (не RCSI)

Вариант 2 был бы моим сильным предпочтением.

Вариант 4 (спасибо Джеку Дугласу) имеет преимущество в устранении взаимоблокировок и не должен вызывать любые «конфликты обновлений», учитывая непересекающийся характер изменений, но для этого требуется включить изоляцию моментальных снимков при уровень базы данных, явно меняющий уровень изоляции, и не будет устранять основную проблему : вы все равно получите расточительное параллельное сканирование таблицы, где хороший поиск индекса - это то, что вы действительно хотите.

ответил Paul White 28 Mayam14 2014, 09:30:41

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132