Результаты поиска

Мы видим некоторые пагубные, но редкие условия взаимоблокировки в базе данных Stack Overflow SQL Server 2005.

Я прикрепил профилировщик, настроил профиль trace, используя эту превосходную статью об устранении тупиков, и захватил кучу примеров. Самое странное, что тупиковая запись всегда одна и та же :

UPDATE [dbo].[Posts]
SET [AnswerCount] = @p1, [LastActivityDate] = @p2, [LastActivityUserId] = @p3
WHERE [Id] = @p0

Другой оператор deadlocking варьируется, но обычно это какое-то тривиальное, простое чтение таблицы posts. Этот всегда погибает в тупике. Вот вам пример

SELECT
[t0].[Id], [t0].[PostTypeId], [t0].[Score], [t0].[Views], [t0].[AnswerCount], 
[t0].[AcceptedAnswerId], [t0].[IsLocked], [t0].[IsLockedEdit], [t0].[ParentId], 
[t0].[CurrentRevisionId], [t0].[FirstRevisionId], [t0].[LockedReason],
[t0].[LastActivityDate], [t0].[LastActivityUserId]
FROM [dbo].[Posts] AS [t0]
WHERE [t0].[ParentId] = @p0

Чтобы быть совершенно ясным, мы не видим тупиков записи / записи, но читаем / пишем.

На данный момент мы имеем смесь LINQ и параметризованных SQL запросов. Мы добавили with (nolock) ко всем SQL запросам. Возможно, это и помогло некоторым. У нас также был один (очень) плохо написанный запрос значка, который я исправил вчера, который занимал более 20 секунд, чтобы выполнить каждый раз, и выполнялся каждую минуту. Я надеялся, что это было источником некоторых проблем с замком!

К сожалению, я получил еще одну тупиковую ошибку около 2 часов назад. Те же самые точные симптомы, тот же самый точный виновник пишут.

По-настоящему странно то, что оператор блокировки write SQL, который вы видите выше, является частью очень специфического пути кода. Он выполняется только тогда, когда к вопросу добавляется новый ответ-он обновляет родительский вопрос с новым количеством ответов и last date/user. это, очевидно, не так часто по сравнению с огромным количеством считываний, которые мы делаем! Насколько я могу судить, мы не делаем огромное количество записей в любом месте приложения.

Я понимаю, что NOLOCK-это своего рода гигантский молоток, но большинство запросов, которые мы здесь выполняем, не должны быть такими точными. Будет ли вам небезразлично, если ваш профиль пользователя устарел на несколько секунд?

Использование NOLOCK с Linq немного сложнее, как это обсуждает здесь Скотт Ханселман .

Мы заигрываем с идеей использования

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

на базовом контексте базы данных, так что все наши запросы LINQ имеют этот набор. Без этого нам пришлось бы оборачивать каждый вызов LINQ, который мы делаем (ну, простые считывающие вызовы, которые являются подавляющим большинством из них), в блок кода транзакции строки 3-4, что некрасиво.

Я думаю, что немного разочарован тем, что тривиальные чтения в SQL 2005 могут затормозить на записи. Я мог бы видеть, что писать / писать тупики-это огромная проблема, но читает? У нас здесь нет банковского сайта, нам не нужна идеальная точность каждый раз.

Идеи? Мысли?

Вы создаете новый объект LINQ - SQL DataContext для каждой операции или, возможно, используете один и тот же статический контекст для всех своих вызовов?

Джереми, мы по большей части делимся одним статическим datacontext в базовом контроллере:

private DBContext _db;
/// <summary>
/// Gets the DataContext to be used by a Request's controllers.
/// </summary>
public DBContext DB
{
    get
    {
        if (_db == null)
        {
            _db = new DBContext() { SessionName = GetType().Name };
            //_db.ExecuteCommand("SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED");
        }
        return _db;
    }
}

Вы рекомендуете нам создать новый контекст для каждого контроллера, или для каждой страницы, или .. а чаще всего?

Недавно Джефф опубликовал сообщение о своей проблеме с блокировками базы данных, связанными с чтением. Мультиверсионное управление параллелизмом (MVCC) претендует на решение этой проблемы. Что это такое и какие базы данных его поддерживают?

обновлено: эти поддерживают его (какие другие?)

• oracle
• postgresql