Проблема взаимоблокировки с SQL Server 2008 и ADO.NET

В наших приложениях мы не используем ни транзакции ADO.NET, ни транзакции SQL Server в процедурах, и теперь мы получаем ошибку ниже на нашем веб-сайте, когда несколько человек используют.

Транзакция (идентификатор процесса 73) зашла в тупик при блокировке | ресурсы буфера обмена данными с другим процессом и был выбран в качестве жертвы тупика. Повторите транзакцию

Это ошибка из-за отсутствия транзакций? Я думал, что согласованность будет обрабатываться самой БД.

И еще я заметил, что для свойства SQLCommand.Timeout установлено значение 10000. Будет ли это проблемой для ошибки?

Я пытаюсь решить эту проблему как можно скорее. Пожалуйста помоги.

ИЗМЕНИТЬ

Я видел свойство Isolationlevel транзакции ADO.NET, поэтому, если я использую транзакцию ADO.NET с соответствующим свойством уровня изоляции, например «ReadUncommitted» во время чтения и «Serializable» во время записи?


sql-server-2008 transactions deadlock ado.net
person Antoops    schedule 08.09.2010    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Каждый оператор SQL DML (INSERT, UPDATE, DELETE) или DQL (SELECT) выполняется внутри транзакции. По умолчанию SQL Server открывает новую транзакцию (если таковая не существует) и, если оператор завершается без ошибок, автоматически фиксирует транзакцию.

Поведение IMPLICIT_TRANSACTIONS, о котором упоминает Сидхарт, в основном заставляет SQL Server несколько изменить свое поведение - оно оставляет транзакцию открытой после завершения оператора.

Чтобы получить более точную информацию в журнале ошибок SQL Server, вы можете включить флаг трассировки . Затем вы узнаете, какие соединения оказались в тупике (а не только те, которые были отключены) и какие ресурсы были задействованы. Затем вы сможете определить, какая модель поведения приводит к тупикам.

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

person Damien_The_Unbeliever    schedule 08.09.2010
comment
Я включил информацию о тупике с помощью DBCC TRACEON (1204). Теперь жду следующего тупика, чтобы подробнее проанализировать. - person Antoops; 08.09.2010

arrow_upward
0
arrow_downward

IsolationLevel - ваш лучший выбор. Уровень сериализации транзакций по умолчанию - «Сериализуемый», который является наиболее строгим, и если на этом уровне существует циклическая ссылка, вероятность тупиковой ситуации очень высока. Установите для него значение ReadCommitted во время чтения и позвольте ему быть сериализуемым во время записи.

Сервер Sql может использовать неявные транзакции, что может происходить в вашем случае. Попробуйте выключить:

SET IMPLICIT_TRANSACTIONS OFF;

Прочтите об этом здесь: http://msdn.microsoft.com/en-us/library/ms190230.aspx

person Sidharth Panwar    schedule 08.09.2010
comment
какие-либо комментарии к значению свойства тайм-аута 10000? - person Antoops; 08.09.2010
comment
Не думайте, что тайм-аут - это проблема. - person Sidharth Panwar; 08.09.2010