Artyom EРеализовать перехватывание ошибки взаимоблоировки и повторный запуск транзакции - достаточно проблематично и трудоемко.Всего лишь ещё раз выполнять, разве сложно?

Хотя, конечно, может, и бывло бы востребовано.

Предложите.

Точнее, проголосуйте, это уже предложили (кстати, ни одного голоса "за").
https://feedback.azure.com/forums/908035-sql-server/suggestions/32889979-implement-automatically-retrying-deadlock-victims
Статус UNPLANNED, но написали. что подумают. Может, если создать новое предложение, и продвигать, то будет результат?

Гавриленко Сергей АлексеевичДавайте все-таки включим мозг. На минуту, буквально.

Вот, допустим, задедлочилась транзакция





После, по вашей логике, какую именно транзакцию надо реранить? Варианты реранить ту:
у которой состояние таблицы b было на начало транзакции и текущая дата была на начало транзакции

у которой состояние таблицы b было на начало транзакции и дата на момент рерана

у которой состояние таблицы b было текущее и текущая дата была на начало транзакции

у которой состояние таблицы b было текущее и дата на момент рерана

Т.е. уже целых 4 варианта как надо реранить запрос в пол строчки. Но, внезапно, тут еще надо учитывать состояние таблицы [a], ибо всякие констрейнты. Уже получается 8 вариантов. И как задавать параметры для этого запроса? А как для скрипта в 20к строк?
Мне просто интересно, стандартная рекомендация MS по борьбе с делдлоком "перезапустить транзакцию" что подразумевает, какой из этих 8-ми вариантов?

Разумеется, если на указанном стейтменте возникла ошибка, нужно перезапустить этот стейтмент. Да, данные на момент повторного запуска (потенциально) изменились, и что, это ненормально, это противоречит каким то принципам РСУБД?
Для "скрипта в 20к строк" совершенно то же самое, не вижу разницы по сравнению со скриптом в один INSERT.
С теми же параметрами, которые передавались в первый раз. Что тоже никак не противоречит ни академическим теориям СУБД, ни здравому смыслу.

Т.е. мы делаем некое атомарное изменение БД, он оне удплось, мы его пробуем повторить, точно так же, как в первый раз, теми же DML с теми же параметрами.

Тут очевидные препятствия другие - клиент тоже участвует в транзакции.
Например, передаёт данные - не все же клиенты только выполняют запросы, есть же ещё и клиентские курсоры.

И если клиент не знает про перезапуск, то это будет непросто сделать. Вообще непонятно, есть ли теоретическая возможность реализовать такую функциональность в MSSQL.

Именно в этом проблема, а не в "какую транзакцию ..." или "это уже будет другая транзакция".

[b]Artyom E , Но есть решение, про которое уже сказали (сразу же)
Сделать это на клиенте.

В нормальном проекте доступ к СУБД не размазан тонким слоем по всему коду, а сделан в одной точке.
При условии, что управление транзакциями тоже не размазано по всему коду, а сосредоточено в пределах этого метода доступа (то есть один вызов - это атомарное изменение БД), функциональность автоматического перезапуска добавляется в проект очень быстро, нужно просто написать несколько строк в одном месте проекта.

Гавриленко Сергей АлексеевичalexeyvgДля "скрипта в 20к строк" совершенно то же самое, не вижу разницы по сравнению со скриптом в один INSERT.Кроме стандартной отписки MS, я рассматривал еще и другие варианты реализации рерана. И вот для гипотетических вариантов разница есть.Мы же обсудждаем типовой вопрос по реакции на ошибку "дедлок". Зачем так усложнять, как будто тут дискуссия искушённых читателей исходников Database Engine& :-)

Гавриленко Сергей АлексеевичalexeyvgТут очевидные препятствия другие - клиент тоже участвует в транзакции. Почему только клиент? Участвует любой код в стеке вызова, который вычисляет и передает какое-то состояние в транзакцию. И реранить надо с точки, одному вызывающему известной. А не только с того момента, где begin tran написано.Да, если приложение открывает транзакцию, потом что то делает-делает, выполняет запросы, передавая, например, ИД, которые были получены в предыдущих запросах, то з-аново это уже не повторить.

Хорошо, тогда можно было бы ограничиться такой опцией для случаев, когда нет транзакций из клиента, правильно?
Сиквел не может повторить поток вызовов от клиента, но он же мог бы повторить вызовы от себя?

invmИтого, об автоповторе можно вести речь, когда транзакция верхнего уровня однобатчевая и в этом батче нету модификаций данных вне транзакции.
А это слишком частный случай.
Разве "только если однобатчевая"?
По моему, ограничение менее жёсткое - когда клиент в течении транзакции не посылает клиенту запросы (упрощённо можно сказать "когда нет транзакций из клиента").
А внутри сиквела батчей может быть сколько угодно, даже внешних, с DTC и Linked Server.

