Рассматриваемый экземпляр Sql Server 2008 R2 является производственным сервером OLTP с большой нагрузкой. Проблема с тупиком возникла несколько дней назад и до сих пор не решена. Мы получили отчет о взаимоблокировке Xml, в котором перечислены хранимые процедуры, участвующие в тупиковой ситуации, и некоторые другие детали. Сначала я попытаюсь перечислить факты из этого xml:
В тупик вовлечены две хранимые процедуры, скажем, SP1 и SP2. в "Сериализуемый" внутри SP или в Код? - Нет.
Любой другой ИП, у которого IsolationLevel "Serializable" вызывает SP1? - Нет.
Вызывается ли таблица, используемая SP1,
любой другой SP, имеющий Isolation
Уровень как "Сериализуемый"? - Да.
Есть SP, у которых есть изоляция
Уровень установлен на "Сериализуемый" и
доступ к тем же таблицам, что и SP1,
но мы не знаем, были ли они
работали во время
тупик или нет как тупик
в отчете показаны только SP1 и SP2.
Направления мысли:
Мы рассмотрели следующие возможные причины:
Тупиковая ситуация возникает из-за того, что SP1 работает как "Сериализуемый". - Почему этот SP работает в Serializable, когда Я не установил? Изоляция повышение уровня (как это делают блокировки)? Если мы выясним это и заставим его работать как ReadCommitted, проблема будет в решено?
Выполняется любой другой SP, блокируя таблица, используемая SP1, и вызывает взаимоблокировка между SP1 и SP2. - Разве этот SP не был бы указан в отчет о тупике? Может ли тупик отчет пропустил такую зависимость? Если да тогда мы могли бы получить только частичное Информация. Это все еще не решить, как работает SP1 Однако с возможностью сериализации.
Предложения:
Если этой информации недостаточно в решении проблемы, как я могу получить дополнительную информацию из SQL Сервер для моей цели и какой информацию, которую я должен попытаться собрать?
Любые другие мысли, которые вы бы хотели продолжить решение этой проблемы?
Обновление:
Это информация журнала трассировки для тупиковой ситуации. Я изменил имена поставщиков услуг и т. Д., Но проверил и убедился, что изменения не упускают никакой соответствующей информации. Проверьте примечания, следующие за кодом, для получения дополнительной информации о таблицах и т. Д.
?<EVENT_INSTANCE>
<EventType>DEADLOCK_GRAPH</EventType>
<PostTime>2010-09-07T11:27:47.870</PostTime>
<SPID>16</SPID>
<TextData>
<deadlock-list>
<deadlock victim="process5827708">
<process-list>
<process id="process5827708" taskpriority="0" logused="0" waitresource="KEY: 7:72057594228441088 (8d008a861f4f)"
waittime="5190" ownerId="1661518243" transactionname="SELECT" lasttranstarted="2010-09-07T11:27:42.657"
XDES="0x80bf3b50" lockMode="RangeS-S" schedulerid="4" kpid="2228" status="suspended" spid="76" sbid="0"
ecid="0" priority="0" trancount="0" lastbatchstarted="2010-09-07T11:27:42.657"
lastbatchcompleted="2010-09-07T11:27:42.657" clientapp=".Net SqlClient Data Provider"
hostname="xxx" hostpid="5988" loginname="xxx" isolationlevel="serializable (4)"
xactid="1661518243" currentdb="7" lockTimeout="4294967295" clientoption1="673185824" clientoption2="128056">
<executionStack>
<frame procname="SP1" line="12" stmtstart="450" stmtend="6536"
sqlhandle="0x0300070090cbdc7742720c00e99d00000100000000000000">
Select ... from Table1, Table2, Table4, Table5
</frame>
</executionStack>
<inputbuf>
Proc [Database Id = 7 Object Id = 2010958736]
</inputbuf>
</process>
<process id="process5844bc8" taskpriority="0" logused="1873648" waitresource="KEY: 7:72057594228441088 (0e00ce038ed0)"
waittime="4514" ownerId="1661509575" transactionname="user_transaction" lasttranstarted="2010-09-07T11:27:40.423"
XDES="0x37979ae90" lockMode="X" schedulerid="7" kpid="3260" status="suspended" spid="104" sbid="0" ecid="0"
priority="0" trancount="2" lastbatchstarted="2010-09-07T11:27:43.350" lastbatchcompleted="2010-09-07T11:27:43.350"
clientapp=".Net SqlClient Data Provider" hostname="xxx" hostpid="5988" loginname="xxx"
isolationlevel="read committed (2)" xactid="1661509575" currentdb="7" lockTimeout="4294967295"
clientoption1="673185824" clientoption2="128056">
<executionStack>
<frame procname="SP2" line="68" stmtstart="5272" stmtend="5598"
sqlhandle="0x030007003432350f109a0c00e99d00000100000000000000">
UPDATE Table1 ...
</frame>
</executionStack>
<inputbuf>
Proc [Database Id = 7 Object Id = 255144500]
</inputbuf>
</process>
</process-list>
<resource-list>
<keylock hobtid="72057594228441088" dbid="7" objectname="Table1" indexname="Index1"
id="lock448e2c580" mode="X" associatedObjectId="72057594228441088">
<owner-list>
<owner id="process5844bc8" mode="X" />
</owner-list>
<waiter-list>
<waiter id="process5827708" mode="RangeS-S" requestType="wait" />
</waiter-list>
</keylock>
<keylock hobtid="72057594228441088" dbid="7" objectname="Table1" indexname="Index1"
id="lock2ba335880" mode="RangeS-S" associatedObjectId="72057594228441088">
<owner-list>
<owner id="process5827708" mode="RangeS-S" />
</owner-list>
<waiter-list>
<waiter id="process5844bc8" mode="X" requestType="wait" />
</waiter-list>
</keylock>
</resource-list>
</deadlock>
</deadlock-list>
</TextData>
<TransactionID />
<LoginName>xx</LoginName>
<StartTime>2010-09-07T11:27:47.867</StartTime>
<ServerName>xxx</ServerName>
<LoginSid>xxx</LoginSid>
<EventSequence>116538375</EventSequence>
<IsSystem>1</IsSystem>
<SessionLoginName />
</EVENT_INSTANCE>
SP1 выполняет выборку, которая берет данные из 5 различных таблиц (от Table1 до Table5) (использует внутренний запрос и т. Д.) SP2 выполняет обновление таблицы1.
Интересно то, что один из столбцов, которые обновляет SP2, является полем внешнего ключа в Table1 и первичным ключом Table2, в то время как Table1 и Table2 являются частью оператора select SP1, не уверен, что это актуально, но не хотел пропустить
ПРИМЕЧАНИЕ: indexname = "Index1" (на графике взаимоблокировок выше) - Index1 находится в том же столбце, что и внешний ключ в Table1, и первичный ключ Table2.