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


Где найти -- я может не скажу, зато скажу, каков сам механизм.
Откатывается та транзакция, которая на момент дедлока захватила меньше ресурсов (т.е. блокировок).
Таким образом, более большая транзакция продолжается, а более маленькая -- откатывается.

Сергей08Как то накопились вопросы.
То что смог найти в документации звучит так: Если дедлок обнаружен- то убивается процес , на который меньше потрачено процесорного времени.
Практика вызывает подозрения что:

1. Если на прoцесс затрачено даже очень много времени то он всё равно убивается , если он сразу в двух и более цепочках.
Т.е. убив этот запрос мы развязываем две дедлок-цепочки. Если по логике с большим процессорным временем - то надо было бы убить два других процесса, которые почти не затратили процессорное время. Логично , но подтверждения в доке не нашёл.

2. Есть ситуация , когда процесс -жертва дедлока не убивается , а только проходит ролбек для текущей транзакции и запускается следующая транзакция. (потому как chained mode ). Bug?

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

Сергей08Я говорю о ситуации когда в дедлоке 3 транзакции и 2 цепочки.
Т.е. одна транзакция участвует в двух цепочках и если не ошибаюсь то использовала
больше ресурсов перед тем как быть убитой. Скажу больше , что даже иногда пару часов перед дедлоком успела поработать.

Дедлоки разбираются по одному, если их много, берётся "верхний" и разрешается, потом --- следующий.
И так далее. Так что 3 транзакции в цепочке быть может, а двух цепочек -- нет.
Всё на сколько я помню.

Ещё раз давай попробуем ответить на твои вопросы:

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

Я не очень понимаю другое: какой бы он ни был, менять его всё равно нельзя. Как-то воздействовать
на СУБД, чтобы она разрешала бы дедлоки по-другому -- нельзя. Поэтому зачем тебе это ?
Просто чтобы знать ? Тогда ищи сам, в документации найти можно, при желании.

Но, ещё раз, всё, что ты можешь сделать с дедлоками -- это уменьшить вероятность их возникновения.

>Практика вызывает подозрения что:
>1. Если на прoцесс затрачено даже очень много времени то он всё равно убивается , если он сразу в двух и более цепочках.

Поясни, что значит "в двух цепочках". Если один процец участвует "в двух цепочках" -- то это же уже ОДНА ЦЕПОЧКА, потому что у неё есть одна общая вершина. Это связный граф. Почему ты считаешь это за две цепочки ?

Я подозреваю, что ты неверно пользуешься средствами диагностики.


> 2. Есть ситуация , когда процесс -жертва дедлока не убивается , а только проходит ролбек для текущей транзакции и запускается > следующая транзакция. (потому как chained mode ). Bug?

Нет.

авторError 1205
Severity

13

Message text

Your server command (family id #%d, process id #%d) encountered a deadlock situation. Please re-run your command.

Explanation

This error occurs when a process tries to acquire a lock on an object that is locked by a second process when the second process is waiting for a lock on an object that has been locked by the first process. This situation is a deadlock, and can involve more than two processes.

Adaptive Server detects this situation, rolls back the transaction that has accumulated the least amount of CPU time, and notifies the application program of this action with error 1205. This allows other users’ processes to move forward.

Deadlocks are caused by a number of situations, including:

Transactions modify tables in different orders. There is a greater chance of deadlock between two transactions if one is processing in the sequence A–B–C while the other runs C–B–A.

Transactions access tables using a nonclustered index. If the optimizer chooses a different nonclustered index for the same table for two different queries, a nonclustered index is not in the physical data sequence and the two processes are acquiring page locks in a random order. Therefore, there is a greater chance that one process will lock a page that the other needs.

Transactions that use the keyword holdlock or use the set isolation level command to hold shared locks. When holdlock is appended to a select transaction it holds the shared lock for the remainder of the transaction. This increases the risk of deadlock.

Transactions that require a long time to run. The longer a transaction runs, the more likely it is that another user will require a resource held by the transaction.

Action

Restart the transaction that has been rolled back. To minimize future occurrences of deadlocks, use any of the following procedures that apply to your site.



Где написано, что должно разрываться соединение ?

авторСитация выглядит сложно разрешимой. 57 процесс работает 2 часа и занимает море локов и море CPU .
После двух часов работы ненадолго появлются два процесса (124 , 49) и как организовааная банда убивают 57.
Повторяется с завидной периодичностью.
Что делать? Как дать возможность процессу архивации закончить работу? Какие дать рекомендации програмерам апликухи.
Есть конструктивные предлжения?

Ну очень сложно представить, как такое может быть.
Но если такое случается -- просто уходи от дедлоков,
Настрой блокировки на уровне записей, переведи таблицы на DOL/DRL...
блокируй записи в процессах (124 , 49) в другом порядке, например, сразу в начале транзакций всё, что нужно.

Зачем для решения этой проблемы знать механизмы разрешения дедлоков -- не понятно совсем.
Ещё раз, даже если это так, и даже если возможно это баг, то ты с этим ничего не сделаешь,
лучшее, что получится -- это фикс бага через полгода-год. Тебя это устроит ? Думаю, нет.
Так что просто разрешай дедлок.

Далее:

Сергей08 57 процесс работает 2 часа и занимает море локов и море CPU .
После двух часов работы ненадолго появлются два процесса (124 , 49) и как организовааная банда убивают 57.
Что делать? Как дать возможность процессу архивации закончить работу? Какие дать рекомендации програмерам апликухи.
Есть конструктивные предлжения?


Т.е.
процесс 57 -- архивация

процесс 124 -- что-то делает (меняет)

процесс 49 -- что-то делает (меняет).

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

Смотрим в твою диагностику:

Сергей08------------------
00:0004:00000:00057:2015/12/16 09:13:28.61 server Deadlock Id 271 detected
Deadlock Id 271 detected. 2 deadlock chain(s) involved.

Deadlock Id 271: Process (Familyid 0, Spid 57 ) was waiting for a 'exclusive page' lock on page 7363207 of table 'orders' , indid 8 in database 'BEL' but process (Familyid 0, Spid 124) already held a 'shared page' lock on it.
Deadlock Id 271: Process (Familyid 0, Spid 124) was waiting for a 'shared page' lock on page 7376230 of table 'orders' in database 'BEL' but process (Familyid 0, Spid 57) already held a 'exclusive page' lock on it.


Deadlock Id 271: Process (Familyid 0, Spid 57) was waiting for a 'exclusive page' lock on page 7363207 of table 'orders' , indid 8 in database 'BEL' but process (Familyid 0, Spid 49) already held a 'shared page' lock on it.
Deadlock Id 271: Process (Familyid 0, Spid 49) was waiting for a 'shared page' lock on page 7376230 of table 'orders' in database 'BEL' but process (Familyid 0, Spid 57) already held a 'exclusive page' lock on it.

Deadlock Id 271: Process (Familyid 0, Spid 57) encountered multiple deadlocks.
Deadlock Id 271: Process (Familyid 0, Spid 57) was chosen as the victim.
Victim process host = `', user = `xxx' program name = `' host processes = `4088' .

End of deadlock information.

57-ой хотел эксклюзивную блокировку, т.е. менял данные, два других -- только читали .

Как минимум ты либо что-то не так объясняешь, либо неправильно понимаешь диагностику.

Сергей08,

Да, нормально.
В ASE.