Начали транзакцию, выполняем некий код (процедуры, триггеры, в общем, множество батчей). Если возникла ошибка, транзакция откатилась, и требуется повторный запуск, снова начинаем транзакцию, выполняя тот же код. Не "до дедлочащей инструкции включительно" (как это?), а просто выполняем.

Согласен, это очень частный случай, но ИМХО большинство систем с СУБД работают именно так.

alexeyvgНачали транзакцию, выполняем некий код (процедуры, триггеры, в общем, множество батчей). Если возникла ошибка, транзакция откатилась, и требуется повторный запуск, снова начинаем транзакцию, выполняя тот же код. Не "до дедлочащей инструкции включительно" (как это?), а просто выполняем.То есть, можно примерно представить, что сервер код:

автоматически преобразует в такой:

invmalexeyvgРазве "только если однобатчевая"?Если транзакция из нескольких батчей и дедлок не в первом, то выполнить повторно невозможно, т.к. от предыдущих ничего не осталось, кроме предварительных планов, да и тех может не быть.
Следовательно, нужно сохранять все выполняемое вместе с контекстом выполнения.Не, ну конечено, нужно сохранить весь текст, все батчи, от начала транзакции, как же иначе?
invmИ даже в этом случае автоматическое повторное выполнение недопустимо, если что-то отсылалось клиенту.Да, что бы для клиента всё было прозрачно, не надо отсылать данные, пока транзакция не будет подтверждена.
ТЗ для разработчиков МС всё больше и больше :-)

invmОк, как автоматически повторно выполнить вот такое:Просто выполнить всё от BEGIN до COMMIT, в данном случае update
А что в этом неправильного?

Я вот вижу, что будет ошибка, если @rc меняется внутри транзакции. Да, это большая проблема, не-откатываемых при ролбаке изменений :-(

Т.е. если будет так:

invmalexeyvgДа, что бы для клиента всё было прозрачно, не надо отсылать данные, пока транзакция не будет подтверждена.Дело не в этом.
Если транзакция из нескольких батчей и в каком-то из них данные передаются клиенту, то при повторе
- нет гаранитии, что клиенту будут переданы те же самые данные;
- нет гаранитии, что последующие батчи не зависят от переданных данных.Почему же "не в этом"?
Если мы до commit не передаём данные клиенту, то не будет никаких проблем, никаких данных, которые будут неправильными (например, ИД вставленных записей). Когда транзакция завершшится успешно, тогда клиент данные и получит.
Конечно, это всё в исходном предположении, что клиент во время транзакции не запускает новые батчи, то есть когда выполняется условие:
alexeyvgПо моему, ограничение менее жёсткое - когда клиент в течении транзакции не посылает клиенту запросы (упрощённо можно сказать "когда нет транзакций из клиента").
invmИтого, сервер не может самостоятельно принимать решение об автоматическом повторе транзакции при дедлоке, за исключением тривиальных случаев.

Можно лишь попросить МС реализовать механизм повтора, но управляемый сугубо вручную, через указание соответствующих параметров при старте транзакции.
Хотя, при нынешнем уровне квалификации разработчиков, я не уверен, что от такого механизма будет больше пользы, чем вреда.Понятно, что это не режим "по умолчанию", но, повторю, большинство реальных систем и работают "тривиально".

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

Плюс, как я говорил, соблюдая определённые правила (да, они, похоже, достаточно строгию...), такой режим можно использровать и для более сложных транзакций, что разработчики могут применять в проектах, упрощая свой код.

invmalexeyvgКонечно, это всё в исходном предположении, что клиент во время транзакции не запускает новые батчи, то есть когда выполняется условие:Я-то как раз о транзакциях из нескольких батчей.Я понял, но я же уточнял, что "несколько батчей", и "несколько батчей с клиента в текущей транзакции" - это сильно разные вещи.
Во втором случае, конечно, никаких вариантов.
Но повторю - по моему мнению, реально работающие в бизнесе системы редко используют этот второй вариант.

invmalexeyvgЕсли мы до commit не передаём данные клиенту, то не будет никаких проблемТранзакция возвращает клиенту 100500 миллионов строк. Копить их на сервере?Да, или не использовать такую фичу, раз она сильнее нагружает сервер.

Я ещё раз поясню свою мысль: хочется не волшебной кнопки, которая сделает ошибку 1205 невозможной в MSSQL в принципе (это действительно невозможно).
Хочется некую фичу, которая для определённой (и широко распространённой) архитектуре системы, сможет заменить обработку 1205 в приложении.