Застоя - това е затворена верига блок, в който две или повече нишки блокират взаимно, така че никой от тях не може да продължи изпълнението. Когато проследяване застоя на потока в SQL Server открива затворен блок верига, един от участниците в безизходица, той избира като жертва, отменя настоящия пакет от SPID и ролки гръб сделка да позволи на друг SPID продължи. Жертвата ще получите съобщение за грешка безизходица 1205:

Транзакциите (Номер на процеса 52) се спорят за заключване на ресурси с друг процес и е избрана като жертва на безизходица. Изпълнете отново на сделката.

Застоя - специален тип блокиране скрипт, но блокиране и безизходица блокиране - не е едно и също нещо. Понякога хората говорят за застоя, но всъщност виждат блокиране.
С малки изключения, мъртвите зони се срещат като естествен по-блокиращ ефект, и не могат да се считат за грешки в SQL Server. Типичен решение за предотвратяване безизходица е кодът на настройките съхранени процедури / приложение, или на промяна на схемата / индексирането.

Прочетете информацията, получена при -T1222 на знамето. Тази информация ще присъства в дневника грешка SQL Server, след като това се случи безизходица.
Тя изглежда по следния начин:

"Breakdown" е получила информация, за да разберем по-добре сценария за блокиране.
Информация за застоя е представена от секции на "процес-списък" (списък на процеси) и "ресурс-списък" (списък на ресурси). "Процес" - един SPID или работен процес, който е участвал в задънена улица. Всеки процес се определя идентификатор, като този "processdceda8". Ресурс - ресурс, който не е на разположение (обикновено блокирани) и освобождаването на който се чака за един от участниците. Обичам да използвам формата, показан по-долу, за да се събира информация за застоя. Ако искате, можете да пропуснете тази стъпка, но никога не го правя; това ми помага да се разбере ситуацията по-ясно безизходица. Аз оцветена в жълто данните в резултатния набор, използващи 1222, така че можете да се възстанови следната картина.

Изпълняват заявки, които участват в задънена улица, посредством базата данни Tuning Advisor. Поставете текста на запитването в прозорец заявка Management Studio, изберете базата данни в контекста на искането трябва да бъде направено, щракнете с десния бутон върху текста на заявката и изберете "Анализ на заявката в DTA". Да не пропуснете тази стъпка; повече от половината от проблемите, довели до застой, решен просто чрез добавяне на индексите на съответните пазари на една от заявките, по-бързо и по-малко блок ресурс. Ако DTA препоръчва да се изгради индекси, създаване на тях, и да видим дали застоят продължава.

Уверете се, че вашите сделки възможно най-кратък срок от бизнеса - правила. Избягвайте имплицитно сделка, тъй като моделът за управление на операциите по създава ненужно дълги сделки.

Ще мога ли да изисква и други функции, за да се подобри ефективността на запитвания. замесен в застой, или чрез заявка за промяна или чрез индексация. Искането, че минималният брой на блокове от ресурси са по-малко вероятно да доведе до задънена улица. Ако планът за заявка е налице една маса сканиране, индекс сканиране, обемен хеширане или сортиране на големи обеми от данни, е необходимо да се направи подобрения в производителността.

Ако единият или двата SPID изпълняват множество изявление сделка. шансовете са, ще трябва да се създаде линия профайлър да получите информация за застоя, и за определяне на пълния набор от въпроси, които предизвикват появата на безизходица. За съжаление, -T1204 и -T1222 покаже само две искания, които са "запушени цикъл", но това е възможно, че един от най-ключалките е наложена по-ранни заявки, направени в рамките на една и съща сделка.

По-долу са някои общи насоки, които са приложими към всяка безизходица. Ако проблемът продължава, след изпълнението на тези препоръки, ще трябва да се потопите в проблема малко по-дълбоко и да намерим решение с потребителски скрипт. Ето списък на типичните методи, от които можете да изберете най-подходящия метод за справяне с мъртвите зони:

Достъпът до обектите работят в същия ред. Да разгледаме следните два пакета.

1. Започнете транзакция

4. Ангажиране на транзакция

Тези две опаковки, с висока степен на вероятност, може да доведе до застой. Ако и двете ще се извършва стъпка 3, всяка от които може да бъде блокиран от друг, тъй като и двете се отнасят до ресурс, че друга връзка блокиран в стъпка 2.

Ако и двамата членове на безизходица, използващи един и същ индекс, трябва да създадете индекс, който може да осигури допълнителен път за един от най-SPID. Например, добавянето на покритие струпани индекс SELECT, участващи в задънена улица, е възможно да се предотврати проблем (с уговорката, че нито един от ключовете на индекса на покритие не се променя от друг участник заключване щанд).

От друга страна, ако SPID станат страни блокиране поради заключване дължат на факта, че алтернативният път (индекси) са били използвани за достъп до необходимата линия на данни или страница, имайте предвид отстраняването на един от индексите, или използването на картончета за двете искания се използват съвместно един път. Бъдете внимателни, в резултат на този подход може да бъде слабо представяне.

Мъртвите зони, специален вид блок, където две SPID блок помежду си. Понякога най-добрият начин да се предотврати застой е принуден запушване на по-ранен етап в един от сделката. Например, ако блокира предварително SPID А в сделка с нощувка и SPID, а след това от началото на SPID на сделката и не можете да получите ресурси, за да се сложи край на локаута, наложени SPID Б. Това означава ли, че вие ​​умишлено наредили блокиране? Да, защото средствата са заключени, ситуацията няма да възникне застой, и в този смисъл, просто блокиране - по-добро решение безизходица блокиране. Също така е възможно да се продължи с блокиращото средство и подканва HOLDLOCK UPDLOCK да завърши SPID сделка В.

Ако е необходимо, което би като жертва в резолюцията на процеса на заключване безизходица е избран с по-висок приоритет за обработка в по-ниска настройка приоритет може да използва SET DEADLOCK_PRIORITY ниска. SPID, която използва тази настройка винаги се избира като жертвата в случай на безизходица, до която той ще стане.

Избягвайте използването на скупчени табели на стълбове, които често се променя. Промени компоненти ключови колони индекс клъстер ще наложат на катинар в индекса на клъстер (да се движат по линията) и да причини блокиране на всички не-клъстерирани индекс (защото линията на покривалото на не-клъстерирани индекс на референтната стойност на ключа за индекс на клъстера).

В някои случаи, може да е полезно да се използва NOLOCK намек, ако една от заявките е SELECT изявлението. Въпреки, че по този начин е най-атрактивните, защото Той е бърз и лесно решение в много ситуации безизходица блокове, използвайте този подход с повишено внимание, тъй като тя носи проблеми на нивото на изолация сделка прочетете необвързан (заявка може да се върне в противоречие изглед на данните). Ако не сте запознати с проблемите на използването на този ниво на изолация, обърнете се към "SET СДЕЛКИ Ниво на изолация" в SQL книги онлайн на или се консултирайте с компетентни специалисти, преди да използвате тази опция.