Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Deadlock Victim  [new]
Farhod
Member

Откуда:
Сообщений: 46
Владислав Колосов,

Да.
22 сен 15, 11:48    [18179518]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock Victim  [new]
как вариант
Guest
Farhod,

в апдейте таблок поставить
22 сен 15, 12:17    [18179713]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock Victim  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8807
Вот подзапрос и дает Вашу блокировку.
22 сен 15, 13:24    [18180126]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock Victim  [new]
invm
Member

Откуда: Москва
Сообщений: 9827
Владислав Колосов
Вот подзапрос и дает Вашу блокировку.
А не объясните как подзапрос в update влияет на IX блокировку?
22 сен 15, 13:42    [18180241]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock Victim  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8807
invm,

если я правильно толкую граф, то нижний процесс, создавший IX блокировку также пытается получить S блокировку, что может быть вызвано подзапросом, например.
22 сен 15, 15:09    [18180826]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock Victim  [new]
invm
Member

Откуда: Москва
Сообщений: 9827
Владислав Колосов,

Неверно толкуете.

В графе справа - писатель, слева - читатель.
Писатель имеет IX на страницу A и хочет IX на страницу B. Читатель имеет S на страницу B и хочет S на страницу A.
Такое произошло из-за разного порядка просмотра страниц.

Так что подзапросы в update тут ни при чем.
22 сен 15, 15:35    [18181012]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock Victim  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8807
Вероятно, в этом случае, поможет индексирование для запросов, т.к. оно упорядочит просмотр страниц и уменьшит вероятность пересечения доступа. Может быть, будет достаточно кластерного индекса.
22 сен 15, 15:52    [18181098]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock Victim  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4893
alexeyvg
a_voronin
Вам нужно
1) Выгрузить данные в другую БД (в идеале создать хранилище данных)
2) Пускать отчёт там
По моему, для решения проблем дедлока в 30 секундном отчёте это избыточное решение.

Можно просто сделать nolock, если это позволяет бизнес-логика, либо, если не позволяет, наоборот, залочить все таблицы в критической секции перед выборками. Ну или более интеллектуально разобраться, с выстраиванием порядка локов таблиц.


Одно дело, когда транзакция корректировки баланса вызывает дедлок с транзакцией покупки (OLTP дедлок), и другое дело когда транзакция покупки вызывает дедлок с подсчётом скорости продаж (DWH дедлок). Сам факт возникновения второго указывает на неправильную архитектуру, не зависимо от того какими средствами это можно победить. Можно победить, никто не спорит, но надолго ли? И это костыль, а не правильная архитектура.
22 сен 15, 17:50    [18181848]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock Victim  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31959
a_voronin
alexeyvg
пропущено...
По моему, для решения проблем дедлока в 30 секундном отчёте это избыточное решение.

Можно просто сделать nolock, если это позволяет бизнес-логика, либо, если не позволяет, наоборот, залочить все таблицы в критической секции перед выборками. Ну или более интеллектуально разобраться, с выстраиванием порядка локов таблиц.


Одно дело, когда транзакция корректировки баланса вызывает дедлок с транзакцией покупки (OLTP дедлок), и другое дело когда транзакция покупки вызывает дедлок с подсчётом скорости продаж (DWH дедлок). Сам факт возникновения второго указывает на неправильную архитектуру, не зависимо от того какими средствами это можно победить. Можно победить, никто не спорит, но надолго ли? И это костыль, а не правильная архитектура.
Непонятно, какие ваши критерии "правильности архитектуры"?

Мои критерии - когда архитектор выбирает архитектуру, исходя из стоимости решения бизнес-задач. Если дешевле, например, делать повтор запроса при дедлоке (самый распространённый способ решения; кстати, постоянно упоминается у MS), то это и должно быть правильной архитектурой, а не выделение аналитического сервера.
Ну и множество других способов есть, которые вы тоже почему то называете "неправильной архитектурой".
22 сен 15, 20:21    [18182344]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock Victim  [new]
o-o
Guest
alexeyvg
например, делать повтор запроса при дедлоке (самый распространённый способ решения; кстати, постоянно упоминается у MS

может, оно и хорошо в большинстве случаев,
но вот именно случай ТС напоминает те самые отчеты поверх работавшего CRM.
смысл был в том, что жертвой выбирался именно отчет.
a его перезапуск приводил к новому дедлоку.
и не сразу дедлок вываливался,
а после 10-15 минут ожидания,
таблицы здоровые были.
в результате взвыли все: у отчетников просто никаких данных,
а операторы начали жаловаться на тормоза.
перепланировали отчеты на ночь и все успокоились
22 сен 15, 21:04    [18182485]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock Victim  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31959
o-o
может, оно и хорошо в большинстве случаев,
Конечно, в данном случае, для отчёта, неэффективно перезапускать запрос - 10 минут, это не олтп-транзакция на 10 мс

Я писал о других вариантах - 18177432 - например, поставить nolock, или наоборот залочить все таблицы с tablockx на каком то проблемном запросе

Если отчёт требуется раз в день, раз в неделю, то это ИМХО для бизнеса лучшее решение, чем ставить отдельно аналитический сервер, налаживать переносы данных и т.д. Дешевле в создании и при поддержке.
22 сен 15, 23:28    [18182798]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock Victim  [new]
o-o
Guest
alexeyvg,

ну и я тоже про nolock (см. где-то там выше),
только не всегда это возможно.
если генерилка отчетов не позволяет править вручную сгенеренное,
то вариантов еще меньше
22 сен 15, 23:36    [18182808]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock Victim  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
Владислав Колосов, процессы в графе рисуются овалом. А нижний и верхний - прямоугольники, являющиеся ресурсами
23 сен 15, 00:12    [18182859]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock Victim  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
А структуру таблицы и запросы привидете?
23 сен 15, 00:14    [18182862]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock Victim  [new]
Farhod
Member

Откуда:
Сообщений: 46
Mike_za,

Могу только еxtract с профайлера.

К сообщению приложен файл (traceevent_03.xdl - 11Kb) cкачать
23 сен 15, 07:08    [18183101]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock Victim  [new]
Farhod
Member

Откуда:
Сообщений: 46
Выдает ошибку 2 индекса.
1-го удалил, ошибки уменьшились.
2-й сидит в primary kay как clustered.
23 сен 15, 13:44    [18185021]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock Victim  [new]
invm
Member

Откуда: Москва
Сообщений: 9827
Farhod
1-го удалил, ошибки уменьшились.
Т.е. вам все равно использовался ли этот индекс где-то еще или нет?

Самый просто выход для вас:
1. Вернуть удаленные индексы.
2. Включить у БД RCSI.
23 сен 15, 14:07    [18185204]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock Victim  [new]
ититьколотить архитектор
Guest
Farhod
Выдает ошибку 2 индекса.
1-го удалил, ошибки уменьшились.
2-й сидит в primary kay как clustered.

дустом его!
23 сен 15, 15:15    [18185624]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock Victim  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4893
alexeyvg
Непонятно, какие ваши критерии "правильности архитектуры"?


Правильная архитектура такая -- атомарные транзакции в OLTP базе. Аналитические в DWH.
23 сен 15, 15:58    [18185805]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock Victim  [new]
o-o
Guest
a_voronin
атомарные транзакции в OLTP базе. Аналитические в DWH.

какие-какие у нас транзакции еще бывают, кроме атомарных?
23 сен 15, 16:11    [18185889]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock Victim  [new]
invm
Member

Откуда: Москва
Сообщений: 9827
a_voronin
Правильная архитектура такая -- атомарные транзакции в OLTP базе. Аналитические в DWH.
Правильная архитектура та, которая позволит решить поставленные задачи с минимальными затратами, в том числе и финансовыми. На вам, похоже, на этот аспект плевать.
23 сен 15, 17:15    [18186208]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock Victim  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4893
invm
a_voronin
Правильная архитектура такая -- атомарные транзакции в OLTP базе. Аналитические в DWH.
Правильная архитектура та, которая позволит решить поставленные задачи с минимальными затратами, в том числе и финансовыми. На вам, похоже, на этот аспект плевать.


Картинка с другого сайта.
23 сен 15, 18:14    [18186558]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock Victim  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8807
Так и не понятно, почему автор не может сделать uncommitted чтение для отчета.
23 сен 15, 18:22    [18186612]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock Victim  [new]
o-o
Guest
Зато понятно, на какой аспект не плевать воронину
23 сен 15, 18:26    [18186642]     Ответить | Цитировать Сообщить модератору
 Re: Deadlock Victim  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8807
o-o,

ну, видимо, такой вот архитектор.
23 сен 15, 18:28    [18186650]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить