Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Опять дедлоки  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Интересное кино!
Добавление WITH (UPDLOCK) к множественным UPDATE в транзакции вроде бы как уменьшеат дедлоки. Но! Если есть старые аналогичные обращения к этим же таблицам то для них эффект ровно обратный - дедлоков становится больше!
10 июл 04, 19:52    [798571]     Ответить | Цитировать Сообщить модератору
 Re: Опять дедлоки  [new]
KOLCHOZ_POSTEVENT
Guest
Кластерные индексы есть?
Инсерты,делиты в эти таблы,одновременно,с юзеров,числом больше 1 есть?
Значит,будут и дедлоки.Серверу надо пересортирить таблу,какие-бы примочки вы не ставили,последнюю страницу он запрёт,так как все волны сортировки заканчиваются в ней.
11 июл 04, 11:23    [798726]     Ответить | Цитировать Сообщить модератору
 Re: Опять дедлоки  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Нет, ну можно поставить и TABLOCK :) Тогда дедлоков не будет :) Но это не наш метод. В идеале дедлоки можно свести к ожиданиям. Правда непонятно, что будет в итоге эффективнее.
12 июл 04, 11:35    [799546]     Ответить | Цитировать Сообщить модератору
 Re: Опять дедлоки  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
У меня складывается впечатление, что если конкурирующие апдейты затрагивают несколько строк в таблице, то избежать дедлоков вообще невозможно. Ну разве что действительно таблицу целиком лочить.

Всегда можно налететь на "классический" дедлок:
Первый коннект: update каких-то строк и вычитка (редко апдейт) индексов
Второй - update других данных (частично пересекающихся с первым).
Каждый лочит свой кусок и ждет конкурирующего.

Особенный смак можно поиметь со связанными таблицами, когда будут обрабатываться индексы на них.

Короче, при некотором опыте борьбы с этим злом я до сих пор не вижу панацеи, которая бы гарантировала, что при корректном написании кода (нет откровенных дедлоков, когда в транзакции обновляются таблицы в разном порядке) не возникнет дедлоков.
12 июл 04, 11:53    [799583]     Ответить | Цитировать Сообщить модератору
 Re: Опять дедлоки  [new]
KOLCHOZ_POSTEVENT
Guest
Где лочит?Дома или в tempdb?

select object_name(id) table_name,db_name(dbid) db_name,type,spid from master.dbo.syslocks

чо кажет?
12 июл 04, 12:16    [799661]     Ответить | Цитировать Сообщить модератору
 Re: Опять дедлоки  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Дома. KOLCHOZ_POSTEVENT, вы поищите последний топик про дедлоки. Там примерчики были вполне воспроизводимые...
12 июл 04, 12:37    [799737]     Ответить | Цитировать Сообщить модератору
 Re: Опять дедлоки  [new]
KOLCHOZ_POSTEVENT
Guest
Примерчики с dead локами мне особо искать не надо, мои юзеры подбрасывают,иной раз,настолько воспроизводимые...Но если локи дома,то без кодовлезания вряд-ли это можно размотать...
12 июл 04, 12:51    [799787]     Ответить | Цитировать Сообщить модератору
 Re: Опять дедлоки  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Дома, дома дедлоки...
И после введения UPDLOCK их все больше и больше...
На днях попробую посмотреть с пристрастием - с трасером на Stmt Started
12 июл 04, 13:59    [800058]     Ответить | Цитировать Сообщить модератору
 Re: Опять дедлоки  [new]
ChA
Member

Откуда: Москва
Сообщений: 11138
Не совсем по теме, но отчасти с дидлоками можно бороться путем
выстраивания модификаций таблиц в скриптах в одном и том же порядке.
Грубо говоря, определить последовательность в которой всегда(!) будут
модифицироваться таблицы, а затем при написании кода придерживаться
этой последовательности. Фактически - сериализовать модификации
вручную, шанс на дидлок могут весьма уменьшиться.
12 июл 04, 17:51    [800994]     Ответить | Цитировать Сообщить модератору
 Re: Опять дедлоки  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
2ChA: да хрена... Понимаете, в чем фишка-то - бывают ситуации, когда дедлок происходит на ОДНОЙ таблице и включает в себя локи не только строк, но и индексов. И тогда имеет значение, в каком порядке апдейтятся ЗАПИСИ В ПРЕДЕЛАХ ОДНОЙ ТАБЛИЦЫ.

Понимаете? Если апдейт нескольких таблиц я могу регулировать, создав нужные процедуры, то гарантировать апдейт записей в нужном порядке я уж точно никак не могу - это переменный параметр.
12 июл 04, 18:28    [801127]     Ответить | Цитировать Сообщить модератору
 Re: Опять дедлоки  [new]
ChA
Member

Откуда: Москва
Сообщений: 11138
GreenSunrise
2ChA: да хрена...

Я Вас чем-то обидел ?
GreenSunrise
Понимаете, в чем фишка-то

Понимаю. Напомню
ChA
Не совсем по теме, но отчасти с дидлоками можно бороться...

И ничего более...
12 июл 04, 18:43    [801169]     Ответить | Цитировать Сообщить модератору
 Re: Опять дедлоки  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Не, не :-) Ничего личного и никаких обид :-) Это всего лишь грустное созерцание все новых и новых проблем... Если бы все лечилось так легко, как правильным порядком таблиц в апдейте...
12 июл 04, 19:02    [801232]     Ответить | Цитировать Сообщить модератору
 Re: Опять дедлоки  [new]
ChA
Member

Откуда: Москва
Сообщений: 11138
Еще один способ: использование bind session, что фактически также приводит
к сериализации модификаций из разных соединений. Сам не проверял, но
написано убедительно :)
И в качестве бреда: пишем не прямо в таблицы, а посылаем операторы в некую
таблицу, затем, в определенный момент, в цикле выполняем эти операторы в
одном из соединений в одной транзакции. Тонкости такой реализации целиком
на совести усмотревшего в бреде мысль :)
12 июл 04, 19:25    [801287]     Ответить | Цитировать Сообщить модератору
 Re: Опять дедлоки  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
ChA
bind session, что фактически также приводит
к сериализации модификаций из разных соединений. Сам не проверял, но
написано убедительно :)

Нет. bind session позволяет нескольким коннектам делить одну транзакцию. Это совсем другое. Означает, что вы создадите не две (или больше) конкурирующих транзакций, а одну. Т.е. аналогично тому, что было бы в случае одного коннекта. Боюсь, что такая штука чревата еще более непредсказуемыми результатами - вы же фактически начнете видеть грязные данные другой транзакции.

Короче, имхо для данной задачи - бред.
13 июл 04, 12:05    [802351]     Ответить | Цитировать Сообщить модератору
 Re: Опять дедлоки  [new]
ChA
Member

Откуда: Москва
Сообщений: 11138
GreenSunrise
bind session позволяет нескольким коннектам делить одну транзакцию

Using Bound Connections
Bound connections can work on the same data without lock conflicts
И далее
Only one connection in a set of bound connections can be active at any time.
If one connection is executing a statement on the server or has results pending
from the server, no other connections that share the same transaction can access
the server until the current connection finishes processing or cancels the current
statement

P.S. Наше дело предложить, ваше - отказаться :)
13 июл 04, 15:58    [803476]     Ответить | Цитировать Сообщить модератору
 Re: Опять дедлоки  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Да с конфликтами понятно, почему их не будет :-) Нет разных транзакций - нет проблем.

Насчет второго - признаю свою ошибку.

В общем и целом - остаюсь при мнении, что bind session - не наш метод...
13 июл 04, 16:15    [803554]     Ответить | Цитировать Сообщить модератору
 Re: Опять дедлоки  [new]
bgt
Guest
автор
Если апдейт нескольких таблиц я могу регулировать, создав нужные процедуры, то гарантировать апдейт записей в нужном порядке я уж точно никак не могу - это переменный параметр.


Ну почему.. С помощю индексов порядок обработки записей можно сделать довольно предсказуемым и свести вероятность дедлока практически к нулю...
13 июл 04, 17:27    [803894]     Ответить | Цитировать Сообщить модератору
 Re: Опять дедлоки  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Неа. Был пример с индексами. Два инсерта в разном порядке перед апдейтом потом дедлочат или нет.
13 июл 04, 18:55    [804242]     Ответить | Цитировать Сообщить модератору
 Re: Опять дедлоки  [new]
Chaklun
Member

Откуда: Ukraine, Kiev
Сообщений: 105
ИМХО еще один (весьма эффективный метод) борьбы с дедлоком - уменьшение гранулярности операций.
Повторный апдейт на таблицу в пределах одной транзакции - всегда угроза дедлока.
Если гранулярность операций не получается уменьшить - есть "патентованный"
Чаклунский способ. Мне надо было по условию повторно писать в транзакции в одну и ту же таблицу и дедлок меня замучал. Тогда я аккумулировал строки обновления и вставки во временной таблице, создаваемой внутри ХП.
После этого стал намного спокойней спать.
13 июл 04, 19:09    [804270]     Ответить | Цитировать Сообщить модератору
 Re: Опять дедлоки  [new]
Полуэкт
Member

Откуда:
Сообщений: 381
слушайте господа программисты и пр народец :)

чисто теоретический вопрос

если есть например большая база и в ней индексов нет вообще кроме праймари ключей. дедлоки возникали раза 3 за пол года и то изза неправильно написанных процедур которые потом исправлялись.. если добавить индекса (а будет их там наверное штук 300-500) может ли теоретически увеличиться вероятность дедлоков при условии что все процы останутся теми же
13 июл 04, 19:13    [804281]     Ответить | Цитировать Сообщить модератору
 Re: Опять дедлоки  [new]
Chaklun
Member

Откуда: Ukraine, Kiev
Сообщений: 105
Вряд ли. Хотя усложнение структуры БД всегда ведет к увеличению количества артефактов
13 июл 04, 19:16    [804289]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить