sql блокировка и тайм-аут почти постоянно
Похоже, сегодня будет еще один мусор. Недавно мы обновили наш sql box с полным монстром, с множеством ядер и оперативной памяти, однако мы застряли с нашей старой схемой БД, которая является crapola.
У нашей старой коробки sql были проблемы, но она не имела ничего общего с тем, что мы испытываем с новой, хотя в день выпуска она работала очень быстро, через неделю это полный беспорядок...
Наше приложение.net, которым пользуются несколько сотен человек или около того, генерирует огромное количество взаимоблокировок и тайм-аутов на блоке SQL, и мы пытаемся выяснить, почему. Мы проверили все индексы, и они сейчас настолько хороши, насколько это возможно. Некоторые из основных таблиц слишком широки и содержат большое количество триггеров, но сейчас мы ничего не можем с этим поделать.
Многие пиды кажутся одинаковыми для одних и тех же пользователей, которые пробуют несколько раз.
Так, например...
User: user1
Time: 09:21
Error Message: Transaction (Process ID 76) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
User: user1
Time: 09:22
Error Message: Transaction (Process ID 76) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
так далее....
Когда мы перенесли БД в новую коробку, она была скопирована из старой и восстановлена в новой.
Если у кого-то есть какие-либо предложения относительно того, что мы можем сделать, я куплю им несколько пинт.
4 ответа
Это действительно больше проблема развития. Вы можете проконсультироваться со своими разработчиками, чтобы определить, какой уровень изоляции транзакций используется.
Уровень изоляции по умолчанию для Microsoft SQL Server - "Передано на чтение". Разработчик должен знать и установить соответствующий уровень для транзакции. Как правило, рекомендуется использовать минимально возможный уровень изоляции и избегать использования уровней изоляции Repeatable Read и Serializable, если это возможно.
Если они используют более строгий уровень изоляции, чем по умолчанию, такой как Repeatable Read или Serializable, тогда приложение будет более предрасположено к проблемам с блокировкой. Если они используют более строгий уровень изоляции, чем по умолчанию, и не знают, что делают, это еще хуже.
Основная технология доступа к данным Microsoft, Entity Framework, использует уровень изоляции Serializable по умолчанию. Это не очень хорошо задокументировано или раскрыто. Если приложение использует Entity Framework, и разработчик не знает об этом факте, разработчик может захотеть проверить структуру базы данных, чтобы определить, могут ли они установить уровень изоляции транзакции на Read Committed.
Дополнительная информация:
УСТАНОВИТЬ УРОВЕНЬ ИЗОЛЯЦИИ ТРАНЗАКЦИЙ (Transact-SQL)
http://msdn.microsoft.com/en-us/library/ms173763.aspx
Транзакции и соединения в Entity Framework 4.0
http://blogs.u2u.be/diederik/post/2010/06/29/Transactions-and-Connections-in-Entity-Framework-40.aspx
Я не увлекаюсь пивом, но вы должны серьезно взглянуть на профилировщик SQL Server - это ценный инструмент для анализа вашей рабочей нагрузки, включая некоторые инструменты, помогающие выяснить причины возникновения тупиковых ситуаций.
На эту тему написано множество статей, и эта достаточно обширна. Официальная документация на MSDN также содержит некоторую информацию, хотя и не так хорошо написана.
Если у вас есть правильные индексы, нет хорошего способа решить эту проблему, не исправляя схему базы данных и / или запросы: в частности, тестирование с SNAPSHOT ISOLATION и READ COMMITTED SNAPSHOT. Это не быстрые исправления.
Если вы не возражаете превратить нового зверя в медленного, вы можете отключить параллелизм. Неясно, насколько это поможет.
В конечном счете частые взаимоблокировки являются результатом неадекватного проектирования базы данных, и нет никакого способа обойти это.
Вы хотя бы смогли записать запросы, вызывающие проблемы? По моему опыту было очень мало запросов, отвечающих за подавляющее большинство вопросов.
Из сообщений об ошибках похоже, что вы используете SQL Server. Если вы работаете в 2005 году или лучше, включите Trace Flag 1222 DBCC TRACEON (1222, -1) он должен дать вам некоторую информацию о запросах. Дрянная схема может вызвать проблемы, но я никогда не видел, чтобы дрянная схема напрямую вызывала взаимоблокировки. Обычно есть обходной путь. Медленный запрос намного лучше, чем запрос, вызывающий постоянные тупики.
Получить некоторые из запросов, которые мешают вытащить, и мы могли бы предложить некоторые изменения в них.