Що може бути причиною цього типу тупикової ситуації? (не взагалі без тупика)
Блокуйте ресурси буфера зв'язку
Це вказана система має мало пам’яті, і кількість буферів закінчилося?
Детальна помилка:
Трансакція (ідентифікатор процесу 59) була заблокована на ресурсах буфера зв'язку блокування з іншим процесом і була обрана в якості жертви тупикового зв'язку. Перезавантажте транзакцію
Відповіді:
Повне повідомлення, яке зазвичай зустрічається:
Трансакція (ідентифікатор процесу 53) виявилася тупиковою на блокуванні | комунікаційні буферні ресурси з іншим процесом і був обраний як жертва тупикової ситуації. Перезавантажте транзакцію.
Цей тип блокування зазвичай зустрічається із запитами тупикового зв'язку, які SQL Server виконує як паралельні, іноді їх називають "паралельними тупиками внутрішнього запиту". Я бачив декілька тверджень, що це також вказує на низькі системні ресурси, які, мабуть, можуть бути залучені в незначній мірі.
Загальне керівництво, яке я помітив, щоб визначити, чи є паралельний тупик, коли ви витягнете графік тупикової ситуації XML (що можна зробити за допомогою сеансу system_health у 2008 році та вище), ви помітите різні ідентифікатори процесу, які показують один і той же біт коду в межах стек виконання.
Крім того, перегляньте список ресурсів тупикової графіки та зазначивши тип події офіціанта. Вони найчастіше показують "e_xxxxxx", або щось подібне, можливо:
<waiter-list>
<waiter event="e_waitPipeGetRow" type="consumer" id="process821d828" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process8209198" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process3827c18" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process3809eb8" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process8226b08" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process9acb6d8" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process6188d7828" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process381cef8" />
</waiter-list>Щоб спробувати вирішити проблему, пропонуються різні шляхи в Інтернеті та в книгах. Я, як правило, починаю з перегляду плану виконання запиту / процедури і зосереджуюсь на областях, які показують паралельне виконання. Потім звідти пройдіться, намагаючись спочатку налаштувати запит, а потім як остання інстанція може почати використовувати підказки запитів.
Найпоширеніший натяк на запит, який ви побачите, згаданий для вирішення цих тупиків, реалізується MAXDOP 1. Однак перед тим, як зробити це, ви можете перевірити, на що встановлено рівень MAXDOP на сервері та поріг витрат. Пороговий показник вартості за замовчуванням встановлений на 5, і я хотів би підвищити його до 35 або 40 для початку, якщо запит має низьку вартість для цього розділу коду, можливо, його взагалі не потрібно буде паралельно виконувати. Мені не все подобається використовувати підказки для запитів MAXDOP, але це не означає, що вони не мають свого місця та призначення. просто моя думка